Tooling & Stack

The toolset behind the work.

Ten platforms cover most of what we ship — from the data platform to the products on top to the Terraform underneath. We'd rather know a short list in production than a long one on slides. Same discipline across all of them.

Deep expertise, prebuilt accelerators

Ten platforms we know in production.

This isn't a list of things we've read about. Every platform on this page has been carried through real engagements — migrations, lakehouses, payment systems, governed AI surfaces — and each comes with its own accelerator: reference architectures, reusable modules, deployment patterns, test scaffolding and operations playbooks built up over years of shipping.

Moberg is a Microsoft Solutions Partner for Data & AI and for Digital & App Innovation (Azure), and a Databricks Consulting & Solution Implementation Partner, with Databricks Certified Data Engineers and Platform Architects on the team. Microsoft and Databricks have both independently audited this body of work — this page is the substance.

The depth is the offer: when we deploy one of these accelerators, you're not paying for a first attempt — you're paying for the version that already learned its lessons.

01 · Data & AI platform

Microsoft Fabric

Fabric folds Data Factory, OneLake, Data Warehousing, Notebooks, Data Science / Copilot and Power BI into a single SaaS workspace. We adopt it where the client already lives in the Microsoft estate and where reducing the moving parts is worth more than maximum platform flexibility.

Best practice

  • One workspace per project, separate dev / UAT / prod, never shared.
  • OneLake as the single storage layer — never copy data between workspaces, use shortcuts.
  • Semantic model first — define measures, dimensions and RLS before the first report.
  • Lakehouse for raw + Silver layers, Warehouse only when the consumer is strictly SQL.
  • Capacity sizing reviewed monthly — Fabric capacity is the dominant cost line.

Suggested use-cases

  • Migration from legacy ADF + Analysis Services + Power BI into one unified Fabric workspace.
  • New-build data platform for Microsoft-shop clients, OneLake as the single storage layer.
  • Consolidated reporting across finance, operations and biology / logistics on one capacity.
  • Self-service Q&A via Fabric Data Agents on top of a properly modelled semantic layer.
  • Right-sizing exercises — replacing a sprawl of Azure data services with one Fabric capacity.
AI in this platform

Copilot in Power BI for first-draft visuals and DAX. Fabric Data Agents for natural-language Q&A over the semantic model. Used as an accelerator and a self-service surface — never as the source of a regulated number.

CI/CD

Fabric Git Integration to source-control workspace items (notebooks, pipelines, semantic models, reports). Deployment Pipelines for promotion through dev → UAT → prod. Pull requests reviewed by a senior engineer before merge to main.

See this platform in the work — all stories →

02 · Data & AI platform

Power BI

Power BI sits on top of all our platforms — Fabric, Databricks, Synapse, on-prem SQL Server alike. The discipline is the same regardless of source: a properly modelled semantic layer, measures that mean exactly one thing, and a separation between "the model" and "the report" that survives a change of designer.

Best practice

  • Star schema, always. Snowflakes only when the source genuinely demands them.
  • DAX measures over calculated columns. Calculated columns over base-table edits.
  • Semantic model is a separate artifact from reports — versioned, tested, owned.
  • Row-level security via Active Directory groups, never via hardcoded usernames.
  • Refresh-on-demand as a Power App for monthly closing — partitioned by business area.
  • Best Practice Analyzer rules enforced before any release.

Suggested use-cases

  • Executive and operations dashboards on top of any modelled source — Fabric, Databricks, Synapse or on-prem SQL Server.
  • Self-service BI with row-level security for geographically distributed teams.
  • Refresh-on-demand Power App pattern for finance during monthly close.
  • Power BI Embedded inside operational applications — reports where the workflow happens.
  • Migration from legacy SSAS Tabular models into semantic-model-first patterns under Git.
AI in this platform

Copilot in Power BI for report-authoring acceleration. Q&A natural-language layer on the modelled semantic model — only as good as the model under it. AI assistants read from the semantic model, not from raw tables. Spec-driven: AI proposes the measure; the engineer reviews and approves before release.

