Every sales conversation about custom code reaches the same question, usually asked sideways: "But what happens after? If it's not on a platform, who looks after it? What if you disappear?"
It's a completely fair question and most of the answers to it are evasive. So here is the direct one: what actually happens to a custom-built website in the year after the developer stops working on it.
The short version
Websites don't decay. Their surroundings move.
The code you paid for does not get worse while you sleep. What changes is everything around it — credentials expire, third-party services change their APIs, dependencies get security advisories, browsers ship updates. How exposed you are to that depends almost entirely on what your site does, not on whether it was custom-built.
Two very different kinds of site
"Custom website" covers two things with wildly different upkeep, and conflating them is why the advice on this topic is so confused.
| Static marketing site | App-like site | |
|---|---|---|
| What it is | Pages, images, forms. No login. | Payments, accounts, dashboards, APIs |
| Server software exposed | Essentially none | Yes |
| Can it sit untouched a year? | Genuinely, yes | No — needs periodic review |
| Main risk | An expired credential | A third-party API changing |
A static site is delivered as pre-built files. There is no database to compromise, no admin login to brute-force, no plugin ecosystem updating itself at 3am. This is the underrated part of the model: a large class of maintenance simply doesn't apply, because the software that would have needed maintaining isn't running.
An app-like site is different, and anyone telling you otherwise is selling. If it takes payments or holds user data, it has real obligations.
What actually breaks, in order of likelihood
1. Something expires
By a wide margin the most common cause of a site going down, and it's never the code. A domain registration lapses. A card on the hosting account fails. An API key hits its expiry.
The fix is administrative, not technical: keep every account in your business's name with a shared billing address, turn on auto-renew, and put the domain expiry in a calendar. I have seen a business lose its site for three days because a renewal notice went to a former employee's inbox.
2. A third party changes something
Your payment gateway deprecates an API version. A maps or reviews integration changes its terms. An embedded service shuts down.
This is the real ongoing obligation for anything transactional, and it arrives on someone else's schedule. Mitigation is mostly about not having twelve integrations you forgot about — every third-party service is a small standing commitment.
3. A dependency needs patching
Any modern build has dependencies, and occasionally one gets a security advisory. What matters is a distinction most people aren't told:
- Build-time dependencies run on the developer's machine while generating the site. A vulnerability here is largely a non-event for a static site — the code isn't exposed to visitors.
- Runtime dependencies run on a live server handling real requests. These matter, and they need patching promptly.
A static marketing site is almost all the first kind. That is why "you have dependencies, therefore you need a monthly retainer" is usually an overstatement.
4. The platform shifts underneath
Rare, gradual, and rarely urgent. A browser changes default behaviour, a CSS feature is deprecated, a mobile OS alters how it handles something. Effects are usually cosmetic and show up over years, not months.
"No subscription" doesn't mean "no attention"
The honest correction to my own side of the argument.
Custom code removes recurring platform costs, and that's a real advantage compounding over years. But it doesn't remove the need for someone to occasionally look at the thing. What it does is convert a fixed monthly obligation into an occasional variable one.
For most small businesses that's a good trade. It stops being a good trade if "occasional" becomes "never" and you discover in year three that nobody has looked at the site since launch, three integrations have quietly stopped working, and the contact form has been failing silently for eight months. That last one happens more than you'd think.
The test that actually matters
Forget the technology question. Ask this one:
If my developer vanished tomorrow, could a competent stranger take over on Monday?
That's answered by your handover, not your stack. Here's the checklist — and the right time to ask for it is before the final invoice is paid, not when you need it:
- The repository, in an account your business controls. Not a zip file emailed to you.
- Hosting and domain accounts registered to your business, with billing you control.
- Environment variables and API keys, documented — what each one is and which service it belongs to. This is the most commonly missed item and the most painful to reconstruct.
- How it deploys. One page. "Push to main, the host builds and publishes it."
- DNS access, and a record of what points where.
- A written IP transfer, so ownership isn't a conversation.
If you're commissioning a build rather than inheriting one, ask for all six in the first conversation — a developer who hesitates over any of them has told you something useful, and the rest of the vetting questions are in the buyer's guide to hiring a developer in India.
Hold all six and you are genuinely portable — you can hire anyone, and your leverage in every future conversation is real. Miss the credentials or the repository and you are dependent on one person's goodwill, whatever technology it was built with. That's the substance of owning your stack, and it's what I hand over on every project.
What year two actually looks like
For a typical static marketing site handed over properly:
- Months 1–3: some content edits, a couple of small fixes as real traffic finds edge cases. Normal settling.
- Months 4–12: usually nothing. The site serves the same files it served on day one. This is the part people don't believe until they've lived it.
- Somewhere in there: a domain renewal, ideally automatic.
- Around the year mark: worth an afternoon — check the forms actually deliver, glance at dependency advisories, confirm nothing third-party has silently broken, look at what the analytics say people came for.
That's it. Not zero, but nothing like the ongoing obligation people brace for — and considerably less than the update-and-plugin cycle it replaced.
The honest summary
The fear that custom code strands you is really a fear about dependency on one person, and it's the right fear pointed at the wrong thing. A platform doesn't protect you from it — plenty of businesses are just as stranded on WordPress because the agency holds the logins.
What protects you is the handover. Get the repository, the accounts, the credentials and the deploy instructions, and year two is a quiet year with a website you own.
I'm Divyansh Sood, a freelance developer in Himachal Pradesh. Every project I ship hands over a clean repository, documentation, an architecture walkthrough, a signed IP transfer and 30 days of support — because portability is the point. If you're weighing a custom build and the after-part is what's stopping you, ask me about it directly.