TL;DR: Most descriptions of the development process are marketing diagrams with five tidy arrows. The real version has a discovery phase that determines everything, a long middle where you change your mind, and a handover that decides whether you own the result. Knowing the shape lets you tell drift from normal.
The reason people ask what happens during a build is not curiosity. It's that they're about to spend money on a process they can't see, with a vendor whose work they can't evaluate, over a period long enough for things to go quiet.
So here is the actual shape, including the parts that are uncomfortable.
Before anything: the one page that decides your budget
Write a page describing the process you want fixed. Who touches it, in what order, what goes wrong now, and what "fixed" looks like.
This is not a formality. It's the single largest lever you have on cost, because a developer who understands the problem can scope it, and one who doesn't has to bill for finding out.
It also does something less obvious. Writing it forces you to notice that your process has exceptions you've never articulated, and exceptions are where software projects go over budget. The customer who gets different pricing. The job type that skips a step. Those exist in your head as "obviously." They do not exist in software unless someone says them out loud.
Discovery: the phase people try to skip
Discovery is where the developer learns your operation and turns it into something buildable. Depending on scope it's a conversation or it's weeks.
What should come out of it is a written document describing what will be built, in what order, and what could go wrong. Not a proposal. A plan.
We run our own build this way and the artefacts are countable: 7 written execution plans covering April through July 2026, each produced before the code it describes. Anything touching data or money also gets a written threat model first, which is why there are 140 of those in the repository.
The reason to insist on this is not process theatre. It's that a written plan is the only version of the project that exists before money is spent, and it's the cheapest place to discover a disagreement. A misunderstanding caught in a document costs an email. The same misunderstanding caught in month three costs a rebuild.
What good looks like: you read the plan and recognise your own business in it, including one or two things you'd forgotten to mention.
The build: what you should actually see
You should see working software early and often, on a URL you can open.
Not screenshots. Not a status percentage. Something you can click.
This matters because "80% complete" is unfalsifiable, and the last 20% of a software project is famously not 20% of the work. A running version, even an ugly one, is the only honest progress report.
Expect the first version you see to be wrong in ways you couldn't have predicted. That is the process working. You're now looking at your process reflected back, and reflection reveals things description doesn't.
What good looks like: a regular rhythm of "here's what changed, here's the link." Weekly is common; the exact interval matters less than the fact that it doesn't slip.
The middle: where you change your mind
You will. Everyone does, and it's not a failure.
The question is whether your developer treats it as a Tuesday or a crisis. Small refinements to things you've now seen working should be absorbed. Genuinely new scope should be priced, and honestly so, because a developer who absorbs everything without discussion will make it up elsewhere.
We reversed a decision on our own product partway through. The roofing configuration originally shipped with a quoting tool. In April 2026 we removed it entirely and replaced it with proposals, because roofing work needs photographs and explanation that a quote line item cannot carry. That was working, shipped code, deleted. It was still the right call, and the alternative was maintaining a feature that fit the trade badly forever.
Where this goes wrong: every request triggers a change order, or no request ever does. The first is a shop profiting from your uncertainty. The second means the price is being recovered somewhere you can't see. Agree what counts as refinement versus new scope during discovery, in writing.
Testing: the invisible phase
At some point work will appear to slow down while nothing visibly changes. This is usually testing, and it's the phase clients most often try to compress.
Automated tests are code that checks the other code still works. Their value isn't at launch, when everything is fresh. It's in month seven, when a small change to one thing silently breaks another. Without them, every future change carries risk that compounds.
Our platform has 97 test files and a failing test blocks release. That's not rigour for its own sake. Across 958 commits it's the only mechanism that makes the thousandth change as safe as the tenth.
What to ask: what's tested automatically, what's checked by hand, and what happens when a test fails after launch.
Launch, and the two weeks after
Launch is not the end. It's the beginning of finding out what real use does to assumptions.
Expect a burst of small issues in the first fortnight. Data that doesn't fit the shape anyone expected. A step people do in a different order than they described. This is normal, and a sensible contract includes a defined period where this class of fix is included rather than billed.
Data migration is the part that most often bites here. In our onboarding work, field mapping is the most common failure: source fields rarely align cleanly with destination fields, so names arrive in company fields, phone numbers in email columns, and custom data disappears silently. Ask specifically how migration will be verified, and insist on checking a sample yourself before the old system is retired.
Handover: the phase that decides ownership
This is the one people don't think about until it matters, and it's the one that determines whether you own the software or merely use it.
Four things should be yours at the end: the code in your repository, the hosting under your account, the domain in your name, and written documentation of how to run it. If any of those sit with the developer, leaving becomes a negotiation.
What to ask before signing, not after: what exactly do I receive at the end, and how long does it take to transfer if I ask.
What normal drift looks like versus a problem
Some slippage is ordinary. Distinguishing it from a project going wrong:
Ordinary looks like a missed week with an explanation and a revised date that then holds. It looks like scope discussions. It looks like the demo showing something you need to correct.
A problem looks like updates arriving only when you chase. It looks like progress reported as percentages instead of working software. It looks like the same date moving three times. It looks like nothing you can open in a browser after several weeks.
The single most useful habit: ask for a link, not a status. A developer who can always produce something running is a developer whose project is real.
Frequently Asked Questions
How long should discovery take before building starts?
For a single-workflow tool, often one or two conversations plus a document. For anything touching multiple systems, expect longer and treat that as appropriate rather than as delay. The test isn't duration, it's whether the output is a plan specific enough that you recognise your own exceptions in it.
Who should be involved from my side?
One decision-maker, and the person who actually does the work daily. That second person is the one most often left out and the one who knows where the exceptions live. Involving them at discovery is cheaper than discovering their workflow at launch.
What if I don't like what gets built?
Address it at the first demo, not the fifth. The cost of changing direction rises sharply with each layer built on top of a wrong assumption. Any developer who reacts badly to early correction is more expensive than one who welcomes it, regardless of rate.
Should I pay for discovery separately?
It's common and often healthy, because it lets you evaluate the working relationship before committing to a build. Ask one thing first: if you proceed, does the discovery fee credit against the project, and if you don't, do you keep the document. Both answers should be yes.
What documentation should I receive?
Enough that a competent developer who has never seen it can run it. How to deploy it, where data lives, what external services it depends on and what they cost, and how to restore it if something fails. If it fits on one page it's probably too thin.
If you can describe the process you want fixed, that page is the start of discovery. We'll tell you what scope it implies and whether an existing product already covers it.
See custom app development or start a discovery call. Related reading: eight checks for vetting a developer, what custom development actually costs, and whether to build it yourself.
Sources
- ClickWerxs platform repository — 7 execution plans and 140 STRIDE threat models written before their corresponding code, 97 test files, 958 commits between 6 April and 20 July 2026; roofing quoting module removed in favour of proposals, April 2026. First-party operator data.
- ClickWerxs onboarding pattern — field mapping is the most common data migration failure; source fields rarely align cleanly to destination schema. First-party operator data.
ClickWerxs builds custom software for businesses and earns revenue from those engagements. This post reflects our direct experience building and operating our own platform, not independent third-party research. No ClickWerxs timelines or pricing are quoted here because both depend on scope, which is established in discovery. This is operator opinion and not legal advice.
Kaleb Dickhaut — Founder, ClickWerxs. Kaleb built ClickWerxs from the ground up, from payment processing ISO to the Command Center platform to the AI SEO methodology the blog runs on. He has onboarded hundreds of small businesses onto payment and CRM systems. linkedin.com/in/kaleb-dickhaut