Quick build: ship an app

Before we build anything, help me decide whether we should.

What I am thinking of building: <describe it in three sentences>.
Who would use it: <roles and rough numbers>.
What we use today: <spreadsheet / a product / nothing>.

Tell me honestly:
1. Is this a solved category where buying something would serve us better?
   Name what we would buy and roughly what it costs
2. What would we get from building that we could not buy
3. What is the ongoing cost of owning this: what breaks, what needs changing
   when our process changes, what happens if the person who understands it
   leaves
4. Is there a smaller version that gets most of the value

Give me a recommendation, and argue against it in a paragraph so I can see
the other side.

Before I approve this model, stress-test it against how our business actually
behaves.

Walk me through what happens in each of these, and tell me whether the model
handles it or needs changing:
- <a customer acquires another customer we also sell to>
- <a contact leaves and joins a different company we work with>
- <a record needs to belong to two parents at once>
- <a record is created by mistake and has already been referenced elsewhere>
- <two people edit the same record at the same time>

For each field you marked required, tell me what happens when someone does
not know the answer at the moment they are creating the record.

Then tell me the three ways this model is most likely to be wrong, and what
you would need from me to be sure.

We are going to build a CRM for our team. Before any code, propose the data
model and let me correct it.

About us: we sell <what you sell> to <who buys it>. A typical deal takes
<length> and involves <number> people on the customer side. Our sales stages
today are <list your stages>.

Propose:
- the record types we need and how they relate (companies, contacts,
  opportunities, activities, and anything else you think we need)
- the fields on each, marked required or optional, keeping required fields
  to the minimum a rep will actually fill in
- which fields we can populate automatically from data already connected to
  this box, so nobody types what we already know
- the stage list and what has to be true to move a deal forward

Then ask me the five questions whose answers would most change this design.

No code yet. Show me the model as a plain table I can read.

Build the core screens for the model we agreed.

- A pipeline board: deals as cards in stage columns, drag between stages
- A company page: details, contacts, open and won deals, activity history
- A contact page: details, the company they belong to, their activity
- A quick-add that creates a company, a contact, and a deal in one form
- A search box that finds anything by company or contact name

Design for a phone first. A rep updates this in a parking lot, one-handed.
Keep every form to the required fields, with everything else behind a
"more details" toggle.

Store data in this app's own database. Read from our connected systems and
change nothing in them.

Seed it with realistic sample data so I can click through it, and clearly
label that data as sample. Then give me the link to open it.

Replace the sample data with our real records.

Pull companies and contacts from <your source: accounting system, existing
CRM export, ERP customer table>. Match on <company name / customer number>
and tell me how many matched, how many were ambiguous, and how many were new.

For each company, pull in from our connected financial data:
- lifetime revenue
- revenue in the last twelve months
- date of last order
- current open receivable balance

Show those on the company page as read-only facts, with a note saying which
system each came from and when it last refreshed.

Before you import anything, show me twenty sample rows of what you are about
to load and the duplicates you found, so I can approve it.

Add access control and history.

- Everyone signs in
- Reps see and edit their own accounts and deals
- Managers see and edit their team's
- Executives see everything, read-only by default
- Nothing is ever hard deleted. Mark records inactive and keep them
- Record who changed what and when, and show that history on each record

Then add the two things that make people keep using it:
- a "my week" view showing my deals that need attention: no activity in
  fourteen days, close date in the past, or stuck in one stage over thirty days
- a weekly summary of pipeline movement I can read on a Monday

Tell me how to add a user and assign them a role.

We are going to build a job scheduler. Before any code, propose the model.

About us: we schedule <what: service calls / installs / production runs /
deliveries> against <who or what: technicians, crews, machines, trucks>.
A job takes <typical duration> and we schedule <how far ahead>. Today this
lives in <whiteboard / spreadsheet / shared calendar>.

Propose:
- the record types (jobs, resources, assignments, customers, and anything
  else) and how they relate
- job statuses and the legal transitions between them
- what makes an assignment invalid: double booking, missing skill,
  outside working hours, insufficient travel time
- which of this we can populate from data already connected to this box,
  for example open work orders

Then ask me the five questions that would most change the design.

No code yet.

Build the scheduling screens.

- A week view: resources down the side, days across the top, jobs as blocks,
  drag to reschedule or reassign
- A day view for the dispatcher, denser, with travel gaps visible
- An unscheduled queue beside the calendar: jobs needing a slot, sorted by
  promised date, drag onto the board
- A job detail page: customer, location, description, status, assigned
  resource, notes, history
