Warehouses, pipelines, and the screens someone acts on.

What we build

Eight shapes this work usually takes. Most projects are two or three of them at once.

• Warehouses and semantic models

  A single store fed on a schedule, and a model on top that names the relationships so people can query it without an analyst translating first.

• Pipelines between systems

  Scheduled ingestion, transformation and reconciliation, running where the data already lives.

• Consolidated views

  One place that reads from several operational systems at once, with each profile seeing its own version of it.

• Monitoring dashboards

  The screen a team keeps open, with the indicators that actually change what someone does next.

• Volume moves and migrations

  Moving large sets between systems without losing rows, history or the ability to reconcile what arrived.

• Exploration interfaces

  Maps, filters and drill-downs for material too large or too granular to read as a table.

• Structure out of documents

  Classification and extraction from PDFs, scans and handwritten forms that were never born as data.

• Corpus for assistants

  The retrieval layer an assistant answers from: chunking, embeddings and permissions, before any model is chosen.

  What we build with AI

Where it usually breaks

Every one of these projects started with data the organization already had. None of them started with a storage problem.

• It’s in several systems

  The Inter-American Development Bank monitors loans across operational systems that were never built to talk to each other. Smart Portfolio reads from all of them into a single set of indicators, with access rules that give each role its own view of the same data.

  Inter-American Development Bank. Built on .NET and SQL Server, with Azure Data Factory moving data between systems on a schedule.

• Two systems, two protocols, one warehouse

  An operator ran its business across a core platform that only exposed SOAP and a CRM that spoke REST. We built a REST gateway over the SOAP interface so the rest of the estate could read it at all, then daily pipelines into a warehouse and a semantic model, with the dashboards built on the model rather than on the raw tables.

  Delivered on Microsoft Fabric, with a data engineer on the team.

• It’s not in a shape anyone can read

  Harvard’s India Policy Insights holds health and population data at a granularity that defeats a spreadsheet. We built it as interactive maps, so a policymaker can compare districts and find what matters without opening a GIS tool or asking an analyst first.

  Harvard University. High-granularity geospatial data on PostgreSQL, rendered in the browser.

• It arrives after the moment it was needed

  EmpowerHealth runs several care programs at once, and a weekly report is too late to change what happens in any of them. The analytics update as the programs run, so the team sees a program drifting while there is still something to do about it.

  EmpowerHealth. Real-time analytics across parallel programs, under HIPAA.

What the dashboard is for

The hard part of a monitoring screen isn’t adding indicators. It’s deciding which ones earn the space, and what each one should make somebody do.

• We start from the decision, not from the data

  The first question isn’t what you can measure. It’s what someone is supposed to do differently when a number moves. An indicator that changes nobody’s behaviour is a maintenance cost with a chart on top.

• Who sees what is settled before the schema

  In most of this work different roles are entitled to different slices of the same data. That isn’t a permission layer added at the end. It shapes how the indicators are built, and getting it wrong later means rebuilding them.

• The model comes before the screen

  A dashboard built straight on the source tables breaks the first time a source changes. A semantic model in between names the entities and their relationships once, so the screens on top stay readable and the next question doesn’t need a new pipeline.

What we work in

• Storage and modelling

  SQL Server, Azure SQL and Cosmos DB for relational and document workloads, PostgreSQL where the rest of the stack already runs on it, and Azure Storage underneath. Semantic models on top, so the relationships are named once rather than rebuilt per screen.

• Movement

  Azure Data Factory for scheduled transfer and transformation, and direct integration where a system can be read in place instead of copied. REST gateways over legacy interfaces when the source system can’t be read any other way.

• The unified route

  Microsoft Fabric where ingestion, storage, transformation, analysis and visualization should sit in one place rather than five, which is most of the time when a team doesn’t already have a data platform.

• What people look at

  Power BI where a team already lives in it, and React where the screens belong inside the product instead of beside it. GraphQL when one interface reads across several services and access control has to live in the query.

• Input that isn’t data yet

  Azure Document Intelligence for PDFs, scans and forms, including handwritten records, and generated Word and PowerPoint where the output has to leave the system.