They built the website. Everything behind it was missing

A conversation I have heard many times

I have often spoken with owners of small businesses who built their websites in-house. It has happened with different tools and in different years. In one recent case, they had gone beyond a few pages: a builder and AI tools had also helped them create a booking system.

The story included learning the tool, experimenting, overcoming errors and taking pride in achieving something that, until recently, would have seemed out of reach without specialist skills. I understand that satisfaction. I began by learning, taking things apart and rebuilding what I did not yet know.

The part that concerns me comes next: the website opens and the booking goes through, so the work is treated as finished. The ability to produce that result is then assumed to be professional expertise.

This is not about qualifications or seniority. A professional can make mistakes, and a highly capable person can build an excellent project for themselves. The mistake is treating the visible part as sufficient evidence of everything else.

Seeing a function respond does not tell you how it was built, what it protects or who will know what to do when it encounters a case that was not part of the demonstration.

This is not a criticism of AI

I use AI every day in my work. It helps me analyse, compare, write tests, check consistency and tackle work that would otherwise take far longer. Presenting AI itself as the problem would make no sense.

Nor is a site builder necessarily the wrong choice. A temporary page, a personal project or a basic presence with no unusual data or functions does not need the same architecture as a service on which clients and revenue depend.

The boundary is not between people who use AI and people who do not, or between hand-written code and platforms. It lies between generating an outcome and taking responsibility for putting it into production. AI can suggest code and configurations. On its own, it does not know the business context, decide which risks are acceptable or answer to a client whose booking has been lost.

Speed makes the first version easier to reach. It also makes it easier to skip anything that feels like wasted time because it does not produce another screen.

The website ended where the questions began

A booking system is a much more revealing example than a homepage. Someone chooses a day, leaves at least a name and contact detail, submits a request and receives a confirmation. In a straightforward demonstration, everything may work.

But what happens if two people choose the same time? What if the confirmation service does not respond, or a field receives unexpected data? Who can view, change or delete appointments? Where are the credentials used to connect external services? Is there an error log? Can the previous state be recovered after a bad update?

These are not questions invented to make something simple appear complicated. They arise the moment an experiment begins to manage other people’s time, data and work.

The test “it worked on my phone” proves the happy path: one device, one connection, an expected sequence and no surprises. Putting a system to work for a business means dealing with the other paths too.

The invisible part is not a list of optional extras

When I rebuilt my working system, I did more than prepare a theme to start from. I defined a shared core, genuinely separate profiles for single-language and multilingual websites, controlled components and rules that every project must follow.

Semantic structure, accessibility, performance, technical SEO and readiness for AI search are not added if time happens to remain. The same applies to configuration and secrets, data validation, external dependencies, version control, testing, selective deployment and the ability to reconstruct what changed.

This part takes more work than an individual page, but it does not exist to make me feel more technical. It keeps the project from depending on the memory of whoever assembled it or on the hope that nothing will change.

A visitor does not need to know these details. The owner should know whether someone has addressed them and who will continue to do so.

The saving lasts until something goes wrong

Building a website in-house can reduce the initial cost. That is a real advantage and, for some projects, it may be the right decision. Avoiding the price does not remove the work the system requires, however. It leaves that work without an owner or moves it further down the road.

A request that never arrives, two overlapping appointments, an update that breaks a function, exposed data, mishandled tracking or an unusable backup are no longer website problems. They become lost time, clients to call back, trust to recover and costs nobody planned for.

The same applies to ownership. If the domain, accounts, data or functions remain tied to a platform or to the person who configured them, with no documentation, the problem appears at the worst possible moment: when something needs to be fixed, transferred or rebuilt.

Professional work begins after the demonstration

Being a professional does not mean knowing the answer to every problem in advance. It means knowing which questions to ask, stating what is not yet known, testing assumptions and leaving a record of decisions.

It also means being able to say that a feature is unnecessary, a risk is disproportionate or a platform is sufficient for the objective. Adding complexity is not proof of expertise. Removing it without losing control often is.

I use AI within this process. I use it to extend the reach of my work, not to replace control. If a generated proposal is plausible but wrong, the responsibility remains mine. If a change is going live, I need to know which files are changing, which checks matter and how to roll it back.

This part of the work is not spectacular. It does not produce a new screen to show every time. It is what makes it possible to entrust data, reputation and part of a business to a website without treating it as a permanent experiment.

Questions worth asking before choosing

Someone commissioning a website should not need to become a developer, a security specialist or a privacy consultant. They can still ask for understandable answers:

• what data the website will collect and which external services will receive it;
• what loads before and after a cookie choice;
• who can access the information and how credentials will be protected;
• how accessibility, performance, SEO and important functions will be checked;
• which backups will exist and whether recovery has been planned;
• who will own the domain, accounts, code and data;
• who will step in after launch and what happens when something does not work.

There is no need to receive a technical lecture. The point is to understand whether a method exists behind the answer, or only faith that the tool has thought of everything.

Being able to create a website with limited means is good news. It allows more people to experiment and more businesses to get started. It becomes a problem when the ease of producing a first version is mistaken for the preparation required to sustain it.

AI can help build what appears on screen. A professional website begins with everything that must continue to exist when the screen no longer tells the whole story.