After Launch

What You're Actually Buying in Ongoing Software Development

4 min read
Share
ongoing-software-development

You sent the same amount again this month. At the end of it, you can't name one thing that shipped. Nobody lied to you — most ongoing software development is sold by availability, and availability is not a deliverable.

Availability is the wrong unit

Most monthly arrangements are priced as access. A developer, or some fraction of one, is assigned to you. You get their hours, their Slack presence, their attendance at your standup.

That holds up until you try to audit it. You can't verify hours you didn't watch. You can't tell a slow week from a blocked week from an idle one. And when the month closes badly, the vendor's honest answer is that the person was there the whole time — which is true, and which is exactly the problem.

The risk sits entirely on you. You paid for someone to be reachable. Whether your backlog moved was never in the agreement. Like most of what goes wrong in an agency relationship, that was visible before you signed anything.

What ongoing software development looks like when output is the unit

Four things get defined before the month starts. All four, in writing, every month.

  • The expert. A named person with a named specialty, assigned to this month's work. Someone you can put on a call, chosen for the thing you actually need built.

  • The scope. The specific backlog items this month covers, agreed before work begins, while you can still change the list.

  • The deliverable. What exists at the end that didn't exist at the beginning. Merged, tested, deployed.

  • The acceptance. How you confirm it's done, decided in the same conversation that set the scope.

None of that is exotic. It's how a well-run project works, applied monthly instead of once. That structure is what the Continuous Development Contract is — one monthly seat, the right specialist on your backlog, a defined deliverable at the end of it.

Why the expert changes

One hire gives you one skill set. Your backlog doesn't stay one shape.

The month you push a mobile release, you want someone who has argued with App Store review before. The month you integrate a payment gateway, you want someone who has handled a Gulf acquirer's 3-D Secure flow and settlement reconciliation. The month your queries start timing out under real load, you want neither of them.

Hire one senior developer and you've bet your roadmap on next quarter's work happening to match their strongest skill. It usually doesn't. The work still gets done — slower, by someone learning it on your budget.

Rotation is what a backlog that keeps changing shape actually asks for.

How context survives a change of expert

The fear is reasonable. Every rotation, context walks out the door.

It only walks out if the context was living in someone's head.

If the only record of why a decision was made is the person who made it, you have a documentation problem. You had it before anyone rotated.

What carries across a handover: written decision records, tickets written so the reasoning survives the ticket, a commit history someone can read, an environment that deploys without tribal knowledge, and review by someone who was on the codebase last month.

We built our own client portal partly for this — status, documents, and change requests in one place the client can open without asking anyone. Continuity you can verify is the only kind worth claiming. It's the same operating discipline behind a build three other agencies had already turned down before it reached us.

What this model doesn't fix

It doesn't fix an undefined backlog. If you can't say what next month should produce, nothing will produce it. You'll spend the month deciding, and the decision will be the deliverable.

One monthly seat is one seat. It will not cover the work of three engineers.

And it isn't a rescue. A codebase in genuine freefall needs a scoped recovery first and continuous work after — running both at once means paying every month to renovate a building that's still burning.

Ongoing software development is worth buying when you can stand at the end of the month and point at what arrived. If you can't point at anything, what you bought was someone's calendar.

Availability is not the unit. Output is.

Filed underAfter Launch
More from the Blog

More from the Blog

Newsletter

Get new posts when they go out.

We publish when we have something worth saying - not on a forced schedule. Drop your email and we will send new posts directly to you.

Follow us
AppWorx

Complex products, delivered right, from the first time, within deadline, & by a team that speaks your language.

© 2026 AppWorx. All Rights Reserved.Built with skill, order, & discipline. That's how complex software gets delivered.