How a build runs

The software development process, week by week

A healthy custom software project moves through five phases: a first call to check fit, a discovery phase that turns the idea into a scoped plan, a build that ships working software in weekly increments, quality work that runs through the whole build, and a complete handover that leaves you owning everything. This guide walks what happens in each phase, how long the whole thing takes, and what you should be able to see at every step. If you cannot click working software within the first weeks of the build, something is wrong.

Book a thirty-minute call

Short answer

A software project runs from a first call through discovery, ships in weekly reviewable increments, and ends with documentation, tests, observability, and a complete handover.

Best for

  • Founders hiring a software agency for the first time
  • Teams comparing how different agencies actually work
  • Buyers who want checkpoints to hold a vendor to
  • Anyone unsure what happens between contract and launch

Not for

  • Teams with a mature in-house delivery process that already works
  • Buyers who want to disappear for three months and collect a finished product
  • Projects with nobody available for a weekly review
// 01

Compare the options

How a healthy process differs from agency theatre, phase by phase.

Phase A healthy build Warning signs
First call

Fit and scope questions, and a clear no if it is not a match.

A price quoted on the spot for an unscoped build.

Discovery

Requirements, architecture, roadmap, riskiest assumption tested.

Skipped entirely, or a paid document nobody pressure-tests.

Contract

Fixed price for locked scope, weekly retainer if scope moves.

Hourly billing with no defined outcome.

Build rhythm

Working software you can click every week or two.

Status slides and burndown charts instead of software.

Quality

Tests, CI/CD, and monitoring grow with the code.

QA squeezed into the last two weeks before launch.

The end

Documentation, credentials, and a complete handover.

Knowledge stays with the vendor so you cannot leave.

// 02

Where Wavect lands on this

Every build we run follows the same shape, because the failure modes are always the same. The first call is thirty minutes to find out whether you should build at all. Sometimes it ends with us telling you not to. Then discovery turns the idea into requirements, an architecture, a roadmap, and a test of your riskiest assumption, from EUR 3,500, deducted from the final invoice.

With scope on the table, you pick the contract that matches your certainty: a fixed-price Werkvertrag if scope is locked, a weekly retainer you can cancel any week if the product is still moving. The build ships in increments you can review, working software every week or two, not status slides. Tests, CI/CD, and monitoring grow with the code instead of being bolted on before launch. Our QA checklist shows what has to be in place by then.

The engagement ends when the handover is complete: code in your repositories with full history, documentation, a test suite and pipeline you can run yourself, and every credential rotated to you. A process with no defined end state is designed to keep you dependent.

// 03

Cost, risk and timeline

Discovery From EUR 3,500Deducted from the final invoice, and the input every honest estimate depends on.
Build rhythm Weekly incrementsWorking software to review every week or two, from early in the build.
Full timeline Weeks to monthsA scoped MVP has shipped in 6 weeks. Complex products take months. Nobody honest quotes a date before discovery.
// 04

Where this usually goes wrong

  • Signing a fixed price before anyone scoped the build, then fighting over every change.
  • Months of silence followed by a big-bang delivery that misses the mark.
  • Progress measured in tickets and slides instead of software you can click.
  • QA and documentation postponed to the end, then cut when the timeline slips.
  • No product owner on the client side, so decisions stall for weeks.
  • No defined end state, so the handover never happens and you cannot leave.
// 05

The checklist

What you should be able to verify in each phase of a build.

  • A first call that questions your scope instead of just quoting it.
  • A discovery phase that delivers requirements, architecture, a roadmap, and a tested riskiest assumption.
  • A contract that matches your certainty: fixed-price Werkvertrag for locked scope, cancellable weekly retainer if not.
  • Working software to review every week or two, starting early in the build.
  • A change process that prices and reprioritizes openly instead of absorbing scope silently.
  • Tests, CI/CD, monitoring, and error tracking built during the build, not after it.
  • A handover with code, history, documentation, credentials, and infrastructure access.
// 06

What this looks like in our work

The same process on real timelines: discovery, weekly increments, complete handover.

PromptID

Live
6 weeks 0 to Production

AI-native assessment platform, 0→production in 6 weeks under compressed market pressure.

NestJS NextJS LangChain
AI 2026

LivLive

Live
+1,000 Concurrent Users

AR-RWA platform: $2M+ raised through the product, 1,000+ concurrent users, six weeks flat.

Solidity Typescript React
BLOCKCHAIN 2025

These are selected projects, not our full portfolio. We have shipped 75+ products since 2018.

// 07

When this fits, and when it does not

// 01

When Wavect is the right fit

  • You want checkpoints you can verify, not promises you have to trust.
  • Someone on your side can review working software every week or two.
  • You want to own the code, docs, and infrastructure at the end.
  • You want an honest no early instead of a messy yes late.
// 02

When we are not the fit

  • You want to hand off a spec and reappear at launch.
  • Nobody on your side can make product decisions week to week.
  • Procurement requires hourly billing and timesheets.
  • You measure progress in hours logged, not software shipped.

A process you can verify week by week is the difference between hiring a partner and funding a black box.

// 08

Related services & reading

// 09

FAQs

Five, in practice: a first call to check fit, a discovery phase that produces scope, architecture, and a roadmap, a build that ships working software in weekly increments, quality work like tests, CI/CD, and monitoring that runs through the whole build, and a handover that transfers code, documentation, and credentials to you. The names vary between vendors. The checkpoints should not.
A scoped MVP takes weeks. We have taken products from zero to production in six weeks, and that pace requires a tight scope and a decisive product owner. Products with heavy integrations or compliance take months. Any date quoted before discovery is a guess, so fix the scope first, then hold the vendor to the date that comes out of it.
Waterfall plans the whole project up front and builds it in one pass. Agile builds in short cycles and adjusts as it learns, with Scrum as the most common framework. In practice a healthy project mixes both: discovery is a small planning phase before code, then delivery runs agile in weekly increments. The label matters less than whether you see working software regularly across the whole SDLC .
They will change, and a healthy process plans for it. Small changes are typically absorbed within the current increment. Larger ones get an impact assessment, a priced change request, and an open reprioritization with you. The warning sign is a vendor where change is either a fight or a silent budget overrun.
Discovery is the intensive part, because your answers define the scope. After that, plan for a weekly review of working software and availability for decisions in between. What a build cannot survive is having no product owner on your side, because every open decision stalls the work.
Last reviewed: byKevin Riedl wiki ↗
Book a thirty-minute call