You describe the thing, the model writes and deploys it, and you iterate in plain language. The skill is knowing what to specify.
The honest framing: this is genuinely transformative for internal tools, prototypes, forms, trackers, dashboards and small utilities, the enormous category of software that was never built because it could not justify a developer. It is not yet a replacement for engineering on anything with real scale, complex state, or a security surface.
Knowing which side of that line your idea sits on is the skill. Tools today: Base44, Emergent, Claude.
The single biggest quality lever is writing the spec in a chat model first, then handing the finished spec to the builder. One page: what it does in one sentence, who uses it and what each can see and do, the screens listed, the data and its shape, what happens when things go wrong, empty states, bad input, no results, and what it explicitly does not do in version one. That last line is the one people skip and the one that saves you, because scope creep in a chat interface is frictionless and therefore constant.
Ask for one change at a time and check it works before the next. A pile of simultaneous changes gives you a broken app and no idea which change broke it, the same one variable discipline as Day 3, applied to software. When something breaks, paste the actual error text, not it doesn’t work. The error message is the single most useful thing you can give the model.
Everything works when the person who specified it uses it as intended. Real users do not. Before you send a link to anyone: submit the form empty, type text where a number belongs, double click submit, paste two thousand words into a name field, open it on a phone, refresh mid way through. Fix the top two failures. This ten minute pass is the difference between a demo and a tool.
Before you build anything you intend to depend on. Where does the data live, and can I export it, no export path means you are renting your own data. What does it cost at ten times the usage, free tiers end exactly when the thing becomes useful. Who maintains it in a year, an app nobody owns is technical debt with a login page. Answer these in writing, they belong in the one page spec.
If your app touches personal data, client information or anything regulated, know where it is hosted, who can reach it, and whether authentication is real or decorative. A generated app with an unprotected link is a data breach waiting for someone to guess a URL. In our market that is a client problem, not an IT problem.
NOVA reacts, nothing is scored, nothing is stored against you.
Build something you personally need: an attendance tracker, a revision planner, a booking form. Write the spec with Claude first, then paste it into Base44 and publish it. Send the live link to one real person and get one piece of feedback.
Build an internal tool that removes a genuine weekly cost, such as a request intake form that routes to the right person, or a client reporting dashboard. Specify authentication, roles and data retention up front. Confirm the export path and pricing model before you commit. Deploy on a custom domain and document how a colleague would maintain it.
Day 10 in progress
Tomorrow, Day 11, Phase 3 begins: automation. The boring parts of your week are about to disappear.