What the estimate is telling you.

Every agency proposal has a number at the bottom. It came from somewhere — a gut feeling, a previous project, a conversation with whoever was going to build it. The quality of that number, and how it was arrived at, is one of the better predictors of whether the project ends well.

Most estimates are too low because they optimise for winning the work. Some are too high because they optimise for margin. Neither approach serves the agency particularly well when the project is in flight and something unexpected happens, because the estimate shaped what was promised to the client, and the client has a memory.

An estimate is not a number. It is a decomposition — a list of things that need to happen, with some assessment of confidence attached to each one. The senior engineer's job is to make that structure legible before the proposal goes anywhere: here is what we know, here is what we are assuming, here is what we will only discover once we start building.

That distinction matters when you are taking the number to a client. Known work — a form with validation, a standard authentication flow, an integration with an API that has clear documentation — can be priced with reasonable confidence. Assumptions are bets: things that look straightforward but carry hidden complexity, usually because they depend on decisions that haven't been made yet. Unknowns are risks: third-party systems with unpredictable behaviour, client data that hasn't been seen, legacy infrastructure that may or may not behave as described. A good estimate names the risks explicitly. A bad one buries them in a single line that says "integrations" and calls it done.

Weekly client demos are often treated as a showcase — a chance to demonstrate what was built this week and bank some goodwill. That is a secondary benefit. The primary purpose is to put the estimate under pressure.

When you show working software to the client every week, you find out quickly whether what you built matches what they imagined. Scope tends to drift, not in dramatic jumps but in small accumulated misalignments — a feature that was specified one way and interpreted another, a user flow that looked sensible in a document and feels wrong in practice. A misalignment discovered at week two is a short conversation. The same misalignment found at week eight is a negotiation about who absorbs the cost.

The demo is not a report. It is a forcing function. It requires the work to reach a demonstrable state on a fixed schedule, and that constraint shapes how the work gets done. Engineers who know something must be running in front of a client on Friday write differently on Monday. The uncomfortable corners get addressed. The hardcoded placeholder that was going to be fixed later gets fixed now.

There is a distinction between code that works and code that can be handed over. A developer working quickly under pressure can produce the first without producing the second. The gap between them is usually invisible until the relationship ends and someone else has to maintain what was built.

Billing-grade code is not glamorous. It means credentials stored as environment variables, not hardcoded into the function that reads them. A deployment process documented well enough that someone who wasn't there when the decisions were made can follow it without calling anyone. Database migrations that run cleanly in sequence, not a Slack message with a list of SQL statements to apply in the right order. A test suite that catches regressions before they reach the client, not after.

None of this requires a particularly clever architecture. It requires the discipline to do the unglamorous thing when the interesting shortcut is also available — and to keep doing it throughout the project, not just when someone is about to review the work.

The handover is where delivery discipline reveals itself fully. When a project ends and another team — whether an internal developer or the next agency in the chain — picks up the work, what they find is the accurate record of how the project was actually run. Not the intentions, not the meetings, not the promises made in the kickoff call. The git history, the README, the deployed environment, the configuration that lived in someone's head because documenting it was never quite urgent enough.

An agency that brings in an outside engineer and receives back a system that can be deployed, maintained and extended without that engineer still on call has received something worth considerably more than the feature list. The feature list was always going to get built. What is rarer, and more valuable, is a system that the next person can work with. A system that only keeps running because the original author is still answering Slack messages is a liability in the clothes of a delivery.

If you have a project that needs to land cleanly — including the handover — send a brief and we can talk about whether it's a good fit.