I just want a website

It usually starts with a brief like this.

“I just want a website. Nothing fancy. A few pages, a contact form, something that looks professional. A thousand pounds, give or take.”

The website gets built. It does what was asked. For a while, this is enough.

Then the business grows.

The escalation

Year one. The website works. A new requirement arrives: the business wants to sell online. The original site was built to display information, not to transact. The platform cannot be extended cleanly. It has to be replatformed first — another thousand pounds. Then the ecommerce capability can be added — another thousand. The new platform is selected to suit the immediate ecommerce requirement, not the larger architecture, because nobody is thinking about the larger architecture.

Year two. Ecommerce is working. Orders are coming in. The bookkeeping has become unmanageable manually. The business needs to integrate the ecommerce platform with an accounting system. The current ecommerce platform was not chosen with this integration in mind. A replatform is required — four thousand. The ecommerce functionality must be rebuilt on the new platform — two thousand. The connector to the accounting system — two thousand.

The business has now paid for the same capability multiple times. Each step was reasonable in the moment. The compound cost — and the time spent operating on something that almost works while the next replatform is scoped — was nobody’s responsibility to calculate.

Year three is when I usually get the call.

The collision

By the time someone reaches out, they are not adding accounting.

They are trying to integrate marketing automation, warehouse management, shipping providers, returns processing, customer service tooling, and an inventory system that talks to the suppliers. The physical operation has scaled past what the original platform stack can support. Vans, stock, staff, returns, deliveries — the bricks-and-mortar side is real and operational. The virtual side has been built one platform at a time, without anyone modelling how it would all join up.

The joins don’t fit. The warehouse system knows where stock is. The ecommerce platform thinks it knows. The accounting system shows a third version. The marketing automation tool is targeting customers based on data that may or may not be current. The shipping integration is failing on edge cases because the address structures don’t quite match between systems.

Nobody in the organisation can say when it became this. Each addition was sensible at the time. Nobody had the responsibility — or the perspective — to look at the whole picture.

This is the moment the original choice catches up with the business. The thousand-pound website was not the problem. The absence of a plan beyond the website was.

What the original brief should have included

The owner who asked for a website did not need an architecture. They needed a website. That was the right tool for the moment.

What they did need — and were not offered — was an honest conversation about what came next.

Will you eventually want to sell online? If yes, the platform decision changes today. Choosing a starter platform that cannot extend into ecommerce means paying twice the first time the business grows. Choosing one that can extend means paying slightly more upfront and avoiding the rebuild.

Will you eventually need to integrate with accounting, fulfilment, or inventory? If yes, the platform’s API capabilities matter today. Not because you need them yet, but because the platforms that have credible APIs are different from the platforms that do not.

How large does the business need to become before it stops being a one-person operation? The architectural answer for a business that will plateau at fifty thousand a year is different from the answer for a business that will scale through a million. The owner often knows which they are. They are rarely asked.

These questions do not require a CTO at the website stage. They require someone who has thought beyond the immediate brief. Most web agencies are not in the business of asking these questions because asking them either upsells the project beyond what the client expects, or loses the project entirely to someone who quoted on the simple version.

The pattern, not the story

The story above is one organisation. The pattern is consistent across most growing businesses that built incrementally.

Each platform was chosen for the immediate requirement. Each replatform was triggered when the previous platform could not accommodate the next requirement. Each integration was bolted on with the assumption that the next requirement would not need rethinking the integration.

By the time the business has reached the collision point, the platform stack contains the accumulated decisions of several past selves — none of whom were able to see the current self’s requirements. The decisions were locally rational. The aggregate is irrational by accident.

The cost is not only money, though the money is significant. The cost is time. The months between each replatform during which the business operates on something that almost works. The opportunity cost of not being able to move quickly because the platform stack is in the middle of being rebuilt. The compounding effect on the team’s confidence in their own systems.

What the right conversation looks like

When the call comes in year three, the work is not adding the next integration. The work is architectural triage.

The first conversation is with the people running the operation — the warehouse manager, the customer service lead, the person reconciling the numbers. They know exactly where the joins are failing. They have been working around the failures for months.

Then comes the audit: every system, every integration, every workflow, every place where data has to be reconciled manually. Not to produce a report, but to understand the actual shape of the operation as it exists today versus the shape implied by the original architectural decisions.

Then comes a plan — usually starting with a stable data layer that the various platforms can reference rather than replicate. The platforms that can be retained, are. The platforms that have to be replaced, are. The integrations are designed around the data model, not the platforms.

This is more expensive than building it properly in the first place would have been. It is significantly less expensive than continuing to add platforms to a stack that has already collided.

A few rules

The website is not the architecture. The website is the first expression of the architecture. The conversation about what comes next should happen before the first platform is chosen, not after the third.

Ask about the destination, not just the next step. A platform that suits the current requirement may not suit the next one. The cost of finding out is a replatform.

An API-capable platform costs slightly more. It is worth it. The platforms that can integrate cleanly are different from the platforms that cannot. Pay the difference upfront.

The integration cost compounds. Each new platform added to an unstable stack increases the cost of the next addition. The price of waiting to fix the foundation rises with every quarter.

The first sign of collision is the operational team. When the warehouse manager, the customer service lead, and the bookkeeper all have workarounds they consider normal, the platform stack has already failed. They are just absorbing the failure on the organisation’s behalf.

---

Richard King is CTO at Sixteen Pillars — technical leadership, architecture, and governance for organisations that need it without the overhead of a full-time hire.