TL;DR
- Trigger. Assistance requests arriving through three channels into a spreadsheet, and two of them missed over a long weekend.
- What shipped. One public request form, a triage queue for the intake team, follow-ups with owners and due dates, and two email workflows — one to the team on submit, one to the requester on triage.
- Outcome. Working software before Thursday’s standup, 16 hours after the first prompt, from a business systems analyst on the operations team. Nothing metered. First-month figures belong to the verified story.
The trigger
The executive director did not ask for a portal. She asked for one place. Requests came in through a website form that emailed an inbox, through direct email, and by phone onto sticky notes; a spreadsheet tracked what someone remembered to enter, and over a long weekend two requests sat with no owner.
The analyst who built the spreadsheet offered to replace it before Thursday’s 9:30 AM standup.
The 24 hours
- Wednesday · 2:00 PMProgram directors' meeting. Assistance requests arrive by web form, email, and phone; a spreadsheet tracks them; two were missed over a long weekend. The executive director asks for one place.
- Wednesday · 4:00 PMFirst prompt. Groups Intake Team and Program Leads first. Objects requests, programs, follow-ups — pip_ prefix. Tenant selected before the first write.
- Wednesday · 6:00 PMRequest form set to public: anonymous submissions land as tenant-scoped rows with a change log. Preview diff: 3 objects, 3 forms, one public flag, 9 screens.
- Wednesday · 7:30 PMWorkflows: submit → email the intake team; triage → email the requester a reference. Committed as v2. Published with only Intake Team in the drawer.
- Thursday · 8:00 AMWorking software. The intake team enters Wednesday's emailed and phoned requests through the form and triages them; the first requester gets a reference by email.
- Thursday · 9:30 AMShown at standup. Program Leads get read access; the website's old form now points at the new one.
The clock runs from the first prompt to working software — the intake team triaging real requests at 8:00 AM — not to the standup that showed it.
What was built
Three objects, three forms, two workflows, two grids, nine screens. The request form is public: anonymous submissions are allowed and land as tenant-scoped rows, and the object change log records every edit that follows. Objects carry the pip_ prefix.
The first prompt:
Build a solution called Assistance Intake (prefix pip_) for a housing nonprofit. Create groups Intake Team and Program Leads before anything else. Objects: Request, Program, Follow-up. The Request form must accept public, anonymous submissions and keep a change log. Requests have a program, a preferred contact method, a status, and an owner. Give me a grid of new requests by program, oldest first. Preview before commit; do not publish yet.
The workflows came second:
When a request is submitted, email the intake team. When a request is triaged, email the requester their reference number and the program it went to. Show me the diff before you commit.
preview-solution-edit returned the entity-level diff — three objects, three forms, two workflows, nine screens, and one form-settings change flipping the request form public. The analyst read that last line twice, then committed v2.
Published to the intake team, opened up on yes
There is no staging tier to hold this in. publish-solution copies the working copy Current → Testing → Production in one shot, and the audience is what you gate: the drawer, the actions and the grids answer to groups, evaluated server-side. The first publish had only Intake Team in the drawer.
The public form could take submissions from that moment — that is the point of a public form — but its link had gone to nobody outside the team, and only the team could see the queue.
Thursday’s yes at standup added Program Leads with read access and swapped the website’s old form for the new link. The analyst published from her own session; her permissions were the ceiling, not the agent’s. IT got the security overview and the data and tenancy page the same morning.
Nothing was metered — not the build, not the first morning’s submissions, not the queue. No tokens. No credits. No meter. You bring the AI subscription you already pay for.
Results
| Metric | Value | Source |
|---|---|---|
| Time to working software | 16 hours (example) | Builder log — sourced on sign-off |
| Builders involved | 1 | Builder-reported — sourced on sign-off |
| Intake channels consolidated | 3 → 1 (example) | Customer-reported — sourced on sign-off |
| Requests missed, first month | 0 (example) | Customer-reported, their own inbox count — sourced on sign-off |
| AI cost metered by CodeMonster | $0 | License terms — nothing is metered |
Caveats: values marked “(example)” are illustrative, and each one gets a named source the day the organization signs off. “Requests missed” is the organization’s own count against its inbox, not a platform measurement. Sixteen hours is first prompt to working software; the old channels were retired over the following weeks.
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 decide eligibility. The workflow routes and notifies; program staff decide, and the change log records who decided what.
- It did not replace case management. Follow-ups are a start, not a case file.
- It did not take phone intake. Staff enter phoned-in requests through the same form — one place.
- It did not translate the form on day one. The platform supports translations; the Spanish version came in a later transaction, and that date belongs to the verified story.
- It did not write backend code. It assembled platform primitives through named operations — a public form on a real table with a tenant on every row, not a script someone now has to patch.
Builder’s notes
- Create the groups before the first object. Read-only for Program Leads was then one permission change on the day of the yes, not a rebuild.
- Pick the tenant, then check
whoami. A public form takes anonymous submissions, but the rows still land in a tenant. Selecting it explicitly before the first write is what keeps three counties’ requests from mixing. - Read the preview diff for the public flag. Flipping a form public is a one-line change in an entity-level diff. Read it, know it is the right form, then commit.
Build this yourself
The intake form and survey blueprint is the primitives map and the starter prompt for this app. Swap the program names for yours; keep the shape.
Build a solution called Assistance Intake (prefix pip_) for a nonprofit that takes public requests.
Create groups Intake Team and Program Leads first.
Objects: Request (program, name, preferred contact, summary, status, owner); Program (name, lead); Follow-up (request, owner, due date, note).
The Request form must accept public, anonymous submissions and keep a change log.
Give me a grid of new requests by program, oldest first, and a grid of follow-ups due this week.
Add workflows: on submit, email the intake team; on triage, email the requester their reference.
Publish with only Intake Team in the drawer. Show me the preview diff before you commit.Then get the desktop app, connect the AI you already pay for, and send the link to your IT approver along with the intake forms and surveys use case.