MadeCurious has built, supports and maintains a significant number of large applications with 10-15 year+ useful lives. When you work across the whole of the Software Development Lifecycle in this way, you become deeply aware that every stage of a digital product affects the next one.
That’s why we’ve put together a series: The Long View - linking up the full shape of a system's life from the decisions made before build, through the pressures of delivery, to the ongoing care that keeps a system valuable.
This article looks at Part 1: De-risking Before the Build
See here for Part 2: The Feature Pressure Problem
See here for Part 3: Why Software Maintenance Deserves Your Attention
________________________________________________________________
De-Risking Before the Build
Many digital projects fail long before any code is written. This article looks at how early assumptions and unclear problems create risk, and what teams can do to reduce it before build begins.
Key takeaways:
- Many digital projects fail before build begins.
- Unexamined assumptions often become expensive problems later.
- Clarity on the real problem matters more than rushing to a solution.
- Testing assumptions early reduces risk and avoids costly rework.
- Successful projects start when risks, constraints and priorities are clearly understood.
________________________________________________________________
Most digital projects don’t fail during build. They fail earlier, when assumptions are left untested, problems are misunderstood, and the pressure to get moving overrides the patience to get clear.
By the time the real problems surface, the damage is already done. The money is committed. The momentum is hard to argue with. And what looks like a delivery issue is usually an early decision coming back into view.
De-risking a project isn’t about slowing things down. It’s about giving the build phase something solid to stand on.
Where digital project risk really starts
The biggest risks are usually locked in before delivery begins.
Scope is agreed while still vague. Timelines are shaped by optimism. Technical constraints are assumed away. Everyone nods because progress feels good and momentum is hard to argue with.
Once build starts, those early choices harden. Changing course becomes expensive and uncomfortable. What looks like a delivery issue later is often an early decision coming back into view.
We've seen this pattern across complex, multi-stakeholder projects, from national data platforms handling tens of thousands of datasets to critical business applications that entire operations depend on. The projects that go well aren't necessarily the ones with the biggest budgets or the clearest briefs. They're the ones where the right questions were asked before anyone started building. Our bet is that this is even more true when you bring AI into the mix and the speed & cost of production decreases, poor decision making, poor quality and bloat stand to happen much faster.
Get clear on the problem before you start building
Many projects begin with a solution already in mind; a system to replace, a platform to build, a list of features to deliver.
What’s often missing is shared clarity on the problem behind it. Different stakeholders can agree on what’s being built while holding very different views on why it matters, what success looks like, or which compromises they'd accept when trade-offs inevitably appear. That gap tends to show up later as rework, frustration, and shifting priorities. What felt like alignment at the start turns out to have been politeness.
Clarity here doesn’t mean perfect definition.It means a shared understanding of what matters most, what can wait, and what a good outcome actually looks like for the people who'll use the thing, not just the people who commissioned it.
We find that working through this together early, sometimes just over a few workshops, or through a rapid prototyping phase, can reveal misalignments that would otherwise have cost months of rework to unpick.
Identify and test project assumptions early
Every project is built on assumptions. The risky ones are usually the quiet ones.
Assumptions about how existing systems behave. About data quality. About how people will actually use the thing once it exists. About who makes decisions when trade-offs appear. These are rarely written down, they're just known, until they're not.
Surfacing and testing assumptions early costs far less than discovering them mid-build. Even small checks, a technical spike, a quick data audit, a conversation with end users can reveal where confidence is well-founded and where it's borrowed.
One of the most useful questions we ask at the start of a project is: what would be expensive to get wrong? The answers usually point directly to what needs to be investigated before build begins.
Understand technical constraints before committing
Hidden technical complexity is one of the most common sources of pain in digital projects, and one of the most avoidable. Legacy systems rarely behave as expected. Data ownership is often unclear. Security, privacy and compliance requirements often get surfaced late, after key architectural decisions have already been made. We cannot overemphasise how important it is to bring these important "gatekeeping" requirements into the conversation early so they do not become a roadblock or source of friction later.
This is especially true in complex environments: multi-system integrations, regulated industries, or platforms that need to serve diverse user groups with very different needs. The organisations we work with often carry significant technical heritage built up over years of good decisions made in different contexts.
Early technical insight isn’t about designing everything upfront. It’s about understanding what’s possible, what’s risky, and what’s unknown. That understanding shapes better decisions across the whole project.
Align your stakeholders before committing to build
Misalignment rarely looks dramatic at the start. It shows up as slightly different definitions of success, quiet disagreement about timelines, or unspoken assumptions about trade-offs.
If leadership, product, and delivery teams aren’t aligned early, build becomes a negotiation rather than execution. Decisions slow down and confidence drops. The delivery team ends up carrying uncertainty that should have been resolved before they started.
We've found that having a dedicated role (we call them “Partner Outcomes”) embedded in the project from the start, not just at delivery, makes a real difference here. Their job is to maintain a shared vision, facilitate clear communication across stakeholders, and make sure that what's being built still reflects what everyone actually needs as the project evolves.
Treat risk as something to work with, not hide
Risk doesn’t disappear because it isn’t written down. It just moves.Naming risks early builds trust. It shows that uncertainty is being handled deliberately, not ignored. It also turns unknowns into choices. Some risks are accepted. Some are reduced. A few are avoided entirely.
The best project conversations we have are the ones where nobody is pretending to know more than they do. Where the question on the table is what do we need to learn before we commit? and not how do we justify the decision we've already made?
We treat your budget the same way, as something to be managed responsibly and transparently, not optimistically. A responsible budget sets a realistic baseline, holds contingency for the uncertainties inherent in software development, and creates the conditions for real priority calls rather than hidden scope.
Why discovery reduces digital project risk
Discovery is often regarded as optional, a nice-to-have before the "real work" begins. In practice, it's one of the most cost-effective investments a project can make.Good discovery focuses on the right questions. What are we unsure about? What would be expensive to get wrong? What do we need to learn before committing?
The output isn't a stack of documentation. It's fewer surprises. Again, when working with AI, it’s valuable context and planning to expedite faster delivery of the right thing, later. A team that understands the problem deeply. Stakeholders who are aligned. Technical constraints that are known rather than assumed. And a clearer basis for deciding what gets built first, what can wait, and what can be descoped entirely if something more important emerges.
Our preference is to work in a way we frame as “agreed budget with scope control” starting with a clear problem, setting a responsible budget, and making implementation decisions collaboratively as the project unfolds. Rather than trying to define everything upfront, design decisions are made at the point of need, when the team doing the work has the best context to make them. It reduces waste. It keeps everyone's eye on what matters. And it means that when real user feedback arrives as it always does there's room to respond to it.
Know when you’re ready to build
You’re rarely ready because everything is known. You’re ready when the biggest risks are understood and owned. That usually looks like a clear problem definition, tested assumptions, known technical constraints, and aligned stakeholders. A delivery approach that can flex with reality rather than fight it. It looks like informed trade-offs rather than optimism with a timeline attached.The projects that succeed aren’t the ones that rush to start. They’re the ones that take the time to remove avoidable risk before momentum makes that impossible. Then they can move fast because they’ve been built on the right foundation.
________________________________________________________________
Next in The Long View: Part 2: The Feature Pressure Problem → the pressures that build during delivery, and what they cost when nobody's watching.
Also next in The Long View: Part 3: Why Software Maintenance Deserves Your Attention → The feature pressure problem doesn't end at go-live. It shows up later - in the systems that are slow to change, expensive to fix, and harder to love than they should be.
