Most custom software projects that go wrong don’t fail in month twelve. They fail in month one — quietly, in the scoping decisions nobody revisits until the budget is half gone.
The first 90 days of an engagement set the architecture, the working rhythm, the definition of “done,” and the relationship between the people paying for the software and the people building it. Get those right and later problems stay manageable. Get them wrong and every sprint inherits the mistake.
This is a practical look at how to structure the opening phase when buying custom software development services — what should happen, in what order, and what you should have in hand at the end of each stage.
Join The European Business Briefing
New subscribers this quarter are entered into a draw to win a Rolex Submariner. Join 40,000+ founders, investors and executives who read EBM every day.
Subscribe
Why the First 90 Days Matter More Than the Rest
Early decisions are cheap to make and expensive to reverse. Choosing a data model, an integration approach, or a hosting strategy takes a few meetings in week three. Changing any of them in month nine can take a quarter.
The opening phase also establishes habits. If requirements arrive as vague emails in week two, they’ll arrive the same way in week forty. If demos are skipped early “because there’s nothing to show,” stakeholders lose visibility and start filling the gap with assumptions.
A well-run first 90 days produces three things: a validated understanding of the problem, a working slice of the product in real users’ hands, and a delivery cadence both sides trust.
A Phase-by-Phase Breakdown
| Phase | Weeks | Main Goal | Key Output |
|---|---|---|---|
| Discovery | 1–3 | Understand the problem, users, and constraints | Problem statement, user journeys, risk register |
| Solution design | 3–5 | Decide how the system will be built | Architecture outline, backlog, release plan |
| First build cycle | 5–10 | Ship a thin, working slice end to end | Deployed increment, CI/CD pipeline, test baseline |
| Validation and adjustment | 10–13 | Test assumptions with real users and data | Feedback log, revised roadmap, updated estimates |
Weeks 1–3: Discovery
Discovery is not a formality before “real work” starts. It’s where the most expensive misunderstandings get caught.
A good discovery phase includes interviews with people who will actually use the system — not just the executives sponsoring it. It maps current workflows, including the workarounds people use today. Those workarounds usually reveal the real requirements better than any specification document.
Discovery should also surface constraints early: compliance obligations, integrations with legacy systems, data quality issues, internal security reviews that take six weeks to schedule. These aren’t exciting topics, but every one discovered late becomes a delay.
What you should have at the end: a written problem statement both sides agree on, prioritized user journeys, a list of known risks with owners, and an honest assessment of what’s still unknown.
Weeks 3–5: Solution Design
With the problem understood, the team decides how to solve it. This includes the high-level architecture, technology choices, integration patterns, and how the system will be deployed and monitored.
The key discipline here is proportionality. A system for 200 internal users doesn’t need the architecture of a consumer platform serving millions. Over-engineering at this stage creates cost and complexity that never pays back. Under-engineering creates rework when the system grows.
Solution design should also produce a first backlog — not a 400-item list pretending to know everything, but a prioritized set of capabilities with the first release clearly defined.
What you should have at the end: an architecture outline you can understand without being an engineer, a prioritized backlog, a first-release definition, and rough estimates with stated confidence levels.
Weeks 5–10: The First Build Cycle
The goal of the first build cycle is a thin vertical slice: one complete user journey working end to end, deployed to a real environment, with real data where possible.
This matters more than feature count. A slice that touches the database, the business logic, the interface, and the deployment pipeline proves the architecture works. Ten half-built features spread across the system prove nothing.
This is also when engineering foundations get laid — automated testing, continuous integration, environments for development, staging, and production, and basic monitoring. Teams that skip these to “move faster” early pay for it repeatedly later.
What you should have at the end: a deployed, working increment; a pipeline that deploys reliably; a test suite that runs on every change; and a demo stakeholders have actually seen.
Weeks 10–13: Validation and Adjustment
Now the assumptions made in discovery meet reality. Real users try the software. Real data flows through it. Some things work as expected. Others don’t.
This phase is about learning and adjusting, not defending the original plan. Estimates should be revisited with actual velocity data. The roadmap should be updated with what users actually need, which is rarely identical to what they said they needed in week two.
What you should have at the end: a feedback log from real users, a revised roadmap, updated estimates grounded in observed delivery speed, and a clear plan for the next quarter.
Common Scoping Mistakes
Treating the specification as a contract for outcomes. A detailed spec written before discovery locks in assumptions that haven’t been tested. Fixed scope on uncertain requirements usually means either change requests or a product that matches the document but not the need.
Skipping users in discovery. Sponsors know the business goal. Users know where the process actually breaks. You need both.
Measuring progress by features started. Progress is working software in production. Ten features at 80% are worth less than three at 100%.
Deferring integration work. Integrations with ERP, CRM, payment, or identity systems are where timelines slip. Tackle the riskiest integration in the first build cycle, not the last.
No single decision-maker on the client side. When five stakeholders each have veto power and none has final authority, the team waits — and waiting is billed the same as building.
Questions to Ask a Vendor Before Signing
- How do you run discovery, and who from our side needs to be involved?
- What will we have in hand at the end of week four? Week ten?
- How do you handle requirements that change after discovery?
- When will we see working software deployed to a real environment?
- How are estimates revised as the project progresses, and how will we be told?
- Who on your team makes architectural decisions, and how are they documented?
Vague answers to these questions are a signal. A vendor with a mature process can describe their first 90 days concretely, because they’ve done it many times.
What Your Team Needs to Bring
Custom software development is a collaboration. The vendor brings engineering capability; the client brings domain knowledge and decisions.
That means a product owner with real authority and available time, access to end users for interviews and testing, timely answers on business rules, and an internal technical contact for integrations and security reviews. Engagements where the client side is under-resourced move slowly regardless of how strong the vendor is.
The first 90 days don’t need to produce a finished product. They need to produce clarity: about the problem, about the architecture, about how the two teams work together, and about what the rest of the project realistically looks like. Companies that invest in getting this phase right spend the following months building — not untangling.
