How it works
Job description in. Working software out.
The method behind every build. It works because of one bet: a team can dismiss a deck in nine seconds. They cannot dismiss a working tool that solves a problem only someone who understands their job would know they had.
01
Send the job description
Or the posting, or a page of notes on what the team does all day. That is the brief. For companies we add a 20-minute call with three questions.
02
We read it for the verbs
Recruit, vet, negotiate, whitelist, pay, report. The verbs, in the order they actually happen, become the nav. Then we find the two to four things your program does that a neighboring industry does not. Those get built properly. Everything else gets built competently.
03
You log in
A password-protected site, on your domain if you want it, with real screens that do something. Sample data is labeled as sample data. Nothing unverified shows as a number. You review once at the halfway point.
04
It keeps running
The monthly plan hosts it, maintains it and grows it as the program grows. Every decision the tool enforces is written down so the team runs one way, even when people change.
The rules every build follows
- The nav is the argument. Grouped by the job someone is doing, ordered the way the work happens. Not by feature.
- A check nobody ran is not a pass. Every gate is pass, fail, or not run. Green means clear. Grey means nobody checked. They are never blurred.
- Numbers are real or they say they are not. Sample data is labeled. Unverified figures render as needs verification instead of being invented.
- Two to four modules get built properly. The ones with no equivalent in a neighboring industry. Everything else is competent and quiet.
- Decisions are written down. Every hard call the tool enforces has a title and a paragraph on what the alternative costs, so the team runs one way even when people change.
- It works on a phone. They will open it on one.
Questions
- Is this a template?
- No. The scaffold (login, nav, design system, the pass/fail/not-run pattern) is shared. Everything a viewer looks at is built from your job description and your workflow. The two to four modules that define the tool do not exist until we read your posting.
- What do you need from us?
- The job description or a page of notes. For company builds, a 20-minute call with three questions: what does this team do every day that no neighboring team does, what decision are you most afraid of getting wrong, and what does done look like in 90 days. Then your real data when you are ready to move off the sample set.
- Where does it live?
- On Vercel, password-protected, on a subdomain of ours or a domain of yours. Source is yours on company builds. The monthly plan keeps it hosted, maintained and evolving.
- What about our data?
- Spec builds contain none of it. Company builds start on labeled sample data and move to yours behind your login. Nothing unverified is ever shown as a number; it renders as needs verification.
- How is a spec build different from a client build?
- A spec build is made from a public posting, unasked, so you can see what the role's team would run on. A client build is scoped with you, built on your workflow, and handed over with the decisions written up.
- Can it connect to our affiliate network, ad accounts, or e-signature?
- Yes, that is what the monthly plan is for. Impact, Levanta, ShareASale, Meta and TikTok whitelisting status, DocuSign-style signing, and payout exports are each a scoped integration on top of the build.