I Have Taken Over React Projects Without Standards. Here Is What That Actually Feels Like.

#react #ai #productivity #webdev

Every file looked slightly different.

Not wrong exactly. Just different. One component used arrow functions. The next used function declarations. State lived in hooks in some features and inline in the UI in others. Naming conventions shifted from folder to folder. Import patterns changed depending on who had last touched the file.

I asked for an introduction to the codebase. The answer was: you can see how it is done.

I could see how it was done. The problem was that it was done differently everywhere I looked.

What a codebase without standards actually feels like

It feels like reading a book where every chapter was written by a different author who never spoke to the others.

Each chapter makes sense on its own. The story is technically there. But the voice changes, the style shifts, the conventions reset. You can follow it but you can never relax into it because you never know what the next page will look like.

That is what a React project without standards feels like to the developer who inherits it. Every file requires active reading. Nothing is automatic. The mental overhead of just understanding what exists before you can build anything new is enormous.

And in most cases the AI built a significant portion of it. One session at a time. Each session making slightly different decisions because no rules existed to make them the same.

The handover problem nobody talks about

Most conversations about React project handovers focus on documentation. Write better comments. Create a README. Document the architecture.

Documentation helps. But documentation describes what exists. It does not create consistency in what exists.

A developer taking over a project with good documentation but no standards still has to read every file carefully. Still has to figure out which pattern is the real one. Still has to make judgment calls about how to extend something that was built inconsistently.

A developer taking over a project with standards can move immediately. The patterns are the same everywhere. The naming follows one convention. The structure is predictable. They do not need documentation to tell them what the codebase looks like because it looks the same everywhere they go.

Documentation tells the next developer what your project does. Standards tell them how it thinks. GitHub Copilot can follow standards. It cannot write documentation that compensates for not having them.

What I did instead

I brought my own standards in.

Not loudly. Not as a refactor proposal. Just quietly applied them to every file I touched. Every new component followed the same structure. Every hook followed the same pattern. Every import went through the feature index.

The parts of the codebase I worked on started looking different from the parts I had not touched yet. More consistent. More predictable. Easier to extend.

The other developers noticed. Not because I told them about a system. Because the code spoke for itself.

Here is what that looked like in practice:

Standards I applied from day one:
1. Every component is either presentational or container. Never both.
2. State logic lives in a dedicated hook within the feature folder.
3. All imports go through the feature index file. No deep relative paths.

Three rules. Applied consistently. The codebase started to have a standard in the areas I touched even when it did not have one everywhere else.

The cost of no standard at handover

The developer who inherits a project without standards pays a tax on every single task.

Reading time. Context building. Pattern recognition. Judgment calls about which of the three ways something is done is the right way to extend it.

That tax compounds. The longer the project exists without a standard, the more inconsistency accumulates, the higher the tax gets for every developer who comes after.

The AI did not create this problem. But it accelerated it. Because every session without rules added another slightly different decision to a codebase that already had too many.

The prompt does not matter. The rules do.

A React project handover does not fail because of missing documentation.

It fails because the next developer opens the codebase and finds five different ways of doing the same thing with no indication of which one is correct.

Standards fix that. Not after the handover. Before the first session. Before the first component. Before the AI makes its first decision about how this project works.