You pay for output and get process design
Capacity shows up on the calendar. Months go to voice docs, templates, and workflows before a steady publishing rhythm does. The pages you wanted stay thin.
Compare hire, agency, and the engine →The Content Engine
I build a content engine that turns your data, writing, and client work into content that sounds like you and ranks.
Teams come to me after an agency stalls or a content hire gets buried building the system instead of publishing, with years of good material sitting behind them that never made it onto a page.
Every number here came from pages the engine built for Juniper Real Estate, a small San Diego brokerage. One build, measured in Google Search Console. Read that case study →
The job underneath
The expertise is already in the firm. Turning it into live pages that keep working still means a lot of manual work. See the hand work side by side.
Capacity shows up on the calendar. Months go to voice docs, templates, and workflows before a steady publishing rhythm does. The pages you wanted stay thin.
Compare hire, agency, and the engine →Teams keep funding the next post while the pages that already ranked get ignored.
See how archive refresh works →Your calls, writing, and client work teach the engine how your team thinks and sounds. I turn that into voice rules and a quality gate, so every draft reads like your work before it reaches you. When the build is done, you own every piece it publishes. The engine itself, the files and the publishing workflow, runs under a license your team uses in house.

It starts with strategy, the angle your market is missing and only you can own. For Juniper, the brokerage above, that was local pages backed by real data nobody else in the city would publish. Strategy decides what to say. The engine makes sure it ships, in your voice.
I spent 20 years at the Associated Press building content systems that had to be fast, accurate, and in one voice. The quality gate below is that newsroom discipline written down: it checks every draft for machine writing tells and unsupported claims, and sends failures back to be rebuilt before you ever read them.

Your team asks in plain language, the way you would brief a person, and approves every piece before it goes live.
You would askWrite the permit guide from the county data I dropped in, then let me review it before publishing.
You would askGrade our services page, then fix what you find.
You would askWhat should we publish next quarter, based on what buyers keep asking?
You would askTurn that guide into a LinkedIn post and a follow up email.
Same job, two paths
Same article, different amount of hand work. Without a system, every piece starts over from a blank chat.
You still approve before anything publishes. The busywork before and after that review is what drops out.
Before you write anything new
Most teams only publish the next post. Old pages go quiet, numbers go stale, internal links rot, and last year's best article stops matching this year's facts.
The engine goes back through the archive first. It refreshes the facts, relinks related pages, and brings strong URLs current. Search already knows those pages exist, so updating one usually costs less than starting from scratch.
Juniper is where I watched that pay off. I rebuilt every page instead of only adding new ones, and the rebuilt community pages climbed alongside the fresh work. The Mission Valley page alone pulled 7,000 impressions in that window. If you have years of posts, white papers, or research reports, keeping that library current can matter more than another new article.
How to think about the spend
Most teams weigh this against a content hire, an agency retainer, or another year of ChatGPT drafts. Here is that decision side by side.
| ChatGPT or generic AI | Content hire, first 6 months | Agency retainer, 6 months | The engine build | |
|---|---|---|---|---|
| Time to published work | A draft in minutes, then your team finishes it by hand | Months of ramp before the first piece ships | Weeks per piece, on their queue | Publishing starts inside the build |
| Sounds like you | Only if re-taught each time | After months of ramp | Sometimes | Yes, locked in the system |
| Keeps old pages current | No | If they find the time | Rarely the focus | Built to refresh and relink |
| Publishes into your CMS | No | By hand | By hand, or their stack | Wired to your stack |
| What you own after | Chat history | What they wrote before leaving | Their process stays theirs | A license to run it, plus the content |
| Best for | One off drafts | Long term headcount | Ongoing outsourced production | Running a system in house |
Every column here is a real option, including the first one. On a fit call I will tell you if a hire or an agency is the better answer for where you are.
I run this engine on my own site, and I have shipped it for a brokerage, a product consultancy, a housing data product, and a job search tool. Here is the workflow it runs.
Juniper Real Estate
Juniper had paid an agency for months with flat search traffic to show for it. I rebuilt the site on the engine, archive included, and the numbers above came out of the next 110 days. One local business found a guide and reached out cold.
Level Up Product
Jon Shutt built products at Disney, MLB, and Perry Street for 20 years, then let his consultancy sit for a year. I locked his positioning and built an engine on his own stories that he runs by voice. Five approved posts shipped before my work wrapped.

More buyers now ask ChatGPT, Perplexity, Claude, and Gemini, and those engines cite pages they can parse. The engine writes structured pages tagged with schema, and Juniper's already turn up in live answers.


A real estate brokerage got cited for coffee. The engine found live demand around North Park with thin coverage, then wrote the guide that answered it better. None of it needed private data or access to Juniper's site.
A lot of the edits already feel really close to what I would want anyway. At this point, it's likely just nitpicking.
Ryan didn't just build pages, he helped me figure out what we should actually be known for. Instead of chasing the same market updates every agent in San Diego posts, we focused on the local questions people were really asking.

I'm Ryan. Most people call me Berg. One person builds your engine start to finish, so nothing gets lost between a strategist and a dev shop. All I need up front is a few working sessions to lock your wedge and voice. More about how I work.
No, you don't need to be technical. The engine is a custom skill that runs in Claude Code and Cursor, the same AI tools I build software with. I set it up, and you drive it in plain language: ask for a piece, review the draft, approve it, and it publishes to your site. It runs as real files under a license instead of a subscription you rent every month, so your team keeps running it long after the build ends with nothing extra to pay.
A QA layer for text written by AI. Multiple automated checks run before a draft ever reaches you: em dashes, banned words, robotic sentence patterns, claims without evidence. If a draft fails, the engine rebuilds it. You only review work that already passed, and you stay the final check before anything ships.
Google says it rewards helpful content however it gets made and goes after spam produced in bulk. The engine is built for the first and blocks the second: every piece runs on your real expertise and data instead of filler. The Juniper numbers on this page came from pages the engine built, measured in Search Console, and AI engines cite those same pages as sources.
Three to four weeks for most engines. The exact shape depends on how many voices I lock and how much automation and distribution I wire in.
Either. Some clients take the keys the day training ends. Others keep me on for content support: I run production while their team ramps up, then step back once the numbers prove out.
WordPress is proven in production, including automated Yoast and RankMath SEO metadata, FAQ schema, and image uploads through the API. The engine also works beyond WordPress: this site runs on Astro and Netlify, and I have published through fully custom apps like CasitaScore and Kinship Careers. If your stack has a way in, the engine can publish to it.
It drafts from sources you approved: your data, your writing, your client work, plus the public records in your field that nobody has mined yet. That constraint is the point. It is why the pages hold up when a buyer reads them closely, and why the quality gate can check a claim against a source document instead of trusting a model. If you want a piece on something you have no material for, the engine will tell you what it would need first.