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.
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.
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.
Between them lies a very concrete amount of engineering work:
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.
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.
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.
my-new-app/
└── refs/
├── old-prototype/ # everything you built before
├── screenshots/
└── REWORK.md # the file below, saved as-is# REWORK.md This folder (refs/) contains my current prototype. It was built with AI tools over several iterations. Treat everything inside refs/ as a reference, not as the final code. You are allowed to ignore, rewrite, or restructure any of it. ## Goal Rebuild this prototype as a clean, maintainable web application. The goal is not a new design or new features. The goal is a proper structure I can keep developing without fear of breaking everything. ## Stack - Next.js (App Router) - TypeScript - Tailwind CSS - shadcn/ui for UI components, where it makes sense - SQLite for the database to start with - GitHub as the source of truth - Vercel for deployment Do not introduce Docker, Kubernetes, microservices, or custom CI/CD pipelines. If any of that becomes necessary later, we will add it then. ## How the code must be organized - Split the UI into small, reusable components. One component per file. - Keep pages thin. Pages assemble components; they do not contain business logic. - Move all business logic into a /services folder. Logic must not live inside React components. - Create a data layer under /lib/db. All database access goes through this layer only. UI and services never talk to the database directly. - Keep TypeScript types in one place per domain. Do not redefine the same type in multiple files. - No single file should grow beyond ~300 lines. If it does, split it. ## Data - Use a real database from day one. SQLite via Prisma or Drizzle is fine. - Define the entities clearly. If the prototype implies entities that are not explicit, name them and propose a schema. - Do not store important data only in React state or in local JSON files. ## Auth and roles - Start with simple email + password authentication, or magic-link flow. - Support at least two roles: admin and user. Add more only if the prototype already needs them. - Protect admin routes on the server, not only by hiding them in the UI. ## Admin area - Create a minimal admin area inside the same Next.js app under /admin. - It must let me view, create, edit, and delete the main entities of the product without touching the database directly. - Keep it simple: tables and forms. No dashboards, no charts, no decoration. ## What to keep from the prototype - The product flows. How the user moves through the app step by step. - The domain terminology and naming. - Any UI decisions that clearly work well. ## What to discard from the prototype - Copy-pasted blocks of code. - Inline styles mixed with logic. - Anything that looks like it was patched more than twice. - Single files longer than ~500 lines. ## Hard rules - Do not put everything in one file. - Do not mix UI and business logic. - Do not invent new frameworks or exotic libraries. - Do not optimize anything I have not explicitly asked you to optimize. - Do not add features that are not in the prototype. New features will be requested separately. ## Workflow for every task 1. Read relevant files in refs/. 2. Re-read this REWORK.md. 3. Propose a short plan before writing code. 4. Wait for approval. 5. Implement one area at a time. Small, reviewable steps. 6. After each step, tell me what changed and why.
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:
Read refs/REWORK.md first. It describes exactly what I want. Then read everything else inside refs/ — that is my current prototype. Before writing any code: 1. Produce a short plan: folder structure, main components, services, data layer, routes, and database schema. 2. List what you will keep from the prototype and what you will rebuild. 3. Wait for my approval. Only after I approve — begin implementing, one area at a time.
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.
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.
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.
This article was created in hybrid human + AI format. I set the direction and theses, AI helped with the text, I edited and verified. Responsibility for the content is mine.