CI/CD

.pbip project format under Git. Tabular Editor scripts for semantic-model unit tests and metadata checks. Deployment via XMLA endpoint or Power BI Deployment Pipelines API. Power BI Activity Log monitored so unused reports get retired, not preserved.

See this platform in the work — all stories →

03 · Data & AI platform

Databricks

Databricks is the platform when data volume, workload variety or an existing Spark footprint make Fabric the wrong answer. We hold Databricks Certified: Data Engineer Professional and Associate, plus Platform Architect accreditation across the team. Production work, not notebook prototypes.

Best practice

  • Medallion architecture — Bronze raw, Silver clean, Gold business — applied consistently.
  • Delta Lake everywhere. No Parquet-only tables in production.
  • Unity Catalog for governance — catalogs / schemas / volumes / lineage, never workspace-only.
  • Workflows for orchestration. Jobs for production runs. Notebooks for exploration only.
  • Cluster policies and tagged compute so the bill can be read at the end of the month.
  • Photon on Silver / Gold where the query volume justifies it.

Suggested use-cases

  • 10TB+ Medallion lakehouse consolidating multiple subsidiaries for a regulated bank.
  • Multi-business data lake spanning grocery, e-commerce and pharmacy — one platform, separate domains.
  • SSAS / SSIS / SQL Server modernisation onto a governed Databricks workspace.
  • Production ML — credit-risk scorecards, demand forecasting, anomaly detection — with full Unity Catalog lineage.
  • Joint teams with in-house engineers — senior, certified Databricks expertise accelerating an existing platform.
AI in this platform

Databricks Assistant and SQL editor copilot for ad-hoc query authoring. Mosaic AI for the model lifecycle when ML is in scope. Lakehouse Monitoring with built-in drift detection. AI applied where it has an auditable home — Unity Catalog lineage covers prompts, inputs and outputs alongside data.

CI/CD

Databricks Asset Bundles for everything — notebooks, jobs, pipelines, clusters, permissions — all as code. Azure DevOps or GitHub Actions pipelines for build → test → deploy. Bundle deployment per environment (dev / UAT / prod) with environment-specific variables. PR validation runs notebook tests and Delta Live Tables checks before merge.

See this platform in the work — all stories →

04 · Data & AI platform

dbt

dbt is how we keep SQL transformations honest. Models versioned, tested, documented and lineaged like any other engineering artifact. We use it on top of Databricks (dbt-databricks adapter), Fabric Warehouse, Synapse and Snowflake — anywhere the transformations are SQL-first and need to live alongside proper engineering practice.

Best practice

  • Layered models: sourcesstagingintermediatemarts.
  • One model per file. Naming convention strict: stg_, int_, fct_, dim_.
  • Tests on every model — at minimum not_null, unique, relationships on keys.
  • Sources defined explicitly with freshness checks — never a SELECT FROM an undeclared table.
  • Documentation in YAML for every column that matters — generated docs are the contract.
  • Incremental models for anything large, with explicit unique keys.

Suggested use-cases

  • SQL-first Silver and Gold modelling on top of Databricks, Fabric Warehouse, Synapse or Snowflake.
  • Documentation-as-code that survives team handover — generated docs become the contract.
  • Test-driven transformations for finance reporting where the audit trail matters.
  • Lineage mapping from raw source to Power BI exposure for governance and impact analysis.
  • Semantic-layer-style metrics defined once, reused across BI tools and notebooks.
AI in this platform

LLM-assisted model authoring with the project context loaded — useful for boilerplate and first-pass docs. We never accept AI-generated SQL without test coverage on the model and a reviewer signing off. AI doesn't get to write a model and the tests for that model.

CI/CD

Slim CI on every PR — only changed models and their downstream are built and tested. dbt run + dbt test required before merge. dbt docs generate + publish on every main-branch deploy. Manifest comparison between branches surfaces breaking changes. Production runs orchestrated from Airflow / Databricks Workflows / Azure Data Factory depending on the wider platform.