- A "my day" mobile view for the person doing the work: today's jobs in
  order, tap to see details, tap to mark started or complete

Warn on conflicts rather than blocking them. The dispatcher knows things the
system does not, so show the warning and let them proceed.

The mobile view is the one that matters most. Big touch targets, readable in
sunlight, works on a bad connection.

Seed realistic sample data, label it as sample, and give me the link.

Connect the real work.

Pull open jobs from <your source: ERP work orders, service tickets, order
system>. Bring across customer, location, description, promised date, and
priority. Refresh <every 15 minutes / hourly> and tell me how you are
handling a job that changes in the source after we have scheduled it.

Pull the resource list from <your source: HR system, equipment register>,
including any skill or certification fields we can use for assignment rules.

Before importing, show me twenty sample rows and any records you could not
map, so I can approve it.

Add access control and the operational extras.

- Dispatchers can schedule and reassign anything
- Field staff see only their own assignments and can update status
- Managers see everything, read-only
- Record every schedule change with who, when, and what changed

Then add:
- a daily schedule summary the dispatcher can send out each morning
- a simple utilization view: scheduled hours versus available hours per
  resource per week
- a flag for jobs at risk of missing their promised date

Tell me how to add a user and assign them a role.

We are going to build a monthly financial review app that replaces the deck
we rebuild by hand every month.

About us: our fiscal year starts in <month>. We close the books around day
<number> of the following month. The review is read by <who> and the
recurring arguments are about <what: allocations, timing, which entity>.

Propose the structure:
- the sections of the review, in the order a reader wants them
- which numbers appear in each, and where each comes from in our connected
  data
- where a human needs to add commentary rather than the system explaining it
- what "this month is closed and approved" should mean, and who says so

Then ask me the five questions that would most change this.

No code yet. Show me the outline.

Build the review for a selected month.

- A month picker at the top. Everything below reflects the chosen month
- Executive summary: revenue, gross margin, operating expenses, net, cash,
  each with change versus prior month, versus same month last year, and
  versus budget if we have it
- Revenue detail by <product line / division / entity>, with variance
  explanations where the change exceeds <threshold>
- Expense detail by category, ranked by variance to budget, largest first
- Cash: opening, in, out, closing, plus receivables and payables aging
- A commentary box under each section where a human types the explanation,
  saved with the month

Every calculated figure must be traceable: clicking it shows the query and
the underlying records.

Label anything AI-generated as commentary, clearly separated from calculated
figures, so a reviewer always knows which is which.

Seed with our real data for the last three closed months and give me the link.

Add the month-end workflow.

Statuses: Draft, In Review, Approved. Only <role> can approve.

Once a month is approved:
- freeze the figures so the page always shows what was approved, even if the
  underlying data changes later
- keep a note of any subsequent change in the source data, so we can see
  drift without the approved numbers moving

Add a comparison view: put any two approved months side by side.

Add an export that produces the same content as a document I can attach to
a board pack.

Automate the assembly.

On day <number> of each month, create next month's review in Draft with all
figures populated, and notify <role> that it is ready for commentary.

For each variance over <threshold>, pre-draft one sentence of explanation
based on the underlying transactions, clearly labeled as a suggestion for a
human to confirm or replace.

Send a reminder if a Draft review is still unapproved after <number> days.

Tell me where the schedule is configured so I can change the dates myself.

We are going to build an approvals app. Before any code, propose the model.

The request types we want to start with: <for example purchase orders,
expense claims, time off>. For each, tell me what you think the form needs.

Our approval rules today, as best I can describe them:
<for example: anything under $500 the manager approves; $500 to $5,000 also
needs the department head; over $5,000 also needs the CFO; anything for a
new vendor always needs finance>

Propose:
- the record types and how they relate: requests, request types, approval
  steps, approvers, attachments
- how the approval chain is described, so we can change a threshold later
  without rebuilding
- what happens when an approver is away, or when a request sits unanswered
- what statuses a request moves through, and who can move it
- which fields we can fill automatically from data already connected to
  this box, for example budget remaining or vendor status

Then ask me the five questions that would most change this design.

No code yet. Show me the model and the rule structure as tables I can read.

Build the core screens.

- Submit a request: pick a type, fill a short form, attach files, see who
  will need to approve it before you send
- My requests: everything I have submitted, current status, where it is
  sitting and with whom, how long it has been there
- My approvals: the queue of things waiting on me, oldest first, with
  approve and decline on the same screen and a required reason on decline
- Request detail: the form, the attachments, the full approval trail with
  timestamps and comments
