Hagi

Content Engine

A content system you own, running in three weeks.

Positioning, a 90-day content architecture, and a production system installed on your own infrastructure — scripts, calendar, images, scheduling. Not an agency retainer you can never leave. A machine you keep.

The problem

Founder-led brands don't fail at content. They fail at the second month.

The first two weeks are fine — there's energy, there are ideas. Then the founder gets busy, the posting stops, and three months later the whole thing restarts from zero. Agencies solve this by renting you their capacity, which works exactly as long as you keep paying.

This is a different trade: I build the positioning and the architecture, then install the system that produces to it. The system is yours, on your infrastructure, with your keys. If we stop working together it keeps running.

What you get

Three weeks, four deliverables.

Deliverable What it covers
Positioning document Who you're for, what you're claiming, what you refuse to say, and the specific angles that separate you from everyone else in the category. Short, decided, and usable as a brief for anyone who writes for you later.
90-day content architecture Content tracks rather than a list of post ideas — recurring formats that each do a different job, so the calendar builds itself instead of needing to be invented weekly.
Production system, installed Running on your server or hosting. Define a brief once; it drafts posts, generates or selects images, builds a calendar and publishes on schedule to your site and pages. Controlled by a dashboard or by chat in plain language.
Handover and training Recorded walkthroughs, written runbook, all credentials. Someone on your team can operate it without me.

The retainer is optional, deliberately. After handover you can run it yourself. Most clients keep me on for monthly operation and iteration because it's cheaper than hiring for it — but that's a choice you make with a working system in hand, not a dependency I built in.

Process

Three weeks, three checkpoints.

  1. Week 1 — Positioning

    Written brief, one 45-minute call, a look at whatever you've published so far and what your competitors are doing. You get the positioning document and approve it before anything is built on it.

  2. Week 2 — Architecture and build

    Content tracks defined and the first 90 days mapped. The production system installed on your infrastructure, configured to your positioning, connected to your channels.

  3. Week 3 — First cycle and handover

    We run a full production cycle together on real content, adjust what the system gets wrong, then hand over: credentials, runbook, recorded walkthroughs.

Ongoing operation from $1,500/month: running the system, producing and reviewing output, monthly reporting, and iterating the architecture as you learn what works.

Case study

19.06 Nail Atelier — Mayfair, London

A studio site with two booking forms that had to reach the studio reliably — with no database, no mail server, and no credentials sitting in the page.

The brief

A landing site for a Mayfair nail atelier, with appointment requests and repair requests arriving somewhere the studio would actually see them. It had to be fast, cheap to run, and not require anyone on the team to learn a new tool.

The constraint

A static site has no server to receive a form. The usual answers — a form service, an SMTP account, a booking platform — all add a monthly cost, a login, and a place for credentials to leak.

The result

Static export served straight from disk, forms posting to a small hardened service that writes into a spreadsheet the studio already opens every day. No database, no mail credentials anywhere, no new tool to learn.

19.06 Nail Atelier landing page — cream background, framed logotype, single reserve call to action
The landing page. A static export served straight from disk — a folder of files, no running application, nothing to crash overnight.
Reservation form page for the studio
One of the two booking forms. Posts to a small dependency-free service that writes into a spreadsheet the studio already opens every day. No database, no mail credentials.
The same landing page on a phone screen
On a phone. Where nearly every booking actually starts.

How it was built

  • Next.js static export served directly by the web server — a folder of files, no running application, nothing to crash at 2am.
  • Deployed under a path on an existing domain alongside a separate live application, with routing arranged so the two cannot interfere. The existing site was never touched.
  • A single source of truth for the base path in code, imported by both the router and the build config — so a fresh clone cannot silently build for the wrong path.
  • Forms post to a dependency-free Node service on the same host, proxied under the site's own domain. The browser never makes a cross-origin request, and the endpoint is never exposed to visitors.
  • Submissions land in a spreadsheet the studio already reads, via a bound script. Notifications use the spreadsheet's own built-in settings rather than code.
  • Rate limited and size capped — five submissions per address per ten minutes, request bodies capped, secrets in a locked-down environment file that is never committed.

The decision worth explaining

The first version sent a confirmation email in the same step that recorded the booking. That looks helpful and is quietly dangerous: if the mail failed, an already-recorded booking would report itself as failed, and the client would submit again. So the email was removed entirely. Recording the request is the job; notification is the spreadsheet's own feature.

And when the forward genuinely fails, the form doesn't claim success or show a dead end — it offers a prefilled email link so the client can still reach the studio. Failure modes are where booking pipelines lose customers, and they're worth more design attention than the happy path.

Why this sits on the content page. Same discipline, different output: work out what the client will actually maintain, build the smallest system that does the job, and design the failure case properly. A content engine is built the same way.

Fit

Who this is for.

  • Founder-led brands where the founder is the credibility and can't be replaced by a generic agency voice.
  • Small teams with no content hire who need consistency without adding headcount.
  • Businesses that have restarted content three times and know the problem is the system, not the ideas.
  • Owners who want to keep what they pay for rather than rent access to an agency's process.

Who it isn't for.

If you want volume posting with no positioning behind it, cheaper options exist and they'll serve you fine. If you want someone to be your brand's voice indefinitely, you want an agency, not a system.

Start here

Tell me what you're building.

A short note about the business, who you're trying to reach, and what you've tried so far. If it's a fit I'll come back with scope, price and a delivery date within two working days.