See this platform in the work — all stories →

05 · Data & AI platform

Claude

Claude is how more of the business gets to ask questions of the data without learning Power BI, SQL or Python. Through the Model Context Protocol (MCP) we plug Claude into the same governed semantic models, lakehouse tables and document stores that already power the reports — so the answer is the same one the dashboard would give, just reached through a conversation. The point isn't a smarter chatbot. The point is putting the correct drivers for a decision in front of more of the people who actually make decisions.

Best practice

  • MCP servers built on top of governed sources — Power BI semantic models, Unity Catalog, dbt metadata, document libraries — never raw tables.
  • Domain-scoped — finance Claude reads finance MCP, operations Claude reads operations MCP. RBAC enforced at the MCP layer, not after.
  • Read-by-default — any write or mutating action requires explicit human confirmation.
  • Source-cited answers — every number traces back to a measure, a table and a query.
  • Prompt observability — full audit log of who asked what, what was retrieved and what was returned.

Suggested use-cases

  • Daily morning briefings for finance, operations and commercial teams over governed data.
  • Conversational analytics on top of Power BI semantic models — non-technical staff get the same answer the dashboard would give.
  • Cross-document research over contracts, regulator filings, internal reports and transcripts.
  • "Why did this number move?" — operational managers explore variance without filing a ticket.
  • 30-day onboarding companion that has read the team's playbooks, SOPs and architecture docs.
What changes for the business

An analyst's morning starts with a written briefing, not a blank dashboard. A non-technical manager can ask why a number moved without filing a ticket. Cross-document research that used to take an afternoon happens in a conversation. The reports don't go away — but the audience for the underlying numbers gets several times larger.

CI/CD

MCP servers versioned and deployed as services — Terraform for infrastructure, GitHub Actions or Azure DevOps for build and release. Prompt patterns and tool definitions reviewed like code. Evaluation suite for accuracy, hallucination rate and refusal behaviour run before each release. Production conversations fed back into the evaluation suite to catch drift.

See this platform in the work — all stories →

06 · Infrastructure platform

Terraform

Terraform is the layer underneath everything else. Networks, identity, capacity, storage, Databricks workspaces, Fabric capacities, Key Vaults, the lot — all expressed as code, versioned in Git, deployed through reviewed pipelines. The reason it's on this page is simple: the difference between "we can stand up a client environment this week" and "we need a month" is almost always whether the infrastructure is in code or in someone's browser tab history.

Best practice

  • Everything in code — Azure subscriptions, AAD groups, networks, Databricks, Fabric, Foundry, MCP infrastructure — no manual portal changes in production.
  • Modules over copy-paste — a reusable library of modules for the configurations we use repeatedly.
  • Remote state in Azure Storage with state locking, encryption and versioning. Never local state in production.
  • Separate environments by workspace or directory, not by variable swaps in a single file.
  • Plan in CI, apply only via an approved pipeline with environment-specific approvers.
  • Secrets in Key Vault, referenced via data sources — never written to .tf files or state.

Suggested use-cases

  • Day-1 client environment standup — network, identity, capacity, Databricks workspace, Fabric capacity — in days, not weeks.
  • Reproducible provisioning of Databricks + Fabric + AI Foundry across multiple portfolio companies.
  • Multi-environment promotion (dev → UAT → prod) gated by policy-as-code (Azure Policy, Open Policy Agent).
  • Cost-tagged infrastructure so the month-end bill reconciles to project, environment, owner and cost-centre.
  • Drift detection so prod stays as last reviewed — and any unauthorised change shows up the next morning.
AI in this platform

LLM-assisted module authoring with the project context loaded — useful for boilerplate and first-pass documentation. AI-generated infrastructure changes do not bypass plan, review or approval.

CI/CD

Azure DevOps or GitHub Actions. terraform fmt + terraform validate + terraform plan on every PR. Apply only on merge to main, with environment-specific approvers gating dev → UAT → prod. Policy-as-code (Azure Policy, Open Policy Agent) blocks dangerous changes. State backed up, locked and audited.

