How to approach custom software before writing code

Most failed software projects do not fail because the development team was not good enough. They fail because the project started with the wrong assumptions, the wrong scope or the wrong architecture — and nobody realised until it was too late to correct without significant cost.

The solution is not to write code faster. It is to understand the problem properly before writing any code at all.

What discovery actually means

Discovery is not a meeting where stakeholders list everything they want. That produces a requirements document that is too large to build and too vague to use.

Real discovery is a process of separating assumptions from facts, identifying the core business problem and understanding the constraints that will shape the solution.

A useful discovery process answers these questions:

• What is the actual business problem being solved?
• Who are the users and what are their real workflows?
• What does success look like, and how will we measure it?
• What are the hard constraints — regulatory, technical, operational?
• What already exists that this system will need to integrate with?
• What scope can be deferred to a later phase without compromising the core value?

These questions sound straightforward. In practice, getting honest, precise answers to them is the hardest part of building software.

Architecture before implementation

Once the problem is understood, the next step is solution architecture — not implementation.

Solution architecture means defining the system boundaries, the key components, the data model and the integration points before any code is written. It means making the expensive decisions in a context where they can still be changed cheaply.

Common architecture decisions that are cheap to change in a diagram but expensive to change in code:

• Whether functionality lives in a single application or across multiple services
• Where the authoritative data store sits and what the data model looks like
• How integrations with external systems are structured and who owns the contract
• What the deployment model is and what the operational requirements are

Getting these decisions right before building saves significant time and cost later.

What happens when you skip this

The pattern we see most often is a development team that was asked to start building immediately because "we already know what we need."

Six months later, the architecture does not fit the actual requirements. Key integrations are harder than expected. The data model was designed for the original assumptions, not the real workflows. The codebase has accumulated workarounds and shortcuts that make new features slow and risky.

Rebuilding is expensive. Refactoring under delivery pressure is painful. Neither would have been necessary with a week or two of proper discovery and architecture upfront.

How we approach it

At The Cloud Practice, we offer discovery and solution architecture as a structured engagement before any implementation begins. The output is a clear architecture design, a phased delivery plan, and a shared understanding of what is being built and why.

This is not a theoretical exercise. It is the most practical thing you can do before starting a software project.

If you are considering a custom software build and want to reduce the risk of building the wrong thing, we would be glad to talk through our approach.