Skip to content
implement.sh

Scope your app
in six turns

A principal architect interrogates your idea — pushing back, cutting v1 down, naming what breaks. You leave with the blueprint and the prompt that builds the prototype.

No account. Roughly eight minutes.
Your email is asked for at the end, not the start.

ALT 42°06:20PROBLEM &USER08:12CORE LOOPCLIENTALLOTMENTDRAWINVOICE10:05ENTITIES &STATE11:40EDGES &INTEGRATIONS12:00MVP BOUNDARYLEFT IN SHADOWLive timers and idledetectionNobody disputes thestopwatch, they dispute…Per-task time entryJira already holds thetasksAutomatic invoicingNeeds the overage rulesettled first

Example section · Retainer · swipe to pan

Five bays. The sun crosses them once.

The interview is bounded on purpose. Depth past the boundary costs you a decision, not an insight — so each bay gets settled and left behind.

  1. 06:20Bay 1

    Problem & User

    Who has this problem, and what does solving it look like in a number?

  2. 08:12Bay 2

    Core Loop

    The path from arriving to getting value, walked end to end.

  3. 10:05Bay 3

    Entities & State

    The objects a database would need, and who is allowed to read them.

  4. 11:40Bay 4

    Edges & Integrations

    Auth, payments, third parties, and everything that fails at 3am.

  5. 12:00Bay 5

    MVP Boundary

    What ships in v1, what waits, and what gets cut for good.

It disagrees
with you

An intake form records what you already believe. This does the opposite: it finds the assumption holding up your plan and pulls on it, then proposes the cheaper shape.

Example exchange · turn 2

Client

It’s like Harvest but for retainers. Agencies sell 40 hours a month and we track the hours.

Architect

Harvest measures work as it happens. A retainer is something else: a prepaid balance granted on the 1st that expires on the 31st. Nobody has ever argued about the stopwatch — they argue about what happened to the eleven hours they didn’t use.

So the entity is an allotment with an expiry, and a draw against it. Which means v1 doesn’t need a timer at all: the account lead types one number a week. No start/stop UI, no browser extension, no idle detection — call it two weeks off the build.

The question that decides the schema: when the month turns, do leftover hours expire, roll over, or partially roll?

Two drawings leave the studio

One is written for you. One is written for the machine that builds it. They are never the same document.

The blueprint

Sent to your inbox

Executive summary, the core loop, what v1 contains and what it deliberately leaves out, the data underneath, the architecture, and what could go wrong.

# Retainer

## What v1 contains
- **Hours drawn against a monthly allotment** — the account lead types one number a week. This is the only figure the client and the agency currently disagree about.
- **Client-facing balance page** — read-only, shows granted, drawn, remaining, and the expiry date. Removes the recurring email thread without any write path for the client.

## What v1 deliberately leaves out
- **Live timers** — nobody disputes elapsed time, they dispute the rollover rule. Timers cost weeks and settle nothing.

Example output

The implementation prompt

Held for your build

Schema, server functions, route tree, screen-by-screen states, seed data, and a build order. Dense on purpose — a coding agent reads it once and starts.

## Domain model

```sql
CREATE TABLE allotment (
  id         TEXT PRIMARY KEY,
  client_id  TEXT NOT NULL REFERENCES client(id),
  hours      REAL NOT NULL,
  granted_at INTEGER NOT NULL,
  expires_at INTEGER NOT NULL
);
CREATE INDEX allotment_open ON allotment(client_id, expires_at);
```

Remaining is `allotment.hours - SUM(draw.hours)`, never a stored column — a corrected draw has to move the balance with it.

## Build order
1. Schema + seed three clients and the current month's allotments.

Example output

Everything is dark until it is drawn

When you want the prototype built from the prompt, reply to the report or write to hello@implement.sh.