The real cost of a cheap website

A cheap website costs you later, not now. The build is the smallest number in the exercise. The expensive part is what a cheap build quietly leaves out: no handover, no documentation, no admin panel you can actually use, and accounts that are registered in someone else's name. That is the bill, and it arrives when you can least afford it.

We know because we inherit these projects. A business comes to us wanting a small change, and we find a site nobody can log into, a domain registered to a freelancer who has stopped replying, and analytics feeding a Google account that belongs to an agency two vendors ago. The change they wanted takes an hour. Untangling who owns what takes a week.

Where does the money in a cheap website actually go?

It does not go into the parts that matter. A low quote is low because something has been removed, and it is almost never the visible design. It is the invisible work: the handover, the documentation, the ownership. Those things take time and time is what a cheap quote cannot include. So they get skipped, and you do not notice until you need them.

There are four ways a cheap build bills you after launch.

1. No handover

The site launches, the invoice clears, and that is the end of the relationship. Nobody sits with your team and shows them how anything works. Six months later you want to add a page or change a price and there is no one to ask, because the person who built it never expected you to touch it.

2. No documentation

Nothing is written down. Where the site is hosted, how to deploy a change, which plugins do what, where the images live. All of it is in one person's head, and that head is no longer on your project. The next developer you hire spends the first week just working out how the thing is put together before they can change a word.

3. No admin you can use

Either there is no way to edit the site yourself, so every comma is a paid request, or there is an admin panel so confusing that your team is scared to touch it. Both come from the same place: the build was optimised to be finished, not to be lived with.

4. No ownership of your own accounts

This is the one that hurts most. The domain, the hosting, the analytics, the code, all registered under the vendor's accounts rather than yours. It works fine right up until the relationship ends, and then your business is a hostage negotiation. We have seen live sites with a footer that still reads "Built by [freelancer's name]", because nobody could get into the site to remove it.

What should you own from day one?

Ownership is not a favour a good vendor does you at the end. It is the default a good vendor sets up at the start. Five things should be in your name before the first line of code is written.

• The domain, registered to your business email, not your developer's
• The hosting, on an account you can log into and pay for directly
• Analytics, on a Google account your business controls
• The code, in a repository you have access to, not a folder on a laptop
• Every third-party account, from the payment gateway to the email service, in your name

None of this is expensive to do right. It is expensive to do wrong, and only later. When we built the sites for Akyra Active Life and its three brands, we deliberately kept content as Markdown in the client's own repository rather than behind a login on our servers. There are no admin accounts to lose and nothing to reconcile, because the content lives where the client can always reach it. We even shipped an AGENTS.md file so their team can extend the site themselves with an AI assistant. That is what ownership looks like when it is designed in rather than bolted on.

How can you spot a cheap build before you sign?

You do not need to be technical. You need to ask four questions, and listen for whether the answer is specific or vague.

1. 1.Whose name will the domain, hosting and analytics be registered under? The right answer is yours, in writing.
2. 2.What happens at handover, and is there documentation? A real answer describes a session and a document. A vague answer is a red flag.
3. 3.How do I make a small change after launch, without paying you? If the only answer is "raise a request", you do not have an admin, you have a dependency.
4. 4.Do I get the code? If the answer is anything other than a clear yes, the site is not really yours.

A vendor who has thought about handover answers these instantly, because they have set it up before. A vendor who has not will improvise, and the improvisation is the tell.

What this means for you

The cheapest website is not the one with the lowest quote. It is the one you can still run, change and move in three years without paying a ransom. Pay attention to ownership and handover before you pay attention to price, because a well-built site you control is cheaper over its life than a cheap one you do not. If you want a site that is yours from day one, our web development work is built around exactly that.