How We Run a Software Project End-to-End (and Where Most Partners Stop Early)

Most software partners stop at one of two places: the match, or the demo. The match is where staffing firms stop — engineer placed, invoice sent. The demo is where agencies stop — feature shown, sprint closed. Neither is where your product starts earning money, and neither is where the risk actually lives.

I run engineering projects for a living, and I have been on the client side of enough of them to know where they go wrong. They do not go wrong in the code. They go wrong at the seams: between the discovery nobody wrote down and the architecture nobody chose; between the sprint that closed and the production system nobody owns. So when a founder asks me «how do you run a project end-to-end?», the honest answer is a list of seams and what we put at each one.

This is that list. Four phases, the cadence inside each, the roles, and the numbers we sign against. It is the same process whether the engagement is a fixed-price MVP, an embedded squad or a single senior engineer inside your team — the cadence scales down, the seams do not go away.

Discovery is one week, and it ends with a document you can argue with

The first week is not a workshop with sticky notes. It is a written scope: what the product must do at launch, what it must not do yet, which existing systems it touches, and what «done» means in a number you can check. We write it as a technical RFC — the same shape we use internally, and the same shape I have argued every team should use — because a document you can disagree with line by line is worth ten slide decks you nod at.

Two things come out of discovery that most partners skip. The first is a risk list ranked by cost of being wrong: the third-party API that has no sandbox, the data model that will be painful to migrate, the compliance requirement that changes the hosting decision. The second is a kill criterion: the condition under which we would advise you not to build this, or not with us. I would rather lose a project in week one than deliver something in week twelve that you should never have started.

Architecture is decided in writing before the first sprint, and every decision is dated

Between discovery and development there is a step that gets compressed into «we'll figure it out as we go», and that compression is where technical debt is born. We do not start sprints until the architecture is written as decision records: the stack, the deployment target, the data ownership, the auth model, what is a monolith and what is not. Each record has a date, the alternatives considered and the reason we rejected them.

The rule I apply is the one I gave in the monolith-versus-microservices piece: the architecture that ships an MVP is the one you can operate with the team you actually have, not the one that looks best on a diagram. For a product going from zero to its first ten thousand users, that is almost always a modular monolith with a clean deployment pipeline, observability from day one, and a data model you will not have to rip out. The exotic parts wait until a real number says they are needed.

This step also decides the team shape. A product build gets a squad: a Tech Lead who owns the output, two backend engineers, one frontend, QA, and an AI engineer when the product needs one. A narrower scope gets a smaller shape. But the Tech Lead is not negotiable, because someone has to be accountable for the architecture surviving contact with the sprints.

Sprints run on a cadence you would recognise, with a first merged PR before the end of week one

Sprint zero is the kickoff: backlog groomed with your product owner, the architecture map on the wall, definition-of-done locked. From there the rhythm is boring on purpose, because a boring rhythm is what lets you predict delivery:

• Daily sync in your Slack, your standup. The squad is not a vendor on the other side of a ticket queue; it is in the room.
• First merged pull request before the end of week one. Not a prototype branch — a PR into your main, through your CI. It proves the pipeline, the access, and the working agreement at the same time.
• Demo every two weeks, live, no deck. Working software or a rollback plan. If the demo cannot run, the sprint did not close.
• Retro with a scorecard against the KPI we agreed at scoping. Not velocity. The number the product is supposed to move.

Underneath the ceremonies there is a follow-up layer that I consider the actual product we sell. A delivery manager checks in with the client and with the engineers — weekly by default, daily when a phase is hot — because the problems that kill a project show up first as a tone in a one-to-one, not as a red ticket. This is the operational side of what I have called the forward-deployed model applied to engineering talent: staffing ends at the match, deployment ends at the handover, and the distance between the two is where we earn the fee.

Where projects die: the seam between «demo works» and «production is yours»

I will concede the strongest objection here, because it is the one I would raise myself: plenty of agencies run good sprints and still leave you with a product you cannot operate. The demo works; the on-call rota does not exist; the deployment lives in one engineer's laptop; the documentation is a README from month two. That failure is so common that «the agency built it and now nobody owns it» is one of the five signs I list when a founder asks whether they need a fractional CTO.

So the handover is not the last week. It is a phase with its own deliverables, and we start it at the midpoint of the project, not the end:

1. Production before «finished». The product is deployed to real infrastructure, under your accounts, with monitoring and alerting, weeks before the last feature lands. The last sprint should be shipping to a system that already runs.
2. Documentation that survives the people. Architecture, the decision records, the deployment guide, the runbook for the three things most likely to page someone at 3 a.m.
3. Accounts, keys and repositories in your name. Then a safe delete of every copy of your corporate content on our side, confirmed in writing.
4. A knowledge-transfer window sized to the team that inherits the system — a half-day if a senior team is taking over, two weeks of paired sessions if it is your first hire.

What this costs us is margin at the end of a project, when the temptation is to coast. What it buys you is a system you own on the day the invoice stops.

The numbers we sign against, so you can hold us to them

A process description is only as good as the terms behind it. Ours, in writing:

• Billed monthly, 30-day operational notice. No twelve-month lock-in. An engagement that has stopped adding value should be able to end.
• Fixed scope, fixed price for an MVP: eight weeks. Discovery, two-week sprints, launch and handover. If the scope moves, we re-scope in writing; the price does not drift silently.
• Replacement guarantee of 30 days, substitute presented within 7, at no added cost. Every engineer we place is on our payroll, so the cost of a mismatch is ours to carry.
• A single accountable owner on our side for the whole arc — the delivery manager — so «who do I call?» has one answer.

And the number I care most about, because it is the only one a client cannot fake: renewals. Our longest current engagement, an embedded squad of three engineers and a delivery manager building a protocol core and its verifier SDKs, opened on a €200,000 budget and renewed for €400,000 more — every deliverable on date, zero bugs. A renewal is a review with a price tag on it.

What I would ask any partner before signing, including us

If you are choosing a software development partner, run this list. The answers tell you where they will stop.

1. Show me the discovery document from your last project. If it is a slide deck, they stop at the pitch.
2. Who owns the architecture decision, and where is it written? If the answer is «the senior dev», they stop at the sprint.
3. When is the first merged PR into my repository? If it is «after the prototype phase», the pipeline is not proven.
4. What happens in a demo that fails? If the sprint still closes, the cadence is theatre.
5. Who checks in with the engineers, not just with me? If nobody, problems reach you late.
6. What does handover include, in writing — accounts, docs, deletion? If it is «we'll send the code», they stop at the demo.
7. What are the replacement and exit terms? If you have to ask twice, you have your answer.

The partner you want is the one who stops last: after the system is running under your name, after the documentation has been read by someone who was not in the room, after their copy of your data is gone. Everything before that is a match and a demo — and a match and a demo are the two places most projects are quietly abandoned.

If you want the version of this process scoped to your product, we scope it in a 30-minute call, and we start by writing down the kill criterion.