Why I work on a subscription basis, and why 'done' doesn't exist

Software doesn't stand still

Almost every quote request starts the same way: "what does it cost to have this built?" A logical question, but it assumes something that isn't true. Namely that software is done one day, the way a renovation is done: you deliver, you shake hands, and after that it just stands there.

That's not how it works. Software doesn't stand still, because the world around it doesn't. Browsers update, dependencies age, a security hole turns up in a package you use three layers deep, PHP jumps a version, and the client changes too: a service gets added, a product changes, an integration has to work differently, and so on. Delivery day isn't the end, it's the moment the clock starts ticking.

The problem with a project price

A fixed project price feels safe, but it pits the builder and the client directly against each other. I get paid to finish and leave. You're left with something that starts quietly aging from day one, without anyone looking at it.

And then, a year later, something happens. A form stops working, an update breaks the payment integration, or Google complains about something that's suddenly no longer allowed. You track down the builder, who has other clients by now, and what could have been a bit of maintenance is now an expensive surprise. In the worst case half a rebuild, because overdue maintenance piles up until it's sometimes cheaper to start over.

That's not malice. It's simply what the model invites: both sides optimized for the wrong moment, namely delivery, instead of the years after it.

What a subscription does

That's why I work on a subscription basis. A fixed monthly price, and something concrete delivered every month: an improvement, an update, a new feature, or just the quiet maintenance that keeps things from breaking. No big invoice when something goes wrong, but an ongoing line with the person who built it.

The nice thing is that it lines up the interests again. I have nothing to gain from finishing fast and disappearing; I gain from it staying up and running, because I'm still here next month. And you don't have to save up for the next big overhaul, because a pile of overdue work never forms. Small, steady steps instead of an expensive shock every few years.

That's also why I only work with a handful of clients at a time, not dozens. It's a deliberate limit: it's about real attention and a direct line to the builder, not a ticket that ends up at the bottom of a stack. I'm not a helpdesk queue; I'm the person who knows your system inside out.

The distinction: living software versus a defined job

Now the honest nuance, because not everything needs a subscription.

Some jobs really are done. A data migration from the old system to the new one. A plugin that has to do one thing well. Moving a Joomla or WordPress site to a new version. A code review, or a second opinion on an architecture you want someone to look at. Those are assignments with a clear edge: a start, an end, and a result that simply stands afterwards.

I'm happy to do that kind of work as a separate project, at a fixed price for a defined scope. You don't need a subscription for it, and I won't push one on you.

The distinction I make is simple: a subscription is for software that stays alive, a project price for a job that's truly finished. A running web application that grows with your business belongs in the first category. A one-off migration in the second. The mistake to avoid is swapping the two: filing living software away as a one-off project, or forcing a defined job into a subscription you don't need.

What it gets you

For you as the owner the result is mostly "boring", and I mean that as a compliment. Software that just keeps working without you having to think about it. No moment of panic when something breaks a year from now, because things rarely break when someone's watching. And no vendor lock-in feeling, because you have the builder on the phone instead of being stuck with a system nobody dares to touch.

For me the gain is the relationship. I'd rather build something for a few clients that I can keep improving for years than deliver projects and never think about them again. I want to be able to keep defending the code I wrote, and that's only possible if I keep maintaining it.

Software is never done. You can pretend it is, and pay the bill later. Or you sort out the maintenance from the start, and it never becomes a problem. I know which of the two I want for my clients.