TL;DR
- Trigger. A discovery call on Monday afternoon: three paper inspection forms, photos texted to dispatch, and a report that reached the site contact two days late.
- What shipped. A phone-first inspections app — sites, inspections, findings — with signature and photo capture, a technician queue, and a PDF report emailed on completion. Built through named platform operations, not generated code.
- Outcome. Working software in the Tuesday 10:00 AM meeting, run by a six-technician pilot the night before. Nothing metered. Rollout figures belong to the verified story.
The trigger
The operations director did not ask for software. She described a Monday: technicians finish an inspection, sign a paper form, text three photos to dispatch, and someone retypes the findings into a report that goes out Wednesday. Six branches, ~400 technicians, three versions of the form.
The next meeting was Tuesday at 10:00 AM with the VP of service. The sales engineer had a choice between a deck and the thing itself.
The 24 hours
- Monday · 2:00 PMDiscovery call. The operations director walks through the paper inspection: three form types, photos texted to dispatch, a report typed up two days later.
- Monday · 3:00 PMFirst prompt. Groups first, then sites, inspections, findings — in the provider's words. They say finding, not issue.
- Monday · 5:30 PMPreview diff: 3 objects, 3 forms, 1 workflow, 9 screens. One lookup pointed the wrong way; fixed before commit.
- Monday · 7:00 PMPublished with only Pilot Crew in the drawer — six technicians. Two of them ran a real inspection that evening on their phones.
- Tuesday · 8:00 AMSecond pass from pilot notes: severity list changed to their four levels, branch logo on the report. Preview, commit, republish.
- Tuesday · 10:00 AMWorking software in the room. The VP of service opens a PDF report generated from a real inspection. The conversation moves to rollout.
The clock runs from the first prompt to working software in the room. The pilot publish at 7:00 PM was real, on the technicians’ own phones; the meeting only made it visible to the person who could say yes.
What was built
Three objects, three forms, one workflow, two grids, nine screens — every one of them a governed platform primitive with a real table underneath. Objects carry the fsi_ prefix because solutions share a schema within an account.
The first prompt set the shape:
Build a solution called Field Inspections (prefix fsi_) for an HVAC services provider. Create groups Technicians, Dispatch, and Pilot Crew before anything else. Objects: Site, Inspection, Finding — they say finding, not issue. The Inspection form needs a signature; the Finding form needs a photo and a multiple-choice severity. Do not publish until I have read the preview.
The workflow came as a second, smaller prompt:
When an inspection is marked complete, generate the PDF report and email it to the site contact. Show me the diff before you commit.
preview-solution-edit returned an entity-level diff — three objects, three forms, one workflow, nine screens — and it caught the mistake: the finding lookup pointed at sites instead of inspections. Fixed in the same transaction, previewed again, committed as v1.
Published to the pilot crew, opened up on yes
For a platform app, “staging” is a group. publish-solution copies the working copy Current → Testing → Production in one shot; who sees the result is gated by groups, evaluated server-side. The first publish went out with only Pilot Crew in the drawer — six technicians, nobody else.
Their notes came back overnight: four severity levels, not five, and the branch logo on the report. Both changes ran in a new transaction on Tuesday morning — preview, commit, republish.
The yes in the room added Technicians and Dispatch to the drawer. The publish ran under the sales engineer’s own account and permissions; the agent acts with the builder’s token, never its own. Every save bumped a version, and the version before it stayed on record.
The meter never started. No tokens. No credits. No meter. You bring the AI subscription you already pay for.
Results
| Metric | Value | Source |
|---|---|---|
| Time to working software | 19 hours (example) | Builder log — sourced on sign-off |
| Builders involved | 1 | Builder-reported — sourced on sign-off |
| Paper form types replaced | 3 (example) | Customer-reported — sourced on sign-off |
| Report turnaround | ~2 days → same day (example) | Customer-reported — sourced on sign-off |
| AI cost metered by CodeMonster | $0 | License terms — nothing is metered |
Caveats, plainly: the values marked “(example)” are illustrative, and each one gets a named source the day the customer signs off. Nineteen hours is first prompt to working software, not contract to rollout. The pilot ran six technicians, not 400 — rollout figures belong to the verified story.
In their words
No quote yet. Quotes ship with the verified story: real words, real name and role, approved in writing before publication.
What the monster didn’t do
- It did not connect to the provider’s dispatch system. A workflow can post to Zapier, Make, n8n, or any HTTP endpoint; that step was scoped for rollout, not the first 24 hours.
- It did not migrate historical inspections. Bulk inserts exist; the provider chose to start clean.
- It did not configure single sign-on. The platform supports Auth0, SAML, Google, and Firebase; that conversation belongs to the provider’s IT, who received the security overview.
- It did not write or generate backend code. It assembled platform primitives through named operations — there is no pile of generated code to secure and maintain.
- It did not decide who sees what. The builder did, through groups, and the platform enforced it.
Builder’s notes
- Groups first. Create Technicians, Dispatch, and Pilot Crew before the first object, so every screen and action lands already gated. Adding groups after the fact means revisiting every drawer entry.
- Pick the tenant before you write.
use-tenantis explicit and per-session; a write without tenant context fails fast with “Tenant context required.” That is the platform being careful, not broken. - Read the preview diff like a pull request. It is entity-level, not a JSON patch. The wrong-way lookup was one line in the diff and would have been an hour of confusion on a phone.
Build this yourself
The field-service inspection blueprint is the primitives map and the starter prompt for this app. Swap the nouns for your prospect’s own; keep the shape.
Build a solution called Field Inspections (prefix fsi_) for a field-service prospect.
Create groups Technicians, Dispatch, and Pilot Crew first.
Objects: Site (name, address, contact email); Inspection (site, technician, date, status, signature); Finding (inspection, category, severity, photo, note).
Use their words for objects and fields — ask me if a term is ambiguous.
Generate the screens so a technician can work today's queue on a phone.
Add a workflow: when an inspection is marked complete, generate the PDF report and email it to the site contact.
Publish with only Pilot Crew in the drawer. Show me the preview diff before you commit.Then get the desktop app, connect the AI you already pay for, and start the clock. See also the field service use case.