There’s a belief about custom software that costs owners real money: you build it, it gets delivered, and then it’s done. One project, one invoice, one system that runs forever.
It would be simpler if that were true. It isn’t. Software is not built; it’s grown.
The truck analogy, and where it breaks
Ordering a custom system feels like ordering a custom truck. Pick the spec, pay, wait, drive it off the lot. That’s the build, and it’s real.
But a truck needs oil changes, tires, a battery every few years, the occasional recall. Skip them and it loses value and eventually stops. Software is the same, with one difference that matters: maintenance on a truck preserves its value. Maintenance on software, done right, increases it. Each cycle makes the system do more of what the business needs. That’s the growth part, and it’s where most of the return comes from.
Beware of “just build it”
Plenty of development shops will build exactly what you tell them and send you on your way. On delivery day the product is everything you asked for. Then, on a schedule nobody planned for, it needs to change. The usual triggers:
- Users find the gaps no spec could have predicted
- The business changes how it operates: a new location, a new service, new pricing
- The frameworks and libraries underneath need updating, and eventually security patches stop coming for the old versions
- A compliance, insurance, or customer requirement lands
- An operating system or browser update breaks something that worked last week
Fall behind on any of these and the system slowly stops matching the business it was built for. Grow or die. A partner who’s honest with you says on day one that what you’re buying is a living system, and helps you plan for it.
Why software has to grow
Users’ needs evolve. Whether the system is for customers or your own people, their relationship with it changes once they use it for real. That’s why we don’t try to build everything at once. The backlog holds every idea; the first release holds the ones that deliver the core value. Getting that into people’s hands fast is the point. It minimizes time to value, and what people do with it tells you what to build next far better than another planning session would.
The business changes. Good software models the real world: how orders move, how a job gets scheduled, how a document gets approved. The real world doesn’t hold still. New competitors, new risks, new opportunities, a new owner with new priorities. This is the biggest driver of software growth, and it’s the one you can’t spec in advance.
The ground shifts underneath. Every system sits on a stack of things nobody at your company chose: cloud services, frameworks, operating systems, integrations to vendors who change their APIs without asking. Those move whether your system does or not.
An example
A group of law firms came to us in 2019 with an idea for a shared platform for lawyers and their clients, in a profession that had been slow to adopt technology. Before we built anything, we ran a Validation, Design & Planning engagement with the group to align on the vision, and a great deal of input from working lawyers went into finding the real pain points.
Then we grew it. Concepts were tested with practicing lawyers and their clients along the way, so the team could tell which capabilities were useful and which were distractions. The roadmap changed as we learned. The product that launched was a matter-centric collaboration platform with a shared workspace and integrations to the storage, document, and communication tools firms already used, with the security and compliance the sector demands. We kept working with them through launch and through many rounds of improvement after it.
If we’d built the first spec and stopped, the platform would have been out of date within a year. Because it was grown, it kept matching the way its users actually worked.
What “growing it” looks like as a plan
This is the part owners want to know: what does it cost, and what do I get for it?
- Reserved hours. A set block of team time each month for fixes, small improvements, and keeping the stack current. Not a retainer for a full team, and not a panicked call when it breaks. Our Managed Hosting & Support is built around this.
- A regular look at the backlog. Quarterly is typical. What are users asking for, what is the data showing, what has changed in the business, what’s the next release.
- Analytics on real use. Where people stall, what they never touch, what they do in a spreadsheet instead. This is cheaper than surveys and more honest.
- A modernization path. Every system eventually needs more than reserved hours, and it’s far better to see that coming. A planned modernization is a project. An unplanned one is an emergency.
Budget for this from the start. A system with no plan for after launch is a system with an expiry date, and the date is usually sooner than the owner expects. When a client tells us their custom software has stopped working for them, the cause is almost always that it stopped growing years earlier.
Where to start
If you’re planning a new build, start with a VDP Sprint and ask, in the first workshop, what year two looks like. A good partner will have an answer. If you already have a system that shipped and stopped growing, a System Evaluation will tell you in one to four weeks whether it needs reserved hours, a modernization, or a fresh start.
Either way: your software is never done. Don’t build it, grow it.