What a decade of maintenance taught us about "done"
When we started Perpact in 2016, "done" meant shipped. The client signed off, the code went live, we moved on to the next thing. It took a few years of the same projects coming back to us — for a fix, a feature, a platform upgrade — before we understood how naive that was.
Ten years and 230-odd projects later, most of the software we've written we've also had to live with. Several of the systems we support today we first built before 2019. That single fact — that we're usually the ones on the other end of the support contract — has quietly reshaped how we build in the first place.
"Done" is where the cost starts, not where it ends
The industry talks about software as if launch is the finish line. For anything that matters, launch is closer to the starting line. A system that runs for five years will spend far more of its life being maintained than it ever spent being built. If you optimise only for the build, you're optimising for the small part.
So we changed what we measure. A feature isn't done when it works on the demo. It's done when the person who inherits it — often us, sometimes the client's own team — can understand it, change it safely, and sleep through the night.
Three things that follow from taking maintenance seriously
Boring technology wins. We reach for the framework the whole team already knows, not the one that's exciting this quarter. In year three, "exciting" reads as "nobody remembers how this works."
Tests are a message to the future. We don't write tests to hit a coverage number. We write them so that the person changing this code in 2028 knows immediately whether they've broken something. That person is usually a stranger, and sometimes it's us having forgotten everything.
Documentation is part of the deliverable. Not a wiki nobody reads — a short, honest description of why things are the way they are. The "why" is what gets lost, and the "why" is what's expensive to reconstruct.
The best compliment we get isn't "that launch went well." It's a client, four years on, saying the system has quietly done its job and barely needed us.
What it costs us up front
Building this way is slower on day one. Choosing the dull option, writing the tests, keeping the docs current — none of that shows up in a demo. Early on, we lost a couple of pitches to teams who promised more, faster. We're at peace with that. The projects we kept are the ones still running, and still paying, years later.
If there's one thing a decade taught us, it's that the second year of a piece of software tells you far more about how well it was built than the launch ever did. We build for the second year now.