Organizations that fund the building of software as one-time projects ("once we ship v1.0 of Product X, we move everyone onto Thing Y") will inevitably be frustrated, fail to deliver outcomes, overspend, and eventually discard the work. Only to fund a replacement project later with similar results.
I've seen this play out hundreds of times.
For context, lots of physical goods are "done" and complete when built and sold. A hammer is done when it leaves the factory, and it's mine when I buy it at my hardware store. I don't expect upgrades or support or new features. Likewise clothes and pastries and soccer balls. When a publisher prints a physical book and sells it to me, it's mine as-is. Tractors used to be "done" when they rolled off the assembly line before GPS and autonomous operations changed the picture.
But applying this to software is fundamentally incorrect, a core misunderstanding of how tech works and is supported. With inevitably bad results. Here are six reasons why you need to keep your maker team (development, product, design, test) intact after v1.0.
- We always trim requirements to ship the first version. Every team is under pressure to get something out, to start earning its keep, to meet market windows. Along the way, we inevitably postpone some less-frequent use cases. Deprioritize a few lower-value features. Accept less-than-perfect scalability. Skimp on live user testing. Miss some failover scenarios. Leave out a marginal report or prompt or configuration item. Every time. Take a look at your hopes-and-dreams list (or PRD or requirements list or "start with the press release" one-pager) for things that didn't make the cut. There's always a shopping list for v1.1 and v1.2 and v2.0.
- We don't know what's missing until real paying users interact with our live product. Brilliant new use cases from early customers, unexpected inputs, telemetry that highlights poor workflow assumptions, data we thought would be easily available, unanticipated issues with languages or currencies or time zones or cultures, parts of our app that aren't very useful, bank routing numbers in formats we don't recognize… Putting the real stuff in the hands of live customers is inevitably humbling and exciting. No product survives first contact with paying customers.
AI makes this even harder. Jeff Gothelf points out that real customers will use our AI features in ways we can't anticipate. - Every system has bugs, and needs fixes. Even when it technically "works as intended." Clarifications of our internal business rules. Obscure use cases that didn't show up in the specs. Performance bottlenecks as we boost usage. Zero-day exploits. Special pricing or metering for our largest customer. I expect a system with no sustaining engineering to die within a couple of quarters.
- The underlying infrastructure is always evolving. We may have built on AWS (or Salesforce or GCP or Azure or ServiceNow), which has its own stream of API updates and sunsetting services and non-optional changes. New browsers, passkeys, evolving payment-gateway requirements, MCP support for AI agents, emerging EU regulations, and new graphics standards... Inevitably, we'll need to make ongoing, continuous updates to our own code to keep running on our chosen platforms and keep interoperating with the rest of the world. Call it tech debt or software entropy, but we can't ignore it or wait until next year.
- There are always new dreams and new opportunities. Every buyer and user and support specialist and industry analyst and board member has suggestions for ways to improve the product. Every sales team and channel partner sees an adjacent market that needs just a few tweaks. Every technical team has ways to boost performance, smooth onboarding, cover more JTBDs, architect for the future. The pressure is irresistible.
- The people best equipped to handle ongoing changes and improvements are the people who built it. Who know the inner workings intimately. Who wrestled with the specific design and architecture choices. Who committed the code and know about the dependencies. Who put their hearts and sweat into it. The POV that "we can just bring in contractors or borrow from other teams when urgent things need to be fixed" is misguided. Inevitably, the learning curve for new folks is much steeper than for those who've built it. Folks swiped from other projects do quickest-n-dirtiest work to get back to their real jobs. And moving our original team onto other stuff means that they quickly lose context… six months later, they mostly have to re-learn their own stuff. I don't buy that "this can't be so hard, AI can probably do most of it, we can re-form the team when we need them."
The need for ongoing investment is a feature, not a bug or a mistake. Software is a depreciating intellectual asset, not a hammer.
Show Me the Money
Why does this matter?
Companies that build software need to recognize and budget for this. Financial models need to match ongoing revenue streams (licenses or transaction fees) against ongoing costs (people and tokens).
Because we have to support every line of our code forever until the very last customer deletes it, we can't pretend that one-off features built for some specific deal will be offset by one-time revenue splits. Those customers will inevitably open P1 support tickets years later, when their own system upgrades break something we've long since forgotten about giving them. Our CEO's phone will light up with a furious demand to repair some data connector that a field engineer improvised in 2017, and we'll agree to fix it.
Market-facing teams like to imagine that we can put 90% of R&D into shiny new things. New products, cool features, AI wonderfulness, killer apps, more sparkle and sizzle. But once we have products in market and revenue from real customers, that's impossible. Sorry. We're selling software, not hammers. It will always need more care and feeding than we'd like.
My default investment model has about 50% of R&D energy toward externally visible new features / opportunities / improvements that we hope will boost revenue. And 35-40% for keeping us in the software business. Your mileage will vary, but I'd consider shorting companies putting less than 30% into care and feeding.
Decades of observation suggest that overweighting new features (70%+) is a short-term shift… unsustainable after a few quarters. Then we inevitably flip to 60%+ firefighting, urgent fixes, pulling the red cord, paying down last year's under-investment. Daily system health status meetings. All hands on deck. Public apologies to customers. Board-level reviews of ticket arrival rates. Deep tech discussions with folks uninterested in having deep tech discussions.
So one-time project-based budgets for commercial or production software ignore how the world works, and inevitably lead to financial and technical crises. It's software-budgeting malpractice.
But We're Outsourcing the Work!
Great, terrific, glad that you have the resources. You'll pay twice as much to outsiders who don't know your systems, context, architecture, or testing philosophy. Who don't have a long-term commitment to your company's viability.
And… everything about the above list is still true. Maybe truer. Requirements are always trimmed to fit the contract; no one can completely spec a system in advance; all software has bugs; our technical environment will keep evolving; and we'll have a wagonload of new dreams and desires for v2.0 long before v1.0 is delivered.
So you should budget for your outsourced development partner to keep their (your) outside team on this project… at half or more of the initial contract run rate for another five years. The financials look very different when we add some reality. ("Wait! How can going outside to build X be twice as expensive over the long run as building it ourselves?")
Yes, But We're Only Going to Use This Once, Internally, For a Few Months
OK, there are some internal tools that might have a very short, finite lifetime. But mostly not. It's like promising to skip dessert tomorrow night if we can have extra dessert tonight. These tools always outlive their stated purpose, and without an owner they eventually blow up.
Sound Byte
Software always needs ongoing improvements, fixes, and the people who know how make those. Inescapably. Unavoidably. Inevitably.