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 each task starts. All four, in writing, every time.

  • The specialist. A named person with a named specialty, assigned to this task and visible to you. Chosen for the thing you actually need built.

  • The scope. What this task covers, written down before work begins, while you can still change it.

  • The deliverable. What exists on the due date that didn't exist before. 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 to every task instead of once. That structure is what the Continuous Development Contract is: one monthly subscription, the right specialist on each task, and a due date on every one.

Why the expert changes

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

The task that pushes a mobile release wants someone who has argued with App Store review before. The task that integrates a payment gateway wants someone who has handled a Gulf acquirer's 3-D Secure flow and settlement reconciliation. And when 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.

A different specialist for each task is what a backlog that keeps changing shape actually asks for.

How context survives a change of expert

The fear is reasonable. Every time the specialist changes, 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 changed.

What carries across a change of specialist: one Project Lead who stays on your account from the first day, 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 already knows the codebase.

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 decide for you. A Project Lead can turn what you want into a plan, but if you can't say what you want next, nothing will produce it. The first tasks will be the deciding.

One subscription is one developer at a time. It will not do the work of three engineers at once.

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.

QR code linking to the AppWorx client app download page
Scan to download AppWorx app
© 2026 AppWorx. All Rights Reserved.Built with skill, order, & discipline. That's how complex software gets delivered.