Most Platform Builds Fail Before the First Commit

Introduction

Over the last decade I’ve watched a lot of product and platform builds, some from the inside, plenty more called in to rescue. The failures rarely look the way people expect. The code is usually competent. The team is usually capable. The cloud architecture is usually defensible.

What’s missing is far more boring, and far more fatal: nobody ever agreed what they were actually building.

Fred Brooks made this point forty years ago: “The hardest single part of building a software system is deciding precisely what to build.” He added something most teams conveniently forget, that no other part of the work cripples the result more when it’s done wrong, and no other part is harder to fix later. He was right in 1986. He’s still right. And yet scoping, requirements, and genuine customer collaboration remain the first things teams cut when they want to “just get moving.”

That instinct is exactly why platforms flounder.

The comfortable lie: “we’ll figure it out as we build”

Writing code feels like progress. Scoping does not. A commit is visible; a week spent pinning down requirements looks, to an anxious founder or a deadline-driven sponsor, like a week of nothing. So teams skip ahead. They convince themselves the shape of the product will emerge once they start building.

It almost never does. What emerges instead is a series of expensive guesses. Engineers make a hundred small decisions a day, what a field means, how an edge case behaves, which workflow matters most, and without a shared definition of “done” they fill every gap with assumption. Some assumptions are right. The wrong ones don’t surface until the customer finally sees the thing and says the four words that sink projects: “that’s not what I meant.”

By then you’re not making changes. You’re unpicking them.

What actually goes wrong

When a build flounders, it’s usually some combination of the same handful of failures, and none of them are technical:

• You built the wrong thing well. The engineering is sound, but it solves a problem the customer doesn’t actually have, or solves their stated problem instead of their real one.
• Scope expanded silently. Nobody decided to double the project. It happened one “small addition” at a time, because there was no agreed boundary to measure those additions against.
• The customer saw it too late. A six-month build with one big reveal at the end is six months of compounding risk. Every misunderstanding had half a year to set like concrete.
• Requirements lived in one person’s head. When the spec is tribal knowledge, every team member builds a slightly different product, and they only discover the divergence at integration.

Notice that “the developers weren’t good enough” isn’t on the list. It rarely is.

Scope is a negotiation, not a document

Here’s the reframe that matters. Scope is not a document you write once, get signed, and file away. It’s a living agreement between the people paying for the platform and the people building it, and it has to be maintained like any other relationship.

That means the customer is not a stakeholder you interview at the start and update at the end. They’re a participant. The best builds I’ve been part of had the customer in the room, or at least in the loop, every single week, looking at something real and telling us where we’d drifted. Not because we lacked confidence, but because their domain knowledge was the single most valuable input we had, and it decayed the moment we stopped collecting it.

This is uncomfortable for a lot of teams. Involving the customer continuously feels slower. It feels like exposing unfinished work. But “slower” here is an illusion: a misunderstanding caught in week two costs a conversation; the same misunderstanding caught in month five costs a rebuild. Continuous collaboration isn’t a tax on delivery, it’s the cheapest insurance you can buy. I’ve written before about how the rituals teams use to communicate are often optimised for the wrong thing; scoping is where that misalignment does the most damage.

What this looks like when it works

When we took on The Accelerator at Princeton, the vision was genuinely clear, a cloud platform to scrape, process and analyse social media data at enormous scale. The path to execution was not. So we didn’t start with infrastructure. We started by working with the stakeholders to define a roadmap: what the platform had to do, in what order, for whom, and what success looked like at each stage. The 18-month build that followed worked because that scoping work happened first, and because stakeholder feedback kept shaping it as the picture sharpened.

Contrast that with the speed it enabled elsewhere. For a global financial-crime advisory we built an audit-ready compliance platform, four product surfaces, thirty engineers, one codebase, from scratch in four months. That pace is only possible because the scope was nailed down hard before the team scaled up. Thirty engineers moving fast against a vague brief is not velocity; it’s thirty people generating rework in parallel. The same was true on Consilient: a tightly defined goal, cut deployment from weeks to roughly a day, gave the engineering an unambiguous target to optimise against.

The pattern is consistent. Clear scope doesn’t slow delivery down. It’s the thing that lets you go fast without going wrong.

“But our requirements will change”

They will. This is the most common objection, and it’s correct, and it’s still not an excuse to skip the work.

Requirements changing is not the same as requirements being undefined. A well-scoped project expects change and has a place to put it: a known baseline, a way to evaluate each new request against the agreed goal, and an honest conversation about what moving the boundary costs. An unscoped project can’t tell the difference between a legitimate pivot and ordinary scope creep, so it absorbs everything, and quietly drowns.

Good scoping also means asking the uncomfortable questions early, while answers are still cheap: what happens at the edge cases, who owns the data, how this integrates with the systems the customer already runs, and what the customer’s own team needs to maintain after we’re gone. These aren’t details to defer. They’re the questions that decide how long the build actually takes, and they belong in the conversation before the first commit, not after the first crisis. It’s the same principle behind taking a concept and running with it properly: the early questions are the project.

Getting it right

You don’t need a heavyweight process. You need a few habits, held to consistently:

• Write down what “done” means, in plain language, agreed by the people paying and the people building, before the team scales up.
• Show the customer something real every week. Not a status update; working software, however rough. Drift surfaces visually long before it surfaces in a report.
• Treat every new request as a decision, not a default. Measure it against the agreed goal and name the trade-off out loud.
• Surface the hard questions first. Edge cases, data ownership, integration, long-term maintenance, early, when they cost a conversation rather than a rebuild.

The bottom line

A platform doesn’t flounder because someone chose the wrong framework. It flounders because the gap between what the customer pictured and what the team built was never closed, and the longer that gap goes unmeasured, the more expensive it becomes to close.

Scope, requirements and customer collaboration are not the boring preamble to the real work. They are the real work. The code is just the part that’s easy to see.

If you’re about to start a build, or you’re partway into one and the brief feels fuzzier than it should, talk to us. A clear-eyed conversation about scope now is a great deal cheaper than a rescue later. You can also see how we approach this through our product development practice, its 10-day MVP Diagnostic, and our broader cloud solutions services.