How ContentForger Turns a Plain-English Brief Into a Deployable App

The Generate page at /generate looks like a text box with a button. Under it, every click sends one request to a single endpoint, and the shape of that request decides most of what comes back. It is worth knowing the shape.

You must be signed in. A signed-out visitor who opens /generate is redirected to the sign-in page and brought back afterwards. The anonymous demo at /demo is a different, smaller thing: it takes a prompt of 10 to 500 characters, runs on Claude Haiku with a short output budget, allows three runs an hour per network address and does not save anything.

The main form has three inputs on a first turn.

Ctrl+Enter (Cmd+Enter on a Mac) sends the form. There is a Stop button while a generation is streaming; it cancels the connection from your side.

The first time you open the page you will see a tip card with three habits that make prompts work: name your stack, list your pages, state your business rules. That card is dismissable and does not come back once dismissed. The habits are worth keeping. The generator fills gaps with sensible defaults, but every default it picks is one you did not choose.

Nothing is sent to the model until your request has cleared a short sequence of checks. Each one exists to protect either you or the service, and each one produces a different message when it fails. Knowing which message means what saves a lot of confusion.

Gate one is a per-address rate limit. The generate endpoint allows twenty requests an hour from one network address, on a sliding window. That window is shared with the AI Project Brief tool. If you hit it you get a plain "Rate limit exceeded" response. This limit is independent of your plan.

Gate two is sign-in. No session, no generation.

Gate three is input validation. Prompt length, the optional template name, the optional style, and, for a change request, the project it builds on are all checked. A malformed request is answered with "Invalid input".

Gate four is a content-policy check. It is a small, explicit block list aimed at a handful of harmful categories such as phishing kits, malware and credential theft. It is not a general-purpose moderation model. A blocked prompt returns "This request was blocked by our content policy" and nothing is spent.

Gate five is your daily allowance. The service counts the generations you have started since midnight UTC and compares the count with your plan's limit: 5 on Free, 100 on Pro, 1,000 on Agency. Two details matter here. The count is taken from your history rows, and a row is written the moment a generation starts, so a run you stop early, or one that fails, still counts. And the clock is calendar-day UTC, not a rolling 24 hours. When you are at the limit the response is a 429 with the message "Daily generation limit reached".

Gate six is a site-wide monthly spend ceiling on model usage across all users. When that ceiling is reached, every generation on the service answers 503 "Service temporarily at capacity" until the month rolls over. The ceiling resets on the first of the month, UTC.

There is one more response worth recognising. If the service cannot read your usage at all, for example because the database did not answer, it refuses rather than guess, and tells you so: "We're temporarily unable to verify your usage, please retry", with a sixty-second retry hint. That is a 503, not a 429. It means try again in a minute, not come back tomorrow. The guards are deliberately built to fail closed, because an unmetered model bill is a worse failure than a short delay.

Once your request is through the gates, it is combined with a long system instruction that you never see on screen. That instruction is the real reason ContentForger output looks the way it does, so this chapter summarises it.

The opening line sets the role: an expert full-stack engineer producing production-ready Next.js 16 App Router code in TypeScript with Tailwind CSS v4. Your style word is added as a single sentence.

Then comes the output format, and this part is strict. Every file must begin with a marker line of the form ---FILE: path/to/file.tsx--- followed by a fenced code block whose language tag matches the file extension. No commentary is allowed between files. The model is also told to emit files most-interesting-first: the page you asked for, then the components it imports, then layout, global styles and config last. That ordering is why the first file you see streaming is usually app/page.tsx rather than a font import.

Then a list of requirements the generator is told to meet on every run. The notable ones:

Finally, a plan-specific tail. Free generations are asked to include a "Built with ContentForger" comment in the footer; that comment is the watermark the pricing page refers to. Pro generations receive deploy instructions for Cloudflare Pages and Netlify instead. Agency generations receive white-label instructions built from your saved brand name, logo URL and primary colour, with an explicit instruction not to mention ContentForger or NorwegianSpark anywhere in the code.

One honest caveat about all of the above. These are instructions to a language model, not a compiler's guarantees. A given output may miss an item, especially when the output budget is tight. Chapter 6 and the pre-launch checklist in the journal explain what to verify.

The response is a live stream. The server forwards the model's text as it is produced, so the right-hand panel starts filling within a few seconds and keeps filling until the model stops. While it runs you see a character count and an elapsed-seconds timer under the prompt.

The viewer does something useful with that raw text. It scans for the ---FILE: markers described in the previous chapter and splits the stream into separate files, each with its path and language. Those files appear as a tree down the left of the panel, with icons by type, and the first file is selected automatically. If the output contains no markers at all, which happens when the model answers in prose instead of code, the viewer falls back to showing the raw text, and the download button gives you a .txt file rather than a ZIP.

The toolbar above the tree has, in order: an Edit toggle, Copy this file, Copy all files, Download ZIP, a Deploy guide, and Share. Edit mode turns the active file into a text area so you can make a quick fix in the browser. Those edits live only in the page: Copy all includes them, but the ZIP is built from the original generated output, so if you have edited in the viewer, use Copy all or re-apply the edit after download.

When the stream finishes a stats line appears under the panel: the model that ran, input tokens and output tokens. The model is decided by your plan, never by the prompt: Claude Sonnet 5.5 for the first app of the day on Free and Claude Haiku 5.5 after that, Claude Sonnet 5.5 on Pro, Claude Opus 5.5 on Agency.

Since October 2026 there is no fixed output cap per app. The app is planned first and then written six files at a time, and each file is saved the moment it is finished, so a closed tab or a dropped connection loses at most the file in progress; reopen the same build link and it carries on. The next chapter covers follow-ups.

The Stop button aborts your connection. The server-side record of the attempt still exists and still counts against your daily allowance, as noted in Chapter 2.

After the first build finishes the form changes. The template and style selectors disappear, the prompt box becomes a Change request box, and up to three suggested next changes appear as buttons. You are now working on a project.

A change request is a new build linked to that project. The planner reads the project's current files together with your request and lists only the files to add, change or delete. Those files are written and saved one by one, like a first build, and every other file is carried over. The template and style are only applied to the first build.

Four practical consequences follow.

The New project link clears the project and brings back the template and style controls. Start a new project when the direction changes substantially; use change requests when you are refining the same app.

A good rhythm for a first project: one first prompt that names the pages, the data and the stack; then two or three change requests, each asking for one concrete change.

At the end of a generation you have a set of source files. This chapter is the honest inventory of what that means.

What you get:

What you do not get:

If that list reads as a lot left to you, the next tutorial, From Generated Code to a Live Site, walks through exactly those steps in order, using the same commands the in-product deploy guide shows.