The honest answer is that a first production release covering one core workflow is achievable far sooner than a complete system, and that most overruns are caused by scope that was never written down rather than by engineering being slow. The single largest determinant of schedule is how clearly you can describe what the software must do before anyone starts building it.
Why "how long" is the wrong first question
The useful question is how long until something is in production doing real work. Those are different, and the gap between them is where projects go wrong.
A team aiming for a complete system spends months building against assumptions nobody has tested. A team aiming for a first release puts a narrow slice in front of real users early, learns which assumptions were wrong while changing them is still cheap, and delivers the rest against evidence.
We build the second way. It is not faster on paper. It is dramatically faster to something that works.
What actually causes overruns
Scope that was never written down. The most damaging arguments on any project are about something both sides assumed and neither recorded. We define scope by exclusions as much as inclusions — writing down what the release deliberately will not do — because that is the list nobody else makes.
Integrations discovered late. "It also needs to talk to the warehouse system" arriving in week six is a schedule change, not a detail. Integration inventory belongs in scoping.
Decisions waiting on one person. Engineering blocks on answers more often than on problems. A named decision-maker who can respond within a day is worth more to a schedule than an extra developer.
Data that is worse than described. Migrations routinely uncover duplicate records, missing fields and values that violate the rules the business believes it follows. Budget for discovering this.
Changing direction without changing the date. Every project changes direction; that is fine and usually correct. The failure is agreeing to the change and pretending the date holds.
What a realistic sequence looks like
| Stage | What happens | What you get |
|---|---|---|
| Scope | Process mapped, exclusions written, integrations inventoried | A document you can hold us to |
| Architect | Data model and service boundaries decided | The expensive-to-reverse decisions, in writing, before code |
| Build | Two-week iterations against staging | Running software you review, not progress reports |
| Harden | Load, security, monitoring, tested restore | Something safe to depend on |
| Operate | Live, monitored, iterating | The remaining scope, delivered against evidence |
The stages that get compressed under pressure are scope and harden. Both compressions are paid back with interest.
Questions that shorten a project
Ask these of yourself before asking a supplier for a date:
- Can we describe the workflow step by step, including the exceptions?
- Which systems must it integrate with, and does each have an API?
- Who decides when there is a disagreement, and how fast can they decide?
- What must the first release do, and what can wait?
- What does the data actually look like, not what should it look like?
A supplier who gives you a confident date without asking these is guessing.
The trade you are actually making
Speed to first release comes from narrowing scope, not from adding people. Adding engineers to a project that lacks a clear specification makes it slower — the new people need answers nobody has, and the specification gets written in retrospect from arguments.
If a date genuinely matters, cut scope. It is the only lever that reliably works, and it is a decision only you can make.
- timelines
- scoping
- delivery
- custom-software