- An admin view listing every open request across the company

Design the approval queue for a phone. Approvers do this between meetings,
and the whole interaction should be readable and answerable in one screen.

Show the requester exactly who is holding the request right now. That single
piece of information removes most of the chasing.

Seed realistic sample data, label it as sample, and give me the link.

Connect the real context, so approvers can decide without leaving the screen.

Pull the people and reporting lines from <your source: HR system, directory>
so the approval chain follows the real org chart rather than a list we
maintain by hand.

For purchase requests, show on the request itself:
- budget remaining for that <department / cost center> this period
- what we have spent with that vendor in the last twelve months
- whether the vendor is already approved and set up for payment

For expense claims, flag anything outside policy: over a limit, missing a
receipt, or a duplicate of another claim.

Before you connect anything, show me where each figure comes from and how
fresh it is, so I can confirm an approver would be right to rely on it.

Add the rules that make this survive real use.

- Delegation: an approver can nominate a delegate for a date range, and the
  trail records that a delegate acted and on whose behalf
- Escalation: if a request sits unanswered for <2 working days>, remind the
  approver; after <4>, notify their manager
- Recall: a requester can withdraw a request that has not been fully approved
- Resubmit: a declined request can be edited and resubmitted, keeping the
  original and the reason it was declined
- Nobody can approve their own request, at any threshold

Make the audit trail complete and permanent: who did what, when, from where,
and what the request looked like at that moment. Approved requests are never
edited afterwards.

Then give me an admin screen where I can change thresholds and approval
chains myself, without needing another build.

Fill this app with test data that looks like our real data rather than
tidy examples.

Include the awkward cases on purpose:
- names with apostrophes, accents, and ampersands
- very long names that will test the layout
- records with optional fields empty
- two records that are near-duplicates of each other
- dates at period boundaries: the last day of a month, a leap day, a weekend
- amounts that are zero, negative, and very large
- a record in every status, including the rare ones
- at least one record for every user role

Label all of it clearly as test data and tell me how to remove it in one
step later.

Then screenshot or describe anything that looks broken with this data in it.

Walk through what happens in each of these and tell me whether the app
behaves sensibly. Fix nothing yet, just report.

- Someone submits a form with every optional field blank
- Someone submits the same thing twice by double-clicking
- Two people edit the same record at the same moment
- Someone opens a record, leaves for an hour, then saves
- A required source system is unavailable when a page loads
- Someone reaches a record they should not have access to by typing its URL
- Someone uploads a file that is too large, or the wrong type
- The list view has 50,000 records in it
- Someone uses the browser back button in the middle of a multi-step form

For each, tell me what happens now, what should happen, and how bad the gap is.

Test the access rules by acting as each role rather than by reading the code.

For every role we defined, list:
- every screen that role can reach
- every record that role can see, and confirm it cannot see the others
- everything that role can create, edit, and delete
- what happens when that role types the URL of a record it should not see

Pay particular attention to:
- list and search results, which often leak records the detail page blocks
- exports and downloads, which often ignore the filters applied on screen
- any report or summary that aggregates across records

Give me a table of role against permission, and flag every place where the
behavior differs from what we agreed in stage 4.

We are about to give this app to real users. Review it and report back
before I invite anyone.

Check and tell me:
1. Who can currently reach this app, and what an unauthenticated visitor sees
2. Every screen that writes data, and what stops a user writing something
   they should not
3. What happens when a required source is unavailable: a clear message, or
   a broken page
4. Whether any screen exposes data a given role should not see
5. What is hard deleted anywhere, and whether it can be recovered
6. How it looks and behaves on a phone
7. Anything you built with sample or placeholder data still in it

For each problem, tell me the severity and the fix. Fix nothing yet.

I want to change this app: <describe the change>.

People are using it and there is real data in it, so plan before you build.
Tell me:
1. What existing records this affects, and how many
2. Whether any data has to be converted, and what happens to records that
   cannot be converted cleanly
3. What happens to work that is part-way through the current workflow
4. Whether anyone sees anything different, and whether they need warning
5. How we undo this if it goes wrong
6. Whether the app is unavailable at any point, and for how long

Show me the plan. Change nothing until I say so.

Set up a regular export of everything created in this app.

- <Weekly>, export every record and its history to <a location we agree>
- Use an open format anyone can read without this app: CSV or JSON
- Include the history and audit trail, not only the current state
- Keep <12> copies before overwriting the oldest
- Tell me if an export fails

Then show me one export now, and walk me through what I would do to read it
if this app were unavailable.