From PoC to platform: what actually breaks first

When DRAM came to us, their attribution product worked — on a good day, for a small subset of campaigns. The proof of concept had done its job: it proved the idea had value. But scaling a PoC into a platform isn't about making the same code run faster. It's about identifying the assumptions that were fine for a prototype and replacing them before they become production incidents.

The first thing that breaks: data ingestion

Every attribution system lives or dies on the quality and completeness of its input. In the PoC, data ingestion was a straightforward pipeline: pull events, write them to a store, process them later. That works when you're handling a few million events a day. At 100M events? The corners you cut become visible.

• Duplicate events silently entered the pipeline because idempotency was treated as nice-to-have
• Schema changes from partners required code changes instead of being handled at the ingestion layer
• Backfills were effectively impossible — reprocessing historical data would take weeks

We rebuilt ingestion first, not last. Idempotent event IDs, a schema registry, and a reprocessing pipeline designed from day one. It's not glamorous work, but nothing else stands until this is solid.

The second thing that breaks: attribution logic under load

The prototype's attribution algorithm was correct on small datasets. At scale, it was slow and — worse — inconsistent. Two runs over the same data produced slightly different numbers. That's fatal for a product clients use to make budget decisions.

Clients don't care about your algorithm's paper. They care that Tuesday's report matches Wednesday's report. Consistency beats cleverness, every single time.

We rewrote the attribution engine with deterministic ordering, explicit windowing, and a test suite that checks consistency across billions of synthetic events. Speed came after correctness — not before.

The order matters more than you think

Tempting as it is to start with the shiny new UI or the clever features, the platformization sequence at DRAM was: ingestion → correctness → scale → features. Skipping any step means building on sand. Two months after launch, the platform was generating 300% more revenue than the solution it replaced — and the foundation was in place to keep growing.