See this platform in the work — all stories →

07 · Software platform

.NET / C#

.NET is the backbone of our product engineering — the platform behind Netgíró (since 2013, now on .NET 9) and Straumur (50M+ transactions in its first 18 months). ASP.NET Core for APIs and portals, EF Core for data access, Hangfire for background processing, MSSQL or PostgreSQL underneath. The reason it's on this page: when a payments platform has to survive a decade of feature growth, regulator scrutiny and traffic spikes, the framework choice matters less than the discipline around it — but a mature, typed, long-supported platform makes that discipline much cheaper.

Best practice

  • API-first design — every product capability exposed as a versioned, documented API before any UI consumes it.
  • EF Core with explicit migrations, reviewed like any other schema change — no auto-applied migrations in production.
  • Background work in Hangfire with idempotent jobs, retry policies and dead-letter visibility.
  • Structured logging and correlation IDs end-to-end — a transaction is traceable from mobile tap to settlement record.
  • Long-term support releases only in production; upgrades staged through UAT with full regression suites.

Suggested use-cases

  • Payment and fintech platforms — loan management, credit scoring, settlement, reconciliation.
  • Self-service merchant / partner / admin portals with role-based access.
  • High-volume transactional APIs with strict auditability requirements.
  • Long-horizon products that will be maintained for a decade, not a quarter.
AI in this platform

LLM-assisted code generation under spec-driven development — specification first, tests second, generated code third. Adversarial review on anything an LLM produced; nothing merges without a senior engineer.

CI/CD

Azure DevOps or GitHub Actions. Build + unit tests + integration tests on every PR; Docker images promoted dev → UAT → prod with environment-specific approvers. Database migrations applied through the same gated pipeline as code.

Our open-source framework — Warp

Warp — distributed job processing for .NET 10

Warp is a distributed job processing and message queue for .NET 10 built by Moberg. Pub/sub messaging, orchestrated background jobs, and in-memory request dispatch — integrated with an existing EF Core DbContext via the transactional outbox pattern, so business data and jobs commit in the same transaction. No Redis, no RabbitMQ, no separate scheduler — just PostgreSQL or SQL Server.

Four patterns, one pipeline

  • Messages — pub/sub fan-out, every handler becomes a job.
  • Jobs — durable orchestrated work with retries, cron, batches, continuations, named queues, mutex.
  • Requests — in-memory, typed request/response through the same pipeline behaviors.
  • Streams — in-memory IAsyncEnumerable<T> for async sequences.

Production capabilities

  • Outbox pattern built in — no lost events, no dual-write inconsistencies.
  • Crash recovery via per-job heartbeat with automatic requeue.
  • Distributed mutex, circuit breaker, retry & backoff, OpenTelemetry traces and metrics.
  • Push wake-up via PostgreSQL LISTEN/NOTIFY or SQL Server Service Broker.
  • Real-time operations dashboard served at /warp — live throughput, job detail, exception traces, batch progress, recurring history. Dashboard front-end built in React.

View Warp on GitHub →  ·  Documentation →

See this platform in the work — all stories →

08 · Software platform

React

React is our default for product front-ends — merchant portals, admin consoles, customer-facing web apps. Straumur's entire portal suite runs on it. We treat the front-end as a first-class engineering artefact: typed, tested, componentised — not a styling afterthought bolted onto an API.

Best practice

  • TypeScript everywhere — no untyped production JavaScript.
  • Component libraries shared across portals so merchant, partner and admin views stay consistent.
  • State kept close to the server — query-cache patterns over sprawling client state.
  • Accessibility checked as part of review, not as a launch-week scramble.
  • Design tokens shared with UX so the Figma file and the build don't drift apart.

Suggested use-cases

  • Self-service portals over .NET APIs — onboarding, management, reporting.
  • Internal admin and operations consoles with real-time oversight — including the operations dashboard for our open-source Warp framework.
  • Customer-facing web apps where conversion depends on speed and polish.
  • Embedded analytics surfaces (Power BI Embedded inside a product UI).
