Bookkeepers, agencies, consultants, financial advisors, law firms and MSPs all run the same process dozens of times a year: get a new client from "signed" to "actually able to work with." It is a known, repeatable sequence, and almost nobody has it written down anywhere except in the head of whoever does it.

So it happens in email. The business sends a welcome note with four attachments and six questions. The client answers two of them. Three days later someone sends a follow-up. The W9 arrives in a reply-all that buries the intake form.

Where are we with this client?

In a thread, nobody can answer that. This is what replaces it, and it is the flow generated by the one sentence at the top of this page: the client opens a single link with no account and no password, works their steps in order, and watches a progress bar fill in. The business sees the same state without asking anyone.

"The product is not a checklist. It is the removal of the chasing."

The cost is real on both sides. The business burns senior hours on administrative follow-up and pushes back the date it can start billing. The client's very first experience of a firm they just hired is being nagged. Time to first value is the metric that matters, and email is actively hostile to it.

The tools that exist do not fit. Asana, Notion and Monday are generic project tools that require the client to have an account and learn a workspace, which is a non-starter for someone who just wants to send you a tax document. The purpose-built onboarding tools are largely template libraries: they still expect you to build every flow by hand.

Each decision in the product traces back to a specific reason the existing approach fails.

The core interaction is deliberately small. You type something like "onboard a new bookkeeping client for monthly close" and the model returns a complete, structured onboarding: an ordered checklist, intake forms with the right questions for that engagement, and the specific document requests it implies.

Critically, the model does not generate a document or a blob of text. It generates a structured schema the product already knows how to render, which is what keeps the output inside the guardrails of the app rather than becoming free-form content nobody can act on.

• Generate from a prompt. One sentence, optionally seeded from an existing template, becomes the full block structure.
• Generate from your existing paperwork. Attachments are text-extracted on the client, clamped, and folded into the prompt, so a process you already run on paper becomes a working flow without retyping it.
• Edit by conversation. Ask for a step to be added, a task split, or a question rewritten, and the edit applies to the live structure. Edits stage the identical job shape as generations, so a single poll handler serves both paths.
• Summarize on the way out. When a client finishes, the model reads what was actually submitted and writes the owner a plain summary of it.

The product framing that made this work is that AI is the setup cost eliminator, not the product itself. The durable value is the portal, the tracking and the automated reminders. AI is what gets you to a populated, correct flow in fifteen seconds instead of forty minutes, which is the difference between a tool someone tries once and a tool someone adopts.

I built the product to be fully usable with the AI turned off, and only then made the AI good. That ordering was the single most useful decision in the project.

• Ship the boring core first. Templates, onboarding instances, the magic-link client portal, file uploads, reminders and the activity log all work with no model involved. AI accelerates that core; it is not load-bearing for it.
• Build a deterministic mock provider. The whole product runs end to end with no API key, which keeps local development and the test suite fast, free and repeatable.
• Then make generation real. Swap the provider by environment variable, with the model and its reasoning effort configurable the same way, so tuning never requires a code change.
• Design for the model being slow and wrong. Async jobs for the latency, schema sanitization for the correctness, per-tenant rate limits for the cost.
• Test the parts that have right answers. Fourteen backend service suites plus nine Playwright end-to-end specs covering auth, the client portal, the dashboard, responsiveness and accessibility.

Everything is serverless, single region, and deliberately simple to operate for one person.

OnboardMap is live at onboardmap.com with 22 paying customers. I built it solo and outside of work, and the whole thing, the AI pipeline, the serverless backend, the React application and the marketing site, went from empty repository to a working product in three days.

Twenty-two customers is validation, not a business. What I take from it is narrower and more useful: people in this category will pay for a tool that removes the chasing, and they will do it without a sales call. The number I actually watch is whether an owner sends a second onboarding after their first one, because that is the only signal that the product beat the email thread it replaced.

The marketing site is its own proof point. An unattended agent researches, writes and publishes a new article to it every morning, which has built a library of 159 pieces of organic search content without me writing them. It is the same thesis as the product, pointed at distribution instead of setup: use the model to erase the cost of the work that otherwise simply does not get done.

This is the part I would want to talk through in an interview, because calling a model is trivial and everything else is not. A generation is slow, non-deterministic, occasionally malformed, and costs money per call. A business that pays for the product needs it to feel as dependable as a form.

• Latency is an architecture problem, not a spinner problem. The 29 second API Gateway ceiling is a hard wall. Moving generation onto a background Lambda with a long timeout and a polling contract meant model quality was never constrained by an HTTP limit.
• Treat model output exactly like user input. It gets validated and coerced into the schema before it is stored. Nothing the model returns is trusted enough to persist directly.
• One job shape for every async AI action. Edits stage the same record as generations, so the poll handler reads both verbatim. Adding a third AI action costs almost nothing.
• A mock provider is a first-class feature. Being able to run and test the entire product with no model is what kept the AI from becoming a hard dependency for every developer, test run and CI job.
• Rate limit before you need to. Per-tenant limits existed before launch, because the failure mode of a metered dependency in a multi-tenant product is a bill, not an error page.
• Keep the model swappable. Model choice and reasoning effort are environment configuration. This category moves monthly, and anything that requires a deploy to change will not get changed.

Worth being precise about what the AI did and did not do here. Claude wrote most of this code, and it compressed what would have been a week of building into three days. That is a real multiplier, but it is a multiplier on something. None of the decisions above came from a model. Choosing to make the product fully usable with the AI switched off, deciding the generator must emit a constrained schema rather than prose, recognizing that a 29 second gateway limit was an architecture problem rather than a UX one, and setting per-tenant limits before the first customer arrived, are all judgment calls about what a paying business needs. The implementation got cheap. Knowing what to implement did not. That is the part I would be hired for.

The clearest lesson is that AI belongs on the setup cost, not on the core loop. The temptation with a generative feature is to make it the product. Here it works precisely because it is not: the durable value is the portal and the chasing, and the model exists to get you to a populated flow before you lose interest. That framing also makes the product resilient, because the model can fail without the business stopping.

The second is that the mock provider paid for itself many times over. Building the deterministic implementation first felt like a detour and turned out to be the reason the test suite is fast, the local loop is free, and the live model could be swapped late without fear.

• Conditional flows. The current onboarding is a flat ordered list. Branching on a client's answers is the most requested shape and the natural next use of the generator.
• Push further into the review side. Summarization is the least developed AI surface and probably the one with the most remaining value, since it targets the owner's time rather than the client's.
• Verticalize the templates. The generator is general, but the buying decision is made by someone who wants to see their own profession reflected back at them on the first screen.
• Keep compounding the content engine. The daily agent is the cheapest distribution I have, and this category is won on search rather than ad spend.