Launch feels like an ending. The work is done, the site is live, and the sensible thing seems to be leaving it alone. A year later it’s slower, something in the contact flow has stopped working, and nobody can say when it stopped.
The site stayed still and everything around it moved
A website isn’t a printed brochure. It sits on a server, runs code written by other people and talks to services owned by other companies. All of those keep moving, whether you touch your site or not.
The software your site is built from releases security fixes, and older versions eventually stop getting them. Browsers change how they treat scripts and cookies. Third-party services revise their APIs and retire old ones on their own timetable, not yours. Search engines adjust what they reward.
Nobody built anything wrong. This is the ordinary condition of anything connected to the internet, and it’s why a site left untouched doesn’t stay as it was. It drifts.
The failures nobody sees for weeks
Sites rarely fail loudly. A page that’s broken outright gets reported within the hour, because visitors complain. The expensive failures make no noise.
An integration stops returning what it used to. A provider changes a field name or retires a version, and the part of your site that depends on it shows nothing. The page still loads, so nothing looks wrong.
The same thing happens where it matters most commercially: a form that submits and thanks the visitor while the message never arrives, a booking step that fails only on certain phones, a payment flow that breaks after a provider’s update. Nobody reports these. The enquiry never reaches you, and the loss doesn’t show up anywhere you’re looking.
Maintenance and ongoing development are different jobs
Keep the two apart. Treating them as one job is how sites end up needing a rebuild.
Maintenance keeps what exists working. That means keeping software current, investigating and fixing what breaks, and making sure the site still does what it did on launch day.
Ongoing development is the site changing as the business does. A new service to explain, a page that isn’t converting, a process worth automating, a section nobody uses that should go. The website your business needed two years ago isn’t the one it needs now.
Most live sites need both. With maintenance alone, a site stays current but stops reflecting the business. With new features alone, the problems underneath pile up until adding anything is slow and risky.
What compounds when a site is left alone
The cost of neglect isn’t linear. It builds up:
- Updates put off for so long that they can’t be applied one at a time any more, so a routine change becomes a project.
- Dependencies so far behind that moving forward means rewriting, not upgrading.
- Small performance regressions stacking up, which is where what a slow website actually costs you starts.
- Content describing services you no longer offer, or missing the ones you do.
- Knowledge leaving with whoever built it, so the next person has to work out how it all fits together first.
Each of these is minor if you deal with it early and expensive if you leave it. That’s also why website modernization and performance work so often means undoing years of deferred maintenance rather than fixing anything that was built wrong.
When you do not need this
Not every site needs continuing engineering work, and we’ll say so.
A small brochure site on a managed platform, changing rarely and integrating with nothing, may need no more than an occasional review. If you already employ engineers who own the site, you need capacity, not a partner. And a site that’s meant to be temporary, like a campaign page with an end date, doesn’t need to last.
The case for continuing work grows with what the site does. The more it integrates with, the more it earns and the more your business depends on it, the more it costs to find a problem late.
What this looks like with us
With ongoing development and maintenance, your website or application stays up to date. Improvements are built as your business needs them, issues are looked into and fixed as they come up, and you have a consistent engineering partner after launch instead of a search for whoever’s available.
It works like any other project with us. You tell us what the site does and what matters about it. We ask about your users, your business goal and your constraints, then recommend an approach. Sometimes the honest answer is that what you have needs very little. If your site has been running for a while without anyone looking at it properly, tell us what you are working with and we’ll tell you what we find.