AI in this platform

LLM-assisted component scaffolding and test generation within the design-system constraints. Generated UI code goes through the same review and accessibility checks as hand-written code.

CI/CD

Lint + type-check + unit tests on every PR. Preview deployments per branch for design review. Production builds promoted through the same gated pipeline as the backend.

See this platform in the work — all stories →

09 · Software platform

iOS & Android — native

Native is the right call when the product depends on the platform itself — biometrics, secure enclave, NFC, deep OS integrations, App Clips / Instant Apps, background processing that has to actually work. Swift / SwiftUI on iOS, Kotlin / Jetpack Compose on Android. Same payments-grade discipline as our .NET work: typed contracts with the backend, offline-tolerant flows, signed builds out of CI only.

Best practice

  • One source of truth for API contracts — generated client code from the same OpenAPI spec the backend publishes.
  • Keychain / Keystore for credentials; never a token in UserDefaults or SharedPreferences.
  • Offline-tolerant flows with explicit sync semantics — a payment is never "probably submitted".
  • Feature flags wired to the same service the backend uses, so client and server roll out in lockstep.
  • Crash + ANR monitoring as a release gate — staged rollouts halted automatically on regression.
  • Accessibility (VoiceOver, TalkBack, Dynamic Type) checked in review, not as a launch-week scramble.

Suggested use-cases

  • Consumer fintech and wallet apps where biometrics, secure enclave and NFC are core to the experience.
  • Apps with strict App Store / Play Store performance budgets — cold start, frame rate, battery.
  • Deep OS integrations — widgets, Live Activities, App Clips, Instant Apps, Wear OS / watchOS companions.
  • Regulated products where platform-specific attestation (App Attest, Play Integrity) is required.
  • Replatforming an underperforming cross-platform app onto native where the UX bar demands it.
AI in this platform

LLM-assisted scaffolding for SwiftUI / Compose screens, view models and unit tests within the existing design system. On-device intelligence (Core ML, ML Kit) when the data shouldn't leave the device. Generated code reviewed adversarially — nothing ships without a senior engineer.

CI/CD

Xcode Cloud / GitHub Actions for iOS, GitHub Actions / Gradle for Android. Lint + unit tests + UI tests per PR. Signed builds produced in CI only — signing keys never on a developer laptop. TestFlight / Play Internal Testing for UAT; staged rollouts to production gated by crash-free-session thresholds.

See this platform in the work — all stories →

10 · Software platform

.NET MAUI

Cross-platform mobile from one C# codebase — the Netgíró consumer app, used daily across Iceland, runs on it. MAUI lets the mobile app share models, validation and API clients with the backend, which is exactly what you want when the backend is the system of record for payments.

Best practice

  • Shared contracts with the backend — one definition of a payment, a loan, a user, used on both sides.
  • Offline-tolerant flows with explicit sync semantics — a payment is never "probably submitted".
  • Platform-specific code isolated behind interfaces, not scattered through the codebase.
  • Release trains aligned with backend deployments; staged rollouts on both app stores.

Suggested use-cases

  • Consumer fintech apps where iOS and Android must ship in lockstep.
  • Field and operations apps that reuse existing .NET business logic.
  • Products where one team owns backend and mobile — and the codebases should reflect that.
AI in this platform

LLM-assisted UI and binding code generation, plus test-device matrix triage. Same rule as everywhere: generated code is reviewed adversarially before it ships.

CI/CD

Build + unit tests per PR; signed builds produced in CI only. Store deployments via staged rollout with crash-rate gates before full release.

See this platform in the work — all stories →

One discipline

Same rules on every platform.

Opinionated defaults. Adversarial review of anything AI-generated. CI gates that don't negotiate.

Let's talk.

Whatever is on your mind — a plan, a question, a challenge — we're happy to think it through with you.

Get in Touch