IN SHORT
- You describe, it asks, it builds and publishes, you use the real thing, you say what is wrong.
- The questions it asks back are the ones that change the answer — not a form of forty fields.
- Describe how the work flows and where it breaks, not what to build.
- Corrections work best as symptoms: what is wrong, rather than your guess at the fix.
The loop
| Step | Whose it is | What happens |
|---|---|---|
| 01 You describe it | Yours | In your own words, the way you would say it out loud to a new member of staff. |
| 02 It asks what it needs to | The studio’s | Only the questions that change the answer — who else uses this, what happens when two people book the same slot. |
| 03 It builds and publishes | The studio’s | Screens, database, rules and the address to reach them. You watch it work rather than waiting for an email. |
| 04 You use the real thing | Yours | Not a preview — the actual system, with your data, on your phone and the office computer. |
| 05 You say what is wrong | Yours | Each correction is another sentence, and the loop starts again. |
What a sentence turns into
None of these are settings that happened to exist and were switched on. Each one is written for your system at the moment you ask for it.
| What you type | What comes back |
|---|---|
| “I need to see which invoices are unpaid.” | A screen listing them, oldest first |
| “Add the car’s registration number.” | The field, in the form and the list, on existing records too |
| “Email me a summary every Monday at eight.” | A job that runs whether or not anyone is logged in |
| “Clients should book their own appointments.” | A public booking page and a confirmation email |
Describing it so you get what you meant
The single largest factor in whether the result fits is how the request was described. Describe how the work flows rather than what to build. Start with the volume, say who touches it, say where it breaks today, and say what should happen rather than how it should be implemented.
“Make me a CRM” gets you a guess. “Thirty enquiries a week, two of us answer them, and we lose track once a quote is sent” gets you the thing you actually needed. Long is fine; vague is not. Include the awkward case — the customer who pays in two instalments, the job that gets cancelled after the parts are ordered — because the awkward case is what the software will be judged on.
Correcting it
When something is wrong, describe the symptom rather than prescribing the fix. “The list is unusable on the van’s tablet because the columns run off the side” tells the studio more than “make the table narrower”, and leaves it free to solve the actual problem.
Ask for one thing at a time. Six requests in one sentence produce a build that is right about four of them, and unpicking which four costs more than asking separately would have.
What it costs while you do this
Every build and every change consumes credits — a few for a field, more for a screen or a report. Simply using the finished system costs almost nothing. The month you build the first version is the heavy one; after that most businesses use a fraction of the allowance.
RELATED
Tutorial: describing what you need — the most useful page here if you are worried you are not technical enough
Tutorial: your first change — the loop on something small enough to check in ten seconds
Credits and billing — what building actually consumes