Standing up a self-running content-and-ads growth engine for a new Australian brand at launch

The launch problem every new brand has

You have the money and the backing. What you don’t have is an audience, and nobody is going to find you on launch day by accident. The usual answer is to hire a marketing team and wait two quarters for SEO to compound while you burn ad budget guessing what converts. This brand didn’t want to wait two quarters and didn’t want the team. It had to be visible and converting from day one.

The hard part isn’t any one channel. It’s that three of them have to come online at once and stay aligned: search visibility, visibility inside AI answers, and paid acquisition. Each one feeds the others — paid traffic tells you what content to write, content earns the rankings that lower your ad cost — and the moment a person has to push each lever by hand, the loop stalls. A small brand can’t staff that.

There’s a second shift that catches new brands flat-footed. The buyers you need increasingly start their research inside an AI assistant, not a search box. Gartner estimates that by 2028, 90% of B2B purchase journeys will be shaped by AI agents. “Findable” now means being citable by a model that may never load your page — not just ranking on a results page you can see.

The constraints we worked under

Three constraints drove every decision below, and the cold start is what makes them harder than they look on a brand that already has traffic.

No marketing headcount, so the engine has to run without a person babysitting each channel — which rules out anything needing a human in the loop on every page or budget change. It does not mean unsupervised, though: the brand’s name is on everything that ships, and wrong output going live unwatched was never on the table.

A genuine cold start, the constraint that separates this from a brand with an existing audience. The loop is supposed to learn from traffic — but on launch day there is no traffic, no conversion history, no baseline. A system that only works once it has data is useless in exactly the window where the brand most needs it. The engine had to produce real content fast and start making allocation decisions before it had earned the right to be confident about any of them.

And a buyer who researches through AI, so the site has to be readable by retrieval crawlers that behave nothing like a browser. Get the rendering wrong and the brand is invisible to the exact systems it most needs to reach, with nothing in the logs to tell you why.

Serving real HTML, because the AI crawlers can’t see anything else

The site is built on the Next.js App Router and ships statically through OpenNext on Cloudflare. The reason is concrete: AI retrieval crawlers mostly don’t execute JavaScript. An analysis of 500M+ GPTBot fetches found almost no client-rendered content gets read at all. A client-rendered SPA would be invisible to the exact assistants this brand needs to reach, so we render HTML at the edge instead. This is the load-bearing decision — get it wrong and the rest of the engine publishes into a void.

The alternative we weighed was a client-rendered app with a prerender shim for bots: detect the crawler, hand it a snapshot. We passed on it. It’s a maintenance tax that compounds — every new page type needs its snapshot path verified, and when it breaks, content silently stops being seen with nothing in the logs to flag it. Serving bots a different payload than humans also ages badly the moment an engine changes how it crawls. Real server-rendered HTML for everyone has no special case to maintain and nothing to get penalized for, and it deletes a whole class of “why isn’t this page getting cited” debugging a new brand can least afford. The static edge deploy buys one more thing at launch: no warm-up curve and no origin to fall over the first time a page actually lands somewhere, so the engine can publish aggressively from day one without anyone watching capacity.

Custom AI skills do the writing, with an eval as the floor

On top of the site sits the loop. The content comes from narrow, custom AI skills — draft, repurpose, optimize. Draft turns a brief into a first page. Repurpose takes one validated piece and spins it into the variants a cold-start brand needs to cover ground quickly: the search-targeted version, the version written to be quoted by a model, the short social cut. Optimize revisits live pages and tightens them against what’s getting traffic. Each skill is bounded to one job and backed by an evaluation set, so output quality is a measured number rather than a vibe.

That eval is what lets the thing run unattended. The naive version is one big prompt that writes everything — cheap to build, impossible to trust, because a small change quietly shifts the quality of every page and you find out in production. Splitting the work into narrow skills localizes a quality drop to the one job that degraded, and the eval set turns “is this good enough to ship” into a threshold a draft has to clear rather than a per-page judgment call. A skill that falls below its bar doesn’t ship. The cost is real — each skill needs its own eval set built and maintained — and we paid it on purpose, because for a brand with no one to proofread the firehose, an eval is the only thing that makes hands-off publishing safe.

Closing the loop with GA4 — and bootstrapping it from cold

GA4 is the source of truth. The conversion and traffic signal it produces decides where the next ad dollar goes; the spend produces more signal; the loop runs again. Content and ads read from that one analytics source, so optimization never has to reconcile numbers across disconnected dashboards. Letting paid optimize to its platform’s own conversion events while content optimizes to engagement is how the two ends of a funnel end up pulling against each other — funneling both through GA4 costs a little fidelity but buys one definition of a win that both sides optimize toward.

The cold start breaks the obvious version of this loop. A signal-driven allocator is only as good as its signal, and on launch day there isn’t one. So the early phase is deliberately exploratory rather than optimizing: spend is spread to buy information, not to chase a conversion rate that doesn’t exist yet, and the first numbers are treated as noise until enough accumulate to mean something. The confidence gate below enforces it — early on almost everything reads as low-confidence and the allocator stays cautious; as real conversion data builds up, the loop tightens on its own. The engine isn’t pretending to know what works on day one; it’s structured to find out cheaply and then commit instead of betting the budget on a guess.

Writing to be quoted, not just ranked

The original GEO study (KDD ‘24) measured which on-page changes raise how often an LLM cites a source. Adding statistics, direct quotations, and cited sources came out on top — up to roughly +40% visibility in generative answers, with “cite sources” the single strongest lever. We use that as a content spec the skills follow by default: state a claim, back it with a real number, cite where the number came from. The writing that holds up to a human reviewer is the writing a model will quote, which is why this folds into the drafting skills rather than running as a separate pass.

This stays white-hat by construction, and for a new brand that’s a survival decision, not a principle. Google’s spam policies now explicitly cover manipulating generative-AI answers, so any tactic whose value depends on the engine not noticing has a short shelf life — and a manual action or de-listing lands on the brand’s name, which a launch can’t absorb. We also skipped llms.txt: a study across 300k domains found no measurable effect on AI citations, so there was no point shipping a maintenance surface with no evidence behind it.

Keeping a person on the ambiguous calls only

Confidence gating decides who acts. When the signal is clear, the system publishes and re-allocates budget on its own; when it’s ambiguous — a thin or noisy signal, an early result that hasn’t earned trust — the case goes to a person instead. This is where “automated but not unsupervised” actually lives, and during a cold start it does most of the work: with little data, most calls start out ambiguous, so a person steers the genuinely uncertain decisions while the engine handles the obvious ones, and that balance shifts toward the engine as data accumulates. Set the threshold too loose and the brand ships things nobody reviewed; too tight and you’ve rebuilt the manual process you were replacing.

Every automated decision is logged and reversible. You can ask why a given page shipped or why a budget moved and get an answer from the record, and a bad call can be audited and undone instead of quietly compounding. For a system that holds a new brand’s name from its first day, that after-the-fact inspectability was a requirement, not a nice-to-have.

The result

A growth engine that finds, publishes, measures, and re-allocates budget on its own, at a pace a small team couldn’t sustain — and without hiring that team. The brand was visible across search and AI surfaces from launch, and the loop bootstrapped its own signal from a cold start rather than waiting for traffic it didn’t have. The engine is brand-agnostic underneath: the site, skills, and eval sets carry the brand identity, and the loop that drives them doesn’t. Re-pointing it at a different brand is config and skills, not a rewrite — which is what makes the build worth more than a single launch.