Modern Data Stack
The modern data stack conversation in most organisations starts with "we need Snowflake." It shouldn't. It should start with "what problem are we actually trying to solve and what does our current stack prevent us from doing?"
What we hear from operators
The problems we solve
The tool was bought before the architecture was designed
Snowflake or Databricks licences are purchased — often after a vendor demo or a board directive — before the data engineering team has designed the ingestion layer, the transformation model, or the semantic layer on top. The tool sits mostly idle, being used as an expensive substitute for what a well-configured cloud data warehouse already does. The gap between the licence cost and the business value is wide and growing.
Transformation logic lives in stored procedures nobody understands
Most organisations that have been running SQL-based analytics for more than three years have transformation logic buried in stored procedures, views, and scheduled jobs that predate the current team. Nobody fully understands them. Changes break things upstream. Testing doesn't exist. Introducing dbt isn't just a tooling decision — it's a process change that brings version control, testing, and documentation to transformation code.
Ingestion is bespoke, brittle, and constantly breaking
Custom-built ELT pipelines for every source system — each one slightly different, each one owned by the person who built it, each one breaking when the source system changes. Fivetran and Airbyte exist to solve this: managed connectors for 300+ sources, schema change handling built in, monitoring included. The decision to build vs buy these connectors is usually obvious in retrospect.
Who this is for
Who modern data stack is built for
The roles that feel the problem first — and what we build for each of them.
Head of Data
The problem
The dbt project has grown organically — duplicated models, inconsistent naming, missing tests and logic that no longer reflects current business definitions.
What we build
A refactored, tested transformation layer in dbt or SQLMesh with documented lineage, surfaced through a Power BI semantic layer.
Version-controlled, tested transformation layer
IT Head / Architect
The problem
Every source has its own bespoke ELT pipeline, each owned by the person who built it, each breaking when the source system changes.
What we build
Managed Fivetran or Airbyte connectors with schema-change handling and monitoring, landing into Microsoft Fabric.
Pipeline failures alerted in minutes, not found in a wrong dashboard
CTO
The problem
A Snowflake or Databricks licence was bought after a demo, before the architecture was designed — and it now sits mostly idle as an expensive substitute for a cloud warehouse.
What we build
Architecture-first stack selection across Snowflake, Databricks and Microsoft Fabric, driven by your data volumes, refresh needs and team capability.
Stack chosen from requirements, not a vendor demo
CFO / Financial Controller
The problem
The gap between the licence cost and the business value is wide and growing, with no clear line from spend to outcome.
What we build
TCO-based stack selection and a single governed semantic layer feeding Power BI, so every metric is defined once and used everywhere.
Metric definitions consolidated to one governed layer
Measurable outcomes
What changes after implementation
Specific shifts from delivered modern data stack work — the before, and the after.
Ingestion pipelines: bespoke and brittle → managed connectors with monitoring
Fivetran or Airbyte connectors replace custom ingestion code. Source schema changes handled automatically. Pipeline failures alerted within minutes, not discovered when a dashboard is wrong.
Transformation code: undocumented stored procedures → version-controlled dbt models
Every transformation in Git. Every model tested. Data lineage documented automatically. New team members understand the transformation layer from the dbt project — not from tribal knowledge.
Metric consistency: different numbers in different reports → single governed semantic layer
One definition of revenue, margin, OTIF, OEE — wherever the metric is displayed. The semantic layer becomes the single source of truth for metric definitions across the organisation.
By market
Modern Data Stack — market-specific pages
Each page below covers what modern data stack looks like specifically in that market — the local ERP landscape, compliance context, and the operational patterns we actually see there.
Singapore & Malaysia
United Kingdom
North America
Technology stack
Start with a conversation, not a proposal
First call is 30 minutes with Amit. We ask about your systems, your team, and your most pressing operational problem. You get a clear view of where the gap is and what closing it looks like. No slides. No pitch deck. No obligation to proceed.