Where It Started
Ruck Authority started as a regular content site. I had sixty article ideas in a spreadsheet, a brand system, and a Next.js project deployed to Vercel. No automations. No AI in the pipeline. Just me writing articles one at a time and publishing them with git push.
That didn't last long.
What's on the site now is very different, and most of it got added in the last few weeks. There's a content engine that scans for topic gaps, drafts articles, and generates its own imagery. A social pipeline that posts to Instagram and Facebook without me touching it. A tracked-products catalog that replaced what would've been a database table. A draft-publish flow that I almost built an admin UI for and then didn't. A RAG chatbot named Miles that answers questions from the article library.
None of that was planned. Each layer got added because a specific problem made the previous layer feel insufficient. That's the only honest way I can describe it. Here's the order it happened in, and what I actually learned at each step.
Layer 1: Writing With Claude, Not Instead of Me
The first thing I added was Claude in the writing pipeline. Not to generate articles wholesale. To do the parts that slow me down.
Research, mostly. Outlining. Turning a messy voice memo into a draft skeleton I could edit into an article. The editing is still mine. The voice is still mine. But the time from "I know what I want to say" to "draft on screen" dropped from hours to tens of minutes.
The lesson here is narrow. AI-assisted writing doesn't replace writing. It replaces the parts of writing that feel like admin. If you treat it like a ghostwriter, you get ghostwritten content, which reads exactly like you'd expect. If you treat it like a writing partner who does the scaffolding, you get something that sounds like you but took a third of the effort.
For a small business owner writing blog posts, social captions, or email newsletters in their off hours, this is the easiest win available. It's also the one most commonly messed up by using AI as a content generator rather than a drafting aid.
Layer 2: Images That Actually Match the Article
For the first thirty or so articles, images were stock photos and whatever I could shoot myself. Fine, but slow, and the results rarely matched exactly what the article described.
I added a generation pipeline. First with FLUX 2 Pro through fal.ai, which is good for general photography. Then, for gear and product articles, I moved to Nano Banana Pro with multi-reference input. The difference is specific: with FLUX, I'd get "a weighted vest" that was generic and sometimes featured the wrong brand name on the label. With Nano Banana Pro plus three reference photos of the actual product, I'd get something that looked like that product.
That sounds like a small thing until you realize it's the difference between an article that feels authentic and an article that feels like content slop.
The whole pipeline costs about five cents per image. A month's worth of article images costs less than a sandwich. And everything is stored in Cloudflare R2, served through a subdomain, automatically resized to the right aspect ratios.
What I learned: the economics of AI imagery are already wildly in favor of just doing it, if you pick the right tool for what you're showing. Photorealistic product shots and editorial illustration are different jobs. One model is not better at both.
Layer 3: A Social Pipeline That Runs Itself
The social side came next. Instagram and Facebook, four posts a week, on a schedule. Not me writing captions at 10pm. Not me remembering to post the gear feature on Wednesday.
The setup is boring. GitHub Actions runs a workflow on cron. The workflow picks an article, asks Claude to write a caption in the Ruck Authority voice, generates a carousel tile through fal.ai, and posts through the Meta Graph API. Total monthly cost: around two dollars. Total time I spend on it: zero, most weeks.
This is the piece I'd tell a small business owner to think about hardest. Not because it's clever. Because social scheduling is the single most common place I see small businesses burn hours they don't have. You can replace your whole posting routine with a cron job, a content calendar, and about three hours of initial setup. The ongoing work is reviewing what gets posted, not posting it.
Layer 4: A CRM Out of Markdown Files
A couple of weeks in, I needed a way to track products that didn't fit into the reviewed-products table. Think: rucking-adjacent gear. Stuff I'd mention but hadn't written a full review on.
The obvious move was a database table. A new migration. An admin UI. Maybe two or three hours of work.
Instead I made a folder of markdown files. Each one has frontmatter for the product details (brand, price, retailer, affiliate link, relevant content pillar) and a body for notes. The site reads the folder at build time and treats each file as a product record. No database. No admin UI. When I want to add or edit something, I open the folder in my editor.
The lesson is the same one that keeps coming up: not every data model needs a database. If the editing rate is low (say, a few changes a week), flat files are faster to build, faster to update, and easier to understand six months later. Git is your audit log. Your editor is your admin panel.
I've used this pattern three more times since. It keeps working.
Layer 5: A Content Engine, Not a Content Calendar
The biggest change came in the last couple of weeks. I wrapped the writing and imagery pipelines into what I now call a content engine. It has two modes. The first scans for product and topic gaps in the existing library, picks something worth writing, drafts the article, generates imagery, and drops the result in a drafts folder. The second watches for trending conversations in the rucking community, writes timely articles, generates editorial illustrations, and does the same.
Both modes run on a cron. Twice a week. Neither publishes anything.
That last part is the important one. The engine does the work up to the point where taste matters. It stops at the drafts folder. I read the draft. I edit or reject. I hit publish. The judgment is still human. The grinding part is automated.
For a small business running content, this is the shape of the thing that matters. Automation that stops before the decision. Not automation that makes the decision for you. Every content tool that promises to "run your blog" skips this distinction and that's why the results from those tools read the way they do.
Layer 6: No Admin UI for the Draft Flow
Originally I planned to build a proper admin queue. A database table for pending drafts. A web page at /admin/drafts with approve and reject buttons. Image thumbnails. Search. Filtering. Maybe three hours of work.
I didn't build it.
Instead: the chat session that runs the content engine also notifies me when new drafts land. I read the draft. I say "publish this" or "reject" in chat. A script handles the file moves and the database updates. The approval loop is a conversation, not a queue page.
The savings aren't just the three hours. It's all the maintenance forever. It's the Vercel Blob fees I would've paid for image storage in the queue. It's the extra surface I would've had to keep working.
This is the move I would've talked myself out of at any job before. "That's not professional." "What if you want to approve from your phone?" "What if another person needs access?" All valid objections for a team. None of them apply to a one-person content operation that trusts its own chat log.
I build things now with that question in the foreground. "Does this actually need to be a full thing, or is the chat window fine?"
What It All Adds Up To
Ruck Authority has sixty live articles, automated social posting, a content engine, a RAG chatbot, a deals tracker that scrapes prices on a schedule, and a full brand system. Monthly AI spend is under fifteen dollars. I've spent about a month on it, mostly part-time. Most of the layers above landed in the final two weeks of that.
None of those individual pieces are especially clever. The thing that's different is that each piece was added because a real problem made the previous state untenable, not because I thought it would look impressive. The layers exist because they earn their keep. The ones that didn't earn their keep never made it in. The admin UI is the example that didn't.
If you're running a small business and watching this AI wave and wondering what to actually do about it, here's what I'd say:
Pick one specific thing that's slow or boring. Add AI or automation to that one thing. Use it for a month. See if it earned its place. If yes, pick the next one. If not, cut it and pick something else.
That's the whole method. It's not glamorous. It's the only version that actually stuck.