Guide · 8 min read
How to create a web app from a description
A practical sequence: what to write in the first message, how to read the result, and when to publish.
Write the job, not a slogan
The first message decides the shape of the web app. “Make me a startup” produces a costume. A useful description names who uses it, what they do in a sitting, and what must still be there tomorrow.
Here is a description that is specific enough to build from, using a neighbourhood bakery as an example. It is an example, not a customer.
A web app for a bakery counter. Staff see today’s orders, mark one as ready, and add a walk-in order with a name, a pickup time, and two or three items. The owner can edit the short menu and see which items were ordered today. Keep it to those screens. Store orders and menu items in the database.
That paragraph has actors, actions, and data. You can be someone who writes code every day or someone who never has. The description is the same kind of work either way: say what the web app must do, and leave out the parts you do not need yet.
Open a project
Go to spinbuild.ai and start on the Starter plan. It is free and does not ask for a credit card. Create a project and paste the description. If you already know you care which model writes the first version, pick one before you send. A faster model is enough for a small, well-described web app. A stronger model is worth the credits when the description has several screens and rules that must not be simplified away.
Send one job. Do not attach a roadmap. “Also add delivery, loyalty, and a blog” in the same breath makes the first diff harder to review. You can ask for those after the counter flow works.
Read what came back
SpinBuild proposes files. You are looking for three things, even if you do not read every line:
- A frontend that matches the screens you named.
- A backend that saves and loads those screens.
- A private Postgres database for this project, not a shared scratchpad.
The change is a diff. Accept it when it matches the description. Reject it when it invented a feature, dropped one you asked for, or wrote something you do not want in the project. Rejection is a normal step, not a failure. Then say what was wrong, in one or two sentences, and let the next diff answer that.
Look at it before you publish
Run the preview. It is private, for you, while you click through the flow you described. For the bakery example that means: add a menu item, place an order, mark it ready, and refresh to see that the order is still there. If a click does nothing, say so in the chat and point at the screen. “The ready button does not change the order” is a better follow-up than “make it better.”
When the private preview behaves, publish. The live address looks like your-app.apps.spinbuild.ai and it is HTTPS. That is the URL you can send. It is not a custom domain.
Keep a copy if you want one
You can push the project to a GitHub repository you own. That push is one way. It gives you the code. It does not watch the repository and pull other people’s commits back into the builder. If you want that copy, connect GitHub after the web app is in a state you have accepted, not in the middle of a rejected diff.
Then stop. A small web app that does the one job is finished enough to use. The next change should be the next real job, described the same way: who, what they do, what must be stored.