This is the objection that stops most people from starting, and it rests on a false assumption: that your description would go straight to code with no way back. That isn't the sequence. Your description first produces a PLAN — the list of data, screens and screen types — which is shown to you and which you correct BEFORE a single line of code exists: rename an entity, fix a field name, add or remove a status value, even change what kind of screen something is. At that stage, getting it wrong costs nothing. After generation, changes are still possible by describing them in plain language, but that rebuilds and revalidates the application: a heavier move, not a tweak.
The mistake people fear isn't the one that happens
The fear is handing over a vague description and receiving a tool that misses the point, with no recourse. In conventional projects that fear is well founded: the brief goes to a supplier, the first screen arrives weeks later, and the gap is paid for in development days. It is that delay — not the difficulty of writing — that makes the exercise daunting.
The literature on requirements says the same thing from another angle: the hard part isn't writing it down, it's knowing what you want before you have seen anything. People don't guess their own working habits; they recognise them once they are laid out.
The plan is shown before the code, and it is editable
Between your description and the application there is an intermediate step: a plan. It lists the data the tool will handle, their fields, and the screens with the TYPE of each — a table, a calendar, a dashboard, a map. That plan is displayed and editable.
In practice, at that point you can rename a data type and its label, fix the fields it carries, add or remove a value from a status list ("Pending", "Approved", "Cancelled"), rename a screen, change its icon — and change its nature: a list that should have been a calendar is fixed right there, in one go.
This is what makes the objection moot. A rough description commits you to nothing: it produces a proposal you read back, and correcting a word in the plan amounts to exactly the same thing as having written it correctly the first time.
After generation: still possible, but no longer the same move
Once the application exists, a change is still requested in plain language — "add a field for the follow-up date", "split quotes from invoices". The difference lies elsewhere: that request regenerates the plan, rebuilds the application and puts it back through automated validation before returning it to service. It is dependable; it is not instant.
Hence the only practical advice on this page: reading the plan deserves five minutes of real attention. They are the cheapest five minutes of the project.
What to know before changing an application already in use
Two points cannot be guessed, and are worth settling before running a change against a tool that already holds your real data.
First: what happens to data already entered when the structure changes (a field removed, one data type split in two). I am not asserting it here — it is a question to ask explicitly before modifying a live application, here as with any vendor.
Second: there is no "revert to the previous version" button. Rolling back is something you prepare, not something you improvise — hence the value of exporting your data before a structural change, which the Settings screen supports in CSV and JSON.