Incremental Delivery: Bronze to Gold Without Waiting Months
Part 4 of the Incremental Delivery series: the medallion pattern makes incremental delivery architecturally possible - the discipline to actually slice work that way is what most teams skip under deadline pressure.
The medallion pattern - Bronze, Silver, Gold - is the closest thing data engineering has to shipping working software every sprint. Raw data lands in Bronze untransformed; Silver cleans, deduplicates, and conforms it; Gold turns it into the business-ready aggregates a dashboard or a decision actually consumes. That architecture makes genuine incremental delivery possible. Almost no team actually delivers that way. Most treat Bronze-Silver-Gold as one long build with a single go-live date months out - and call the two-week planning cycles along the way "sprints" even though nothing ships to a stakeholder until the very end.
This is Part 4 of our series on incremental delivery for data and analytics teams. This post is about the specific discipline of slicing a medallion build so that every sprint ships something a stakeholder can actually use - not a narrower definition of "sprint," but a genuinely different way of sequencing the work.
The Big-Bang Trap: Building All Three Layers First
The default instinct on almost every new data platform build is to build horizontally: get all the source systems landing in Bronze first, then build out Silver's cleaning and conformance logic across the whole domain, then finally start on Gold-layer aggregates once the foundation feels solid. It feels methodical, and it produces a project plan that looks disciplined on a slide. It also means nobody outside the data team sees a single usable number for months - and a lot can go wrong with a plan that long before anyone gets to validate whether the underlying assumptions were even right.
This is waterfall wearing Agile's clothing. Two-week planning cycles don't make a project incremental if nothing ships to a stakeholder until the whole horizontal build is done. Real incremental delivery means the team is wrong about something within the first two weeks, finds out immediately because a stakeholder is actually looking at real output, and corrects course - rather than discovering the same misunderstanding in month four, after building three layers on top of the wrong assumption.
Vertical Slices, Not Horizontal Layers
The fix is to slice the build vertically instead of horizontally: pick one specific, high-value Gold-layer output - one dashboard, one metric a real stakeholder is waiting on - and build only the Bronze and Silver work needed to support that single use case first. The rest of the eventual Bronze and Silver footprint gets built later, sprint by sprint, as each new Gold-layer use case demands it. The team ships something real in the first sprint or two, even if the underlying Bronze and Silver layers only support one narrow slice of what they'll eventually need to cover.
Slicing by Use Case: A Worked Example
Say the eventual goal is a full revenue analytics platform pulling from five source systems - order management, billing, CRM, a product usage database, and a support ticketing system - feeding a dozen downstream dashboards. Built horizontally, that's months of Bronze ingestion and Silver conformance work across all five sources before a single Gold table exists. Built as vertical slices, the first sprint targets just one thing: a daily revenue-by-region dashboard the CFO specifically asked for, sourced only from order management and billing - the two systems that dashboard actually needs.
By the third slice, the "eventual" five-source platform is mostly built anyway - but every sprint along the way delivered something a real stakeholder used, and every sprint was an opportunity to discover a wrong assumption early rather than three months in.
A Sample 10-Week Incremental Roadmap
"Won't We Have to Rebuild Bronze and Silver Later?"
This is the most common objection, and the honest answer is: sometimes, a little - but far less than the fear suggests, and the medallion pattern is specifically designed to make that rework cheap when it happens. Because Bronze preserves raw data untransformed, and Silver's cleaning logic can be corrected and rerun from Bronze with full traceability, a mistake discovered in Slice 2 doesn't mean starting over. It means fixing the Silver transformation logic and reprocessing - not re-ingesting from source systems or rebuilding from scratch. Incremental loading patterns that track only new or changed records mean this reprocessing is also fast in practice, not a multi-day batch job.
The actual risk with vertical slicing isn't rework - it's Gold-table sprawl if nobody's watching. A dozen narrowly-scoped Gold tables built slice by slice, each with its own owner and its own definition, is a healthy outcome. A dozen Gold tables that all claim to answer a similar question slightly differently, because nobody coordinated across slices, is a trust problem - and it's exactly why the governance pause in week 5–6 of the sample roadmap above isn't optional.
Governance Without Slowing Down
Two lightweight rules prevent most of the sprawl risk without reintroducing the big-bang planning this whole approach is trying to avoid. First, one owner and one clear definition per Gold table - if two slices seem to need overlapping metrics, that's a signal to consolidate into a shared Gold table rather than let two similar-but-different versions coexist. Second, quality checks at each hop - schema validation between Bronze and Silver, business-rule validation between Silver and Gold - built into the pipeline from the first slice, not bolted on after slice five reveals a problem slice one already had.
The Staffing Reality This Actually Requires
Vertical slicing asks more of an engineering team than horizontal layer-building does, in one specific way: the engineers building a slice need to move across Bronze ingestion, Silver transformation, and Gold modelling within the same sprint, rather than each specialising in one layer and handing off. A team organised around layer specialists - an ingestion engineer, a separate transformation engineer, a separate analytics engineer - tends to default back to horizontal, big-bang delivery, because that's the sequencing their team structure actually supports.
This is where a lot of data teams either hire slowly against a skills gap they didn't know they had, or bring in a dedicated data engineering team built specifically around full-stack, slice-capable delivery - engineers comfortable moving across the whole Bronze-to-Gold pipeline within a single sprint, rather than a set of narrow layer specialists who can only work well in a horizontal, big-bang sequence.
- Building all of Bronze, then all of Silver, then Gold is horizontal, big-bang delivery wearing Agile's clothing - two-week cycles don't make a project incremental if nothing ships to a stakeholder for months.
- Real incremental delivery slices vertically: build only the Bronze and Silver work one specific Gold-layer use case needs, ship it, then widen the foundation slice by slice as new use cases demand it.
- Bronze's raw, untransformed preservation and Silver's reprocessing capability mean a mistake discovered in a later slice is usually a fast fix-and-rerun, not a rebuild from scratch.
- The real risk in vertical slicing is Gold-table sprawl, not rework - one owner and one clear definition per Gold table, plus quality checks at each hop from the first slice onward, keeps this in check.
- Vertical slicing requires engineers comfortable moving across the whole pipeline within a sprint, not layer specialists who default back to horizontal, big-bang sequencing.
Numlytics' dedicated data engineering team service embeds full-stack engineers - comfortable across Bronze ingestion, Silver transformation, and Gold modelling - directly into your sprint cadence, so vertical slicing is something your team structure actually supports rather than fights against. Speak with a certified consultant about building a slice-ready team for your next platform build.