“I built it in a weekend” is one of the proudest sentences in software, and one of the most misleading. Because shipping was never the finish line — it was day zero of a bill that comes due every month for as long as the thing exists. The dependency that ships a breaking change. The security patch you can't skip. The platform that deprecates the API you built on. The code that worked perfectly in 2026 and quietly stops working in 2027 because the world moved underneath it. This is the maintenance tax: the recurring cost of keeping shipped software alive, and it's the line item almost nobody prices in when they estimate what a project will cost. It's also the third and final tax in a set — after the complexity tax you volunteer for and the build-time tax you pay to launch — and it's the one that never stops.
What the Maintenance Tax Actually Is
Once software is live, a whole category of work begins that has nothing to do with new features and everything to do with staying in place:
- Dependency churn. Every library you pulled in has its own release schedule, and its authors don't consult you. Minor bumps, major rewrites, renamed APIs — each one is a small tax you either pay now or defer into a bigger one later.
- Security patches you can't defer. A CVE in something three layers down your dependency tree isn't optional homework. The clock starts the day it's disclosed, whether or not you were planning to touch that code.
- Breaking upgrades. The framework's next major version has the fix you need and the migration you dread. Staying on the old one is its own slow-accruing debt; moving is a project.
- The platform shifting under you. The payment API, the cloud service, the OS, the browser — anything you built on can change its behavior, its pricing, or its very existence on a timeline you don't control.
- Bit-rot. The quietest one. Nobody touched the code and it still broke, because everything around it aged. Working software decays just by sitting still in a moving world.
None of this is glamorous, none of it ships a feature, and all of it is mandatory if the software is to keep running. That's what makes it a tax rather than a project: it's not a thing you finish, it's a rate you pay. And it's charged against the same scarce resource everything else is — your attention — except that unlike building, maintenance gives you nothing new to show for the hours. You spend a Saturday and the reward is that your app works exactly as well as it did on Friday.
The Tax Scales With Surface Area
Here's the part that turns maintenance from a footnote into a design principle: the bill is proportional to how much you built and borrowed. Every dependency is a future upgrade. Every third-party service is a future outage and a future pricing email. Every clever abstraction is a thing the next person — possibly future you — has to relearn before they can safely change anything. The forty-dependency app that came together fast is a forty-dependency app you now maintain, and “move fast” has a way of meaning “front-load the speed, back-load the upkeep.” The choices that felt free on build day — sure, add the library, wire the service, pull in the framework — were never free. They were financed. The maintenance tax is the interest, and it comes out of every future month.
AI Made Code Cheap to Write — Not Cheap to Own
The 2026 trap is subtle and everywhere. AI assistants have made it nearly free to add — generate the integration, scaffold the service, pull in the dependency, produce another few hundred lines in seconds. But the AI that wrote it in five minutes does not pay your maintenance tax, and neither does the ease of writing more. Every generated integration is still a real integration to keep working; every borrowed library is still yours to upgrade; the surface area you can now create effortlessly is surface area you'll maintain by hand for years. Cheap-to-write has quietly decoupled from cheap-to-own, and the gap is exactly where the maintenance tax hides. The fastest way to a punishing upkeep bill in 2026 is to let a tireless assistant say “yes” to every dependency you'd once have thought twice about.
The Case for a Small Maintenance Surface
The response to a recurring tax is the same as always: reduce your exposure to it, deliberately, up front. In maintenance terms, that means choosing tools by the upkeep they'll demand, not the speed they offer on launch day:
- Fewer dependencies, chosen on purpose. Every one you don't add is a maintenance obligation you never take on. The question isn't “does this library help today?” but “am I willing to own its upgrades for years?”
- Boring, stable technology. The unfashionable framework that's changed slowly for a decade is a maintenance gift: it's not going to surprise you. Novelty is fun to build on and expensive to keep up with.
- Code you own and understand. A foundation you can read end to end is one you can fix, upgrade, and reason about when something breaks — as opposed to a black box you can only pray around. Ownership is what lets you age software on your schedule instead of a vendor's.
- Watch for lock-in that expires. A tool whose access ends when a subscription lapses adds a permanent line item to the very software you were trying to keep cheap to run. Prefer things that keep working when you stop paying.
The Honest Counterpoint
Fairness requires naming how this advice curdles when taken too far, because “minimize dependencies” has its own failure mode: the developer who refuses every library and hand-rolls auth, date math, and a half-baked ORM — and now maintains all of it, worse than the well-supported package would have, and alone. A popular, actively maintained dependency is often less maintenance than your bespoke replacement, because thousands of other users are finding its bugs and its maintainers are fixing them on your behalf. So the goal was never zero dependencies; it's deliberate ones. The skill is honest triage: does this dependency carry its own weight and stay maintained, or is it a liability I'm importing? A load-bearing, well-kept library is leverage. A trendy, abandoned, or barely-used one is a future 2 a.m. page. Count them by the upkeep they'll cost, not by their number.
The Decision, Honestly
Frame every build-or-adopt choice by its total cost of ownership, not its build-day price. Take on maintenance surface when it genuinely earns its keep — the mature library that saves you from owning a hard problem badly, the boring platform that will still be here in five years. Refuse it when the only thing it buys is a faster Saturday — the extra dependency, the clever indirection, the trendy service you'll be babysitting long after the novelty wears off. The asymmetry is the whole lesson of the trilogy: a little discipline about what you take on is cheap and continuous, while a maintenance sinkhole is a debt that compounds silently until the day it consumes a weekend, then a week, then the will to keep the project alive at all. Software isn't done when it ships. It's done when you stop running it — and everything between those two dates is the tax. Price it before you build, and you get to decide how big it is. Ignore it, and it decides for you.
A Foundation You Own, Not One You Rent
ShipKit is a production-ready FastAPI foundation you buy once and own outright — no subscription lock-in, perpetual access to the version you purchased. Boring, readable, and yours to age on your own terms: a small maintenance surface by design.
Explore ShipKit