AI Gave Business a Superpower. Don't Drown in One JS File

Something quiet but important is happening: apps are increasingly written by people who are not developers. Lawyers, consultants, doctors, logistics people, compliance specialists, wine experts — people who have never made a Git commit — are sitting in Cursor or Claude Code and assembling working prototypes.

I see it among friends and acquaintances from very different fields. The line between 'business person' and 'developer' is simply shifting.

What they build is often genuinely good

The prototypes sometimes impress. The design is clean, the product logic feels alive. Because the person is not building an abstraction — they're building what they do with their own hands every day. They don't have the 'understand the domain' problem. They are the domain.

A programmer starting a similar project almost always simplifies something. Not out of laziness — they just don't know where the real pains live. A domain expert is the opposite: they know so much that the product comes out precise right away. Sometimes even too precise for a first iteration.

And then you open the code

The app works. Shown to clients — approved. Shown to investors — impressed. Partner asked for access — logged in and didn't break it.

Then you open the code:

This is not bad. This is typical. A prototype is a prototype — dealing with architecture at this stage is premature, and nobody expects otherwise. The important thing is to understand that you're building a prototype, and that it has its own limits.

Prototype, MVP, and product are three different things

Between them lies a very concrete amount of engineering work:

• - A prototype exists to show the idea. It impresses, and it's not scary to throw it away.
• - An MVP can be evolved. It already has a structure you're not afraid to touch.
• - A product can survive real users. It has a database, auth, deploy, backups, and a chance of surviving your vacation.

If a project starts to live, at some point it has to move from the first state to the second. The third comes later — often after the first real revenue.

The stack I would start with

If you are not a developer but want to build a web app that can grow later, I would take this set:

On day one I would not go beyond that list. Docker and your own server in week one is an attempt to play 'enterprise engineer' before you have your first ten users.

The refs/ folder and REWORK.md trick

What to do if the prototype already exists, it is messy inside, and you can't rewrite it by hand.

Create a new empty folder for the project. Inside it, create a subfolder refs/. Move everything you've built with previous AI iterations into refs/: old code, prompts, screenshots, feature descriptions. Don't clean anything — it's a reference, not a final project.

Next to the code in refs/, put a REWORK.md file. That is the instruction for the agent — what exactly it should do with your prototype. The text below is universal and works for any domain. Copy it whole; nothing needs to be filled in.

Ready REWORK.md (copy and paste)

Then open the project folder in Cursor or VS Code. For VS Code you need to install the Claude (Anthropic) plugin and log in. In Cursor it is already built in.

In the chat, write a short prompt — the agent will pick up the detailed instructions from REWORK.md:

That's one command, but it turns chaos into structure — as long as the agent has something to lean on. refs/ and REWORK.md are exactly that.

When it makes sense to bring in a developer

The prototype stays yours. Nobody takes it away or rewrites it 'because I know better'.

But at some point a project stops fitting into one head and one file. The signals are simple: AI fixes one thing and breaks another; you're scared to touch code that works; the first real users show up and production errors start costing money; it's time to connect a database, roles, an admin area, and a proper deploy — and it's not clear how.

This is the step where I usually help: go through the existing code, pull out what works, carefully move it into a proper structure, connect the database, auth, and deploy. Not rewrite everything from scratch — that is almost always unnecessary. The goal is to turn what you already have into a project you can keep working on without fear.

In closing

The world right now isn't split into 'developers' and 'business'. It's split into those who can build a prototype themselves and those who can turn a prototype into a system. Both abilities matter, and both are needed.

AI gave you the chance to start without a developer. Once the project starts to live, it is worth bringing in someone who already knows how to work with code, database, and deploy. Not to take the project over, but to help it survive the next six months.

Stuck with a prototype that outgrew its one JS file?

Get in Touch