Already built

Your product is already built and live. What happens now?

Most web development advice assumes you are starting from nothing. Most real problems are the opposite. The product exists, people use it, and something about it no longer works. The right next step is usually smaller than a rebuild and more specific than "we need a developer". This page covers the five situations that come up most often, what each one actually needs, and how to tell them apart.

01

It works, but it keeps breaking

Recurring failures in a live system are usually a boundary problem, not a code-quality problem. Something crosses between the frontend, the backend, an integration or the database, and the failure surfaces somewhere other than where it started. The fix is to isolate the boundary first and change the smallest layer that actually needs changing.

Rebuilding rarely helps here, because a rebuild carries the same misunderstanding into new code. What helps is reproducing the failure reliably, then working outward from it.

Related: replacing one dependency without disturbing the system around it.

02

We do not know what is wrong

When nobody can name the problem, the next step is a paid technical audit, not an estimate. An estimate given without knowing the system is a guess, and guesses turn into scope disputes later.

An audit covers what exists today, which parts are finished and which are not, where the integration and authentication gaps are, and what would actually be involved in fixing each one. It ends with a written read on the smallest sensible next step.

Technical Fit Check
03

The person who built it is gone

An inherited codebase is a normal situation, not a disaster. The first job is not to judge the previous work. It is to find out what the system is doing, what the data looks like, and what still depends on decisions nobody wrote down.

Legacy identifiers, undocumented business rules and half-finished features are the usual findings. They can be mapped and kept rather than discarded, which is almost always cheaper than starting again.

Related: migrating a legacy platform without losing what depended on it.

04

It cannot do what the business needs now

This is the one case where a rebuild is sometimes justified, and the test is not the technology. It is whether the system models how the business actually works.

If the data model still fits and the pain is concentrated in one place, that is a fix or an integration. If every new requirement means fighting the structure itself, and the software now carries workflows rather than just content, the model is the problem and a rebuild becomes the honest answer.

Related: how to decide between keeping, fixing and rebuilding and a booking product that outgrew its platform.

05

We need capacity for a client project already underway

Agencies routing work mid-delivery need a defined implementation slice, not a second client conversation. That means a clear boundary on what will be built, what will be verified, what gets handed back, and who owns communication with the end client.

Confidentiality and white-label delivery are normal defaults here.

how agency delivery works

How to tell which one you are in

  • Can you reproduce the problem reliably? If yes, it is probably a fix.
  • Can you name what is wrong? If not, start with an audit.
  • Does the system model how the business actually works today? If not, the model is the problem, not the code.

If you are not sure, send what exists today and what is blocking you, and I will tell you which of these it looks like.

Send what exists today