The spreadsheet proved the idea. Then it stopped working.

A form collected inputs about a course creator's product and their audience. Those answers landed in a Google Sheet, where formula-driven language model calls turned each one into finished marketing copy. Pre-headlines. Headlines. Three-email launch sequences. Ads. Video outlines.

Real creators used it, and real creators got usable funnels out of it.

Then the model was retired.

Open the prototype sheet today and almost every generated cell contains the same model deprecation error. Every output column, across every section, failed at the same moment. The inputs survived. The prompt engineering, months of direct-response marketing expertise written into formulas, survived. What did not survive was the product's ability to produce anything at all.

One hard dependency on one model from one provider, called from a spreadsheet formula. No retry. No fallback. No error handling.

When that dependency was withdrawn there was nothing underneath it. The product did not degrade. It stopped.

That matters for how the rest of this reads. We were not rewriting a working product. We were productising a prototype that had already stopped working, and the distinction shaped every decision that followed.

Two things.

Proven demand. Real users had completed the process and got value from the output. That is harder to establish than a codebase, and the client already had it.

The designed interview. The prototype ran on a five-stage sequence refined by people who understood direct-response marketing. An intro established the product. A customer interview covered the avatar, their problems, what those problems cost them, and their objections to buying. A product interview covered mechanism and differentiation. An author interview was built around the founder's own story. A funnel interview covered the event and its logistics. Every question carried a prompt behind it.

That pairing of question and prompt was the client's intellectual property. Our job was not to invent it, and not to improve it. Our job was to stop it living in a spreadsheet.

The engineering timesheet records roughly 455 documented hours across eleven phases, plus a separate full interface rebuild billed as a fixed amount.

The interview had to stop being code, the generated copy had to become editable, and the whole thing had to be something a person could buy. Roughly in the order it was built:

Two loops sit behind a finished funnel. The first runs once per question and produces a confirmed answer. The second runs once per funnel and turns those answers into copy. They are worth separating, because most of what makes the product usable lives in the first one.

One question at a time, and every answer is a draft. Answers are grouped into four segments: Product, Author, Funnel Intro and Funnel. Product alone carries twelve questions. The user answers in their own words, usually a sentence or two, and the platform drafts a fuller version from it.

Behind every question sits a prompt an administrator wrote and attached to it, carrying placeholders for answers given earlier in the interview. The model call is queued rather than made inline, and falls back to another model if generation fails.

What comes back is presented as a suggestion rather than a result, and three things can happen to it. Regenerate tries again, with the button reading Generating while it runs. Edit lets the user rewrite it by hand, and submit stays disabled until something actually changes. Review and confirm accepts it, at which point it is stored against a short code and becomes reusable downstream. Regenerate and edit both loop back to the draft.

Nothing is stored until the user accepts it, and the summary panel fills in as answers are confirmed, so the picture builds while they work.

Confirmed answers become variables. Each is stored against its short code, alongside the copywriting style the user chose.

A flow definition decides what happens to them. It is an administrator-configured list of output sections, each with its own prompt template and its own position in the run, and an output can reference other outputs. That is the dependency graph, expressed as configuration rather than code.

The run assembles each section's prompt from the variables it needs, including outputs produced earlier in the same run. Jobs are queued, executed against the provider pool, retried on a different model if one fails, and token use is recorded per flow.

What comes out is a funnel, not a page. A landing page as pre-headline, headline, sub-headline, problem, what they will learn, author section and bonuses. Emails as announcement, what and when, and last call, each with subject line options. Ads as problem-led and solution-led variants for paid social. Video scripts as hero's journey, results in advance and paradigm shift, each with hook options.

Every block stays editable afterwards. Users revise any section and save it back, then export: Google OAuth, the destination Drive folder created if it does not already exist, and each asset uploaded with its own progress.

The original failure got two answers. The order they came in is the most useful part of the record.

Stage one, three hours. Automatic model fallback: when one model fails to generate, switch to another. It shipped as a routine change request, alongside dynamic output types and categories. Three hours of insurance against precisely the failure that had already killed the product once.

Stage two, forty hours, much later. A token consumption report per flow. Prompt optimisation to reduce tokens per call. A pool of ten or more provider credentials, with each request routed to whichever had the most available capacity. That work was built once real volume justified it, not before.

Teams usually get this backwards. Either they build elaborate multi-provider abstraction before they have a single user and pay for flexibility they never exercise, or they never build it at all and repeat the original failure the next time a provider changes its plans.

Buying the three-hour insurance immediately is what makes the forty-hour version optional until it is not.

One sample answer in the interface designs reads: “As an AI language model, I don't have personal beliefs, thus cannot act as a marketer. However, based on research about objections to purchasing running courses, below are the top 5 objections...”

That is a model refusal preamble leaking into the product, drawn into the designs as ordinary output. Nobody put it there as a joke. It was there because that is what the system produced, and the designs treated it as a normal case to be handled rather than an edge case to be hidden.

It explains the shape of the questionnaire exactly. The design was a two-column workspace. On the left, the active question, with step and question counters and a progress bar. On the right, a live panel titled “Your Product so far”, with tabs for Product, Author, Funnel Intro and Funnel, collapsible question-and-answer rows, and an Edit control on each. The action buttons were Regenerate, Back, and Review and Confirm. Separate states were designed for an empty summary, for a reviewed question, and for regeneration in progress.

That is why the loop described above exists at all. Generated output is a draft rather than an answer, and the refusal preamble sitting in the designs is the evidence for it, better evidence than any assertion we could make.

Onboarding was designed the same way. Three steps, with a progress indicator across them: Account Created, Setup password, Claim your sub domain. The password screen opens by congratulating the user on their purchase and explaining that an account has been created for them automatically, which is checkout-to-account wiring designed as a flow rather than patched in afterwards. The subdomain step warns that once chosen, a subdomain cannot be changed.

The support phase came to 13 hours, and it is the most honest part of the record.

A trial user whose payment cleared with the checkout provider but never reflected back, leaving the account on trial. A user who hit a credit limit and needed their consumption checked. An onboarding freeze reported by someone whose account turned out to be working normally. Admin search, added because support needed it to do the job.

None of that is model work. All of it is what running an AI product actually looks like.

Laravel and PHP, with Sanctum for authentication and Cashier for Stripe subscription billing, alongside checkout-provider webhooks. Vue with Vuex and TypeScript on the front end, styled with Tailwind, over REST.

MySQL for data. Redis and Horizon for queues and background jobs. Amazon S3 for asset storage, and Laravel Mail for transactional email. OpenAI with the client's own prompt engineering. Google OAuth and the Drive API for export. GA4, PostHog and custom telemetry. Containerised with Docker behind Nginx, deployed through GitHub Actions, with a separate staging environment.