Snapwire was a marketplace connecting brands — including names like Dell and Starbucks — with on-demand photographers. For two and a half years I was the embedded engineering manager and technical product lead on it, working as part of the client's own team rather than a vendor at arm's length.

That distinction matters, so let me be specific about what "embedded" meant here.

Managing across two companies and three timezones

The team I ran was split across organizations. I managed a group of about ten engineers on our side, based in Europe, alongside Snapwire's own engineers in California and Toronto. Two different companies, three timezones, one standup. I was in that standup every day, working directly with Snapwire's CTO and their scrum master — a fifteen-year ex-Apple engineer — as one integrated team. Not "here's the spec, ping us when it's broken." Daily ownership of the technical reality of the product.

Day to day I monitored every issue, wrote the technical specifications, tightened QA and automated testing, and personally executed the hardest parts of the system. I vetted hires, took part in re-architecting the platform when the product pivoted, and helped set technical direction alongside the client's leadership.

What I built

The V2 platform. I rebuilt the product's user experience with our designer, and a big part of that job was unglamorous reconciliation: keeping the new designs aligned with the actual state of the API and the existing frontend, so what got designed was what could actually ship. A redesign that ignores the live system is just a mockup. I made sure V2 matched reality and improved on it.

Payments. I implemented Stripe Connect — marketplace payments, with all the splitting, payout, and edge-case handling that two-sided money movement demands.

The admin backends. The internal tooling Snapwire's team used to run the marketplace.

A real performance win on the frontend. The React bundle had grown to tens of megabytes. Working with the engineering team, we cut it to around three — roughly a ninety percent reduction — which, combined with the V2 redesign, transformed load time and the overall feel of the product.

The image pipeline, and the part I'm proudest of

Snapwire moved millions of images and videos, so I researched and implemented the CDN pipeline on AWS to serve them at scale. Tagging and quality scoring ran through AWS Rekognition.

Here's the honest version: Rekognition out of the box landed around 60–70% accuracy on our content. Good enough for a demo, not good enough for a product brands were paying for. So we didn't stop there. We wrote custom AI/ML code to post-filter Rekognition's output, and that took tagging accuracy past 95%. The off-the-shelf service was the starting point, not the answer — the accuracy that actually mattered came from the layer we built on top of it.

The handoff

Snapwire was acquired by StudioNow. We supported the technical due diligence, helped transition the platform, and — the part I care about — kept shipping features and polish through and after the acquisition, staying with the product until we genuinely weren't needed anymore. A smooth handoff isn't an accident. It's what happens when the people who built the system are still around, the code is understood, and nobody's scrambling to reverse-engineer their own product during diligence.

What this kind of work is

Snapwire is the clearest example of a mode I work in often: not a vendor you brief and wait on, but an engineering manager and technical product lead who embeds in your team, owns the hardest parts of the build, and runs people across companies and timezones as if it were one org. The output isn't a deliverable handed over a wall. It's a product I helped run, day by day, until it had a good home.

In 2016, two founders showed up with a product spec written on a single sheet of A4. They were non-technical, sharp, and they wanted to build a two-sided tutoring marketplace across the United States. They didn't have a CTO. For the next nine years, I was it — without the title.

That's the role I want to talk about, because it's the one most companies don't know how to ask for.

The CTO nobody hired

HeyTutor never had a CTO on the org chart until 2023. They didn't need one, because they had me. I owned the architecture, the infrastructure, the CI/CD, the database, the server management, the API selection, the hiring, and the technical roadmap. Operational ownership, not advice from the sidelines.

People hear "fractional CTO" or "technical advisor" and picture someone who drops in for a strategy call and disappears. That's not what this was. I was scaling load balancers late at night when traffic spiked. I was in the schema design, the query optimization, the migration planning. The database decisions I made in year one were still holding up the platform in year nine — which is the only real test of whether you got them right.

What we actually built

We turned that one-page spec into forty pages, brought in a senior designer for a full InVision prototype, and built V1 from zero. The stack was Vue on the front end — an early bet in 2016, when Vue was still proving itself — and Laravel with PostgreSQL behind a RESTful API. Stripe for payments. Real-time messaging. CI/CD with proper QA and staging environments from day one.

Marketplaces are one of the hardest things to build well, because every page has to serve two sides at once. The piece I'm proudest of is the matching engine. Over a hundred signals fed into pairing a student with a tutor: subject and grade level, teaching style, availability windows, timezone compatibility, location proximity, price range, ratings, background-check status, response-time patterns. Get the weighting wrong and the marketplace feels broken even when every individual feature works.

Timezone-aware scheduling was its own quiet monster. A student in New York and a tutor in Los Angeles need a slot that's correct in both their calendars, with recurring sessions, cancellations, and two people occasionally trying to book the same slot at the same instant. None of that is glamorous. All of it has to be exactly right.

We also generated thousands of local SEO landing pages — "math tutors in Los Angeles," "SAT prep near me" — programmatically, each with location-specific content. They became one of the platform's primary organic acquisition channels.

The pivot that changed the company

HeyTutor started B2C. Then school districts came calling, and B2B turned out to be a different animal entirely. Districts don't browse a marketplace and pick tutors one by one — they bulk-hire and assign through a CRM-driven workflow, and they need to plug into the e-learning infrastructure they already run. So we built a separate B2B layer on top of the existing platform: Google Classroom integration, district-level dashboards, bulk assignment workflows, and the compliance and reporting that government contracts demand.

That layer is what let HeyTutor win LAUSD — the largest school district in the United States. Contracts at that scale don't tolerate a platform that's flaky or undocumented. The engineering has to be right, and it has to be provably right.

Onsite, because some things don't happen over Slack

Roadmaps that actually stick get built in a room. I flew our technical lead and PMs out to California to sit with the HeyTutor team in person, set the direction, and decide together what to build, what to defer, and what to kill. You can run a nine-year engagement remotely, but the inflection points — the moments where the product's direction changes — are worth being in the same room for.

How I measure a good engagement: the handoff

In 2023, HeyTutor hired their first in-house CTO, and I handed the technical leadership over to their internal team. That's the outcome a fractional engagement should produce. The company grows until it needs and can afford a full-time technical leader, and the handoff is clean because the codebase, the infrastructure, and the processes are all documented and well-maintained. A messy handoff means you built a dependency, not a system. A clean one means you did the job.

By the end: 10,000+ tutors, 10,000+ students, tens of thousands of sessions a month, continental US coverage, multiple funding rounds, and both founders on the Forbes 30 Under 30 list. Nine years — my longest engagement, and the one I'd take again without hesitating.

What this kind of work is

If you're a non-technical founder with a hard product and no senior engineering leadership, this is the gap I fill: someone who owns the technical reality of the company end to end, builds the team, makes the architecture decisions you'll be living with for years, and hands it off clean when you've outgrown the arrangement. Not a deck. The actual thing.

I used Contentful for years. It was fine. The content model was decent, the API was fast, the editorial experience was good enough. Then on April 30, 2025, Contentful decided that "free" meant 25 content types, 100K API calls, and a $300/month cliff if you go over.

We had 30+ content types. The math was simple. We left.

Why Sanity

I evaluated Strapi, Payload, Storyblok, and Sanity. Here's the honest version of that evaluation:

Strapi is open source and self-hosted. Great for data sovereignty. Terrible if you don't want to maintain a Node.js server, a Postgres database, and all the DevOps that comes with it. I run a software studio. I have engineers. I still didn't want to babysit a CMS server.

Payload is fascinating — a CMS that lives inside your Next.js app. One deployment unit. TypeScript-native. 42K GitHub stars. If we were on Next.js, I'd seriously consider it. We're on Astro. Moving on.

Storyblok has the best visual editing for marketers. Drag-and-drop, WYSIWYG, the whole thing. But our marketers are me, and I type Markdown in a text editor. Visual page builders solve a problem I don't have.

Sanity gave me 20 seats, 10,000 documents, 1 million CDN requests, and 100GB bandwidth. Free. The Studio is React-based — same stack our team uses for client work. The content model is defined in code, not clicked together in a UI. And the query language (GROQ) is genuinely better than GraphQL for content.

That's it. That's the evaluation. Sometimes the right answer is the one that costs nothing and works immediately.

What Sanity actually is

Sanity is a headless CMS with a twist: the editing interface (Sanity Studio) is a React app that you own, customize, and deploy. The content lives in Sanity's cloud (the "Content Lake"). You query it with GROQ or GraphQL. You render it with whatever frontend you want.

The Studio runs at your-project.sanity.studio or on your own domain. You define schemas in TypeScript. You build custom input components in React. You can replace literally any part of the editing interface with your own code. Most CMSes give you a settings panel. Sanity gives you a React app.

This means the setup cost is higher than WordPress. You'll spend developer time configuring the Studio. But the ceiling is also higher — dramatically higher. Our Studio has custom preview components for blog posts, structured case study schemas with stack arrays and metric objects, and an author reference system. Took a few hours to set up. Works exactly how we need it to.

GROQ is weird. GROQ is also better.

GROQ (Graph-Relational Object Queries) is Sanity's query language. It looks like nothing you've seen before. The first time you see *[_type == "post"]{title, "author": author->name} you think "what is this syntax." The second time you think "wait, that just resolved a reference in one character."

The -> operator dereferences a reference. In GraphQL, you'd need a resolver, a type definition, and a separate query. In GROQ, you add two characters.

Where GROQ wins over GraphQL: server-side projections (you shape the exact JSON your component needs in the query), no deployment step (schema changes are queryable instantly), real-time subscriptions work natively, and reference following is trivial.

Where GraphQL still wins: schema introspection, cross-source federation, and the fact that every developer on earth already knows it. GROQ has a learning curve. Not a steep one — maybe two hours to be productive, a week to be fluent — but it's one more thing.

Sanity supports both. If your team has strong GraphQL opinions, use GraphQL. You'll give up real-time subscriptions and mutations (Sanity's GraphQL layer is read-only), but you'll get the tooling you already know.

Portable Text: why it matters more than you think

Most CMSes store rich text as HTML. Sanity stores it as a JSON block array called Portable Text.

"Who cares?" You will, the first time you need to render the same content in a React web app, a React Native mobile app, an email template, and an LLM context window. HTML is designed for browsers. Portable Text is designed for anywhere.

Every rendering layer has a Portable Text renderer: React, Vue, Svelte, native iOS, native Android. You write custom serializers for your own block types. An inline "callout" block in the editor becomes a styled callout in the web app, a plain text block in the email, and structured metadata for the AI agent. Same source content, four different outputs, zero HTML parsing.

The trade-off: pasting from Google Docs into the editor doesn't always do what you expect. Block-level formatting survives. Inline formatting sometimes doesn't. Your editors need 15 minutes of training. After that, it's fine.

A bigger trade-off we learned the hard way: pasting rich text from chat interfaces (like Claude's web UI) can silently rewrite relative URLs to absolute ones with the wrong domain. We discovered 146 links pointing to claude.ai instead of eltexsoft.com because Sanity Studio's rich text editor resolved /blog/... against the page URL. We wrote a script to fix them. It took an hour. But it shouldn't have happened, and it wouldn't have if we'd pasted Markdown instead.

The MCP thing is actually a big deal

Sanity has a Model Context Protocol server. MCP is the protocol that lets AI agents (Claude, Cursor, VS Code agents, etc.) interact with external tools. Sanity's MCP server lets an AI agent query your content, create documents, patch fields, manage releases, and run semantic search — all through natural language.

I use this daily. "Query all posts where the slug contains 'outsourcing'." "Patch the seoTitle on document ID 93299147 to this value." "Publish these 13 documents." Claude does it. I verify. Done.

We created blog posts, patched SEO fields across 31 pages, fixed 146 broken links, and published 36 articles through a combination of MCP operations and Studio editing. The MCP connection turns content management from a point-and-click operation into a programmable one.

No other headless CMS has anything close to this in May 2026. Contentful doesn't. Strapi doesn't. Payload doesn't. Sanity's MCP server is the single biggest competitive advantage in the headless CMS market right now, and almost nobody is talking about it because "CMS has an AI integration" sounds like marketing fluff. It's not fluff. It's the difference between manually editing 31 meta descriptions and telling Claude to do it in one prompt.

Real-time collaboration

Multiple editors on the same document. Google-Docs-style cursors. Keystroke-level presence. Conflict-free because the Content Lake is patch-based — every change is a discrete operation, not a full document overwrite.

Most headless CMSes have "collaboration" that means "optimistic locking" — if two people edit the same document, one of them loses. Sanity's collaboration means two people type in the same field at the same time and both changes survive. Contentful would need a near-total architectural rewrite to match this.

I'm the only editor on our site, so I don't use this feature much. But for agencies managing content for clients, or companies with editorial teams, this is the difference between "don't touch that document, I'm editing it" and "go ahead, we're both editing it."

The money

Sanity Free: 20 seats, 10,000 documents, 1M CDN requests, 250K API requests, 100GB bandwidth, 100GB assets. Real-time collaboration, Media Library, GROQ + GraphQL.

Sanity Growth: $15/seat/month (viewers free). 25,000 documents, 5 roles, AI Assist, Comments, Tasks, Scheduled Drafts, Content Releases.

Contentful Free (post-April 2025): 25 content types, 100K API calls, 50GB bandwidth. No grandfathering. Exceeding limits can result in suspension.

Contentful Paid: Somewhere between $300 and $850/month depending on which source you trust (PricingSaaS, Vendr, and CostBench all report different numbers). Get a sales quote. Don't trust the internet, including me.

For a studio our size, Sanity's free tier covers everything. 36 blog posts, 13 case studies, 10 industry pages, 9 tech pages, 22 course chapters, authors, metadata — all well under 10,000 documents. We'll hit Growth when we need Content Releases or Tasks. That's $15/month for one editor seat. Not $300.

Where Sanity falls apart

The Studio needs configuration. A fresh install is functional but bare. You'll spend developer days making it feel good for editors. Schema definitions, custom previews, desk structure, validation rules — it's all code you write. This is simultaneously Sanity's greatest strength and its highest barrier to entry.

Document limits are real. 10K on Free, 25K on Growth. Reference-heavy schemas inflate document counts because references create separate documents. If you have 5,000 blog posts with 3 author references each, those references count. The Increased Quota add-on is $299/month. That's a cliff.

API vs CDN billing will bite you. Direct API requests to api.sanity.io cost 10x more per unit than CDN requests to apicdn.sanity.io. A misconfigured @sanity/client with useCdn: false will inflate your bill for no reason. Always set useCdn: true for read operations.

No self-hosting. The Content Lake is Sanity's cloud. Period. You can export everything (GROQ + export CLI), so migration is feasible, but you're a SaaS customer. If "I own the server" is a hard requirement, use Strapi or Payload.

No native visual page builder. If your primary editor wants to drag-and-drop sections like Squarespace, Sanity is the wrong tool. It has Visual Editing (click-to-edit overlays on your frontend) and the Presentation tool, but it's not a page builder. It's a structured content editor. Different animal.

GROQ is one more thing. Your team learns React. TypeScript. Your framework. Your deployment platform. GROQ. That's a real cost. It pays off, but don't pretend there's no ramp.

The bottom line

Sanity is a CMS for people who think about content as structured data, not as pages. If that sentence resonates with you, Sanity is probably the right choice. If that sentence sounds like unnecessary complexity, Storyblok or WordPress might serve you better. No judgment.

We migrated from Contentful using the official contentful-to-sanity CLI. One command. The content came over clean. The Studio took a day to configure. The MCP integration took 10 minutes. The blog has been running for two weeks with zero issues.

30,000+ organizations use Sanity. Nike, Sonos, Figma, Linear, National Geographic, Shopify, Spotify. $85M Series C. $40M+ ARR. This isn't a bet on an underdog. This is a bet on the CMS that quietly became the default while everyone was arguing about WordPress vs Contentful.

The free tier is generous. The content model is flexible. The AI integration is years ahead. And the query language is weird in the way that good tools are always weird at first — it feels wrong until you realize it's right, and then you can't go back.

We rebuilt eltexsoft.com on Astro + Sanity. The full teardown: Rebuilding Our Agency Website in 2026. The Astro half of the story: Astro in 2026.

I spent 10 years building websites with frameworks that ship 200KB of JavaScript to render a paragraph of text. Vue, Nuxt, React, Next — all brilliant tools for building apps. All absurdly overpowered for a marketing site.

Then I found Astro. And I felt like an idiot for not finding it sooner.

What Astro actually is

Astro is a web framework that ships zero JavaScript by default. You write components — in Astro's own syntax, or in React, Vue, Svelte, literally whatever you want — and the build step renders them to plain HTML. The JavaScript disappears. What lands in the browser is HTML and CSS. That's it.

A typical page on our site is 5-15KB. Not 5-15KB gzipped. 5-15KB total. The Lighthouse score is 95+ on mobile without trying. Not because we optimized aggressively — because there's nothing to optimize. You can't have a slow JavaScript bundle if there is no JavaScript bundle.

"But what about interactivity?" Fine. You mark a component with client:load or client:visible and it hydrates independently. One interactive widget on a page of 20 components means one component ships JS. The other 19 are static HTML. Astro calls this "Islands Architecture." I call it "not shipping code nobody asked for."

The numbers that made me switch

State of JavaScript 2025 surveyed thousands of developers. Astro hit 94% positive sentiment. Number one. SvelteKit came in at 88%. Nuxt at 80%.

Next.js? 55%. Down from 68% the year before.

The survey editors didn't sugarcoat it: Next.js keeps gaining market share while losing satisfaction at the same time, and now has a 39-point gap with Astro. That's a framework running on inertia, not love.

I don't make technology decisions based on popularity contests. But when 94% of people who use a tool like it, and 45% of people who use the alternative don't, the signal is hard to ignore.

Cloudflare bought them

January 16, 2026. Cloudflare acquired The Astro Technology Company. All Astro employees became Cloudflare employees. Framework stays MIT-licensed.

The strategic logic is obvious. Vercel has Next.js. Cloudflare needed a framework story. Astro's static-first, edge-friendly architecture is a natural fit for Workers, R2, and D1. Expect Cloudflare-specific features to ship faster than competing platform adapters.

Should you worry? A little. "Stays open source" is a stated commitment, not a contractual guarantee. Governance changes typically lag acquisitions by 12-24 months. But Astro deploys anywhere — Vercel, Netlify, Node, Deno, Hetzner with nginx. We deploy on Hetzner. Cloudflare has zero leverage over our hosting choice. That's the beauty of static HTML.

Astro 6.0

Shipped March 10, 2026. The highlights that actually matter:

Rebuilt dev server on Vite's Environment API. Faster HMR. You won't notice unless your project is large, then you'll notice a lot.

First-class Cloudflare Workers runtime. Unsurprising given the acquisition. If you deploy to Workers, this removes a layer of adapter friction.

Stable Content Security Policy API. Astro is the first JavaScript meta-framework with built-in CSP for both static and dynamic pages. If you've ever hand-rolled CSP headers in nginx and wanted to cry, this is for you. (I have. I did.)

Experimental Rust compiler. Not default yet. Will be. The team is rewriting the compiler in Rust for speed. Early benchmarks show 2x faster rendering. Treat that number as directional — vendor benchmarks always are.

Built-in Fonts API. Sounds minor. Isn't. Google Fonts without the privacy headache and layout shift. Self-hosted, optimized, one config line.

If you're not ready for v6, run 5.17.x. It's stable, battle-tested, and what we're on right now. Upgrade after 6.1 or 6.2 when the integration ecosystem catches up.

Content Collections are the killer feature nobody talks about

This is the feature that sold me. Not the performance. Not the zero JS. The content model.

You define a schema in Zod. You put Markdown files in a folder. Astro validates every file against the schema at build time. Type errors, missing fields, wrong formats — all caught before deploy, not in production at 2 AM.

We have 116 pages: services, industries, tech stacks, case studies, course chapters. Every content type has a Zod schema. Every markdown file is validated. If an engineer adds a case study with a missing stack field, the build fails. Not "renders wrong." Fails. Loudly.

The Content Layer API (stable in 5.0) generalized this further. You can write loaders that pull from anywhere — local files, APIs, headless CMS, databases — into the same type-safe pipeline. Our blog posts live in Sanity. Our marketing pages live in Markdown. Same build, same types, same validation. Both sources.

The AI crawlability angle nobody's writing about

Here's the thing that matters in 2026 and almost nobody is talking about.

GPTBot, ClaudeBot, PerplexityBot, Google's AI Overviews — they fetch your HTML. They don't execute your JavaScript. If your content lives inside a React component that renders client-side, it doesn't exist to them.

Our old Nuxt site was invisible. Zero organic traffic for years. Not because the content was bad. Because the content wasn't in the HTML.

Astro's output is pure HTML. Every word on every page is in the source. AI bots read it. Search engines index it. LLMs can summarize it. We went from zero to 116 fully indexable pages in two weeks. The SEO value of "your content is actually in the HTML" is impossible to overstate in a world where half the web hides behind client-side rendering.

Who else is using it

IKEA, Unilever, Visa, NBC News, OpenAI, Cloudflare's own developer docs, Microsoft, Adobe, Porsche, The Guardian, Bloomberg, Deloitte, LEGO. TechnologyChecker tracks 49,000+ active domains on Astro. Migration data shows a 12:1 ratio of companies moving from Gatsby to Astro versus the other direction.

This isn't an indie framework anymore.

Where Astro falls apart

I'll be honest because nobody else is.

Complex stateful apps. If you're building a dashboard, a Figma clone, a real-time multiplayer game — Astro is the wrong tool. It's content-first. Everything else is a workaround. Use Next.js, SvelteKit, or whatever your team knows.

The ecosystem is younger. Auth, advanced i18n, complex form state — you'll write more glue code than in Next.js. The integrations exist but they're not as mature.

Astro DB was a miss. The hosted database service (Astro Studio) shut down in early 2025. Fred Schott was unusually candid about it: they never found product-market fit. Astro DB still works as a wrapper around libSQL/Turso, but don't pick Astro for the database story. Pick it for the rendering story.

Cloudflare alignment. The framework deploys everywhere today. But Cloudflare-specific features will get priority. If that bothers you philosophically, factor it in.

The bottom line

I run a software engineering studio. We build apps for Fortune 500s. Our own website runs on Astro on an $8.60/month Hetzner VPS with nginx. It builds 116 pages in 2.66 seconds. Lighthouse scores are 95+. Ahrefs health score is 99/100. Every AI bot on the internet can read every word.

The framework won by doing less. Less JavaScript, less complexity, less cleverness. More HTML. More speed. More content that actually shows up when someone (or something) looks for it.

94% satisfaction isn't a fluke. It's what happens when a tool does exactly what it promises and nothing else.

We rebuilt eltexsoft.com on Astro + Sanity. The full teardown: Rebuilding Our Agency Website in 2026.

I run a software engineering studio. We've built apps for Fortune 500s, scaled marketplaces, shipped iOS apps that Apple featured at WWDC. Our own website was running on Nuxt + Contentful and had zero organic traffic.

Zero. For years.

Not because the site was bad. The design was fine. The content was fine. The problem was that Nuxt ships JavaScript, and AI search bots don't execute JavaScript. GPTBot, ClaudeBot, PerplexityBot — they fetch your HTML and move on. If your content lives inside a Vue component that renders client-side, it doesn't exist to them.

So we rebuilt the whole thing. Here's what happened.

Why Astro

I looked at Next.js first. Everyone does. But for a marketing site — services, case studies, blog — Next.js is overkill. You're shipping 85-180 KB of React runtime to render what is fundamentally static text and images. The App Router adds complexity we'd never use. And the CVE list in 2025 was not confidence-inspiring.

Astro ships zero JavaScript by default. A typical page is 5-15 KB of HTML and CSS. That's it. The framework is purpose-built for content-heavy sites: static site generation, Content Collections with Zod validation, built-in sitemap and RSS. State of JS 2025 ranked it #1 by developer satisfaction, 39 points ahead of Next.js.

Cloudflare acquired the Astro Technology Company in January 2026. Framework stays MIT-licensed. If anything, the backing makes the bet safer.

The deciding factor was simpler than all of that: AI bots can read our content now. Every word on every page is in the HTML. No hydration, no client-side rendering, no hoping that Googlebot's renderer feels like executing your JavaScript today.

Why Sanity (and why we left Contentful)

Contentful's April 2025 free-plan crackdown sealed it. 25 content type cap, 100K API calls. Their Premium tier starts at $300/month. We're a 35-50 person studio, not a media company. That math doesn't work.

Sanity's free tier gives us 20 seats, 2 datasets, 10K documents, 1M CDN requests. The Studio is React-based — same skills our team uses for client work. The official contentful-to-sanity CLI migrated our content in one command. And Sanity's structured content model is genuinely better for a site with services, case studies, industries, staffing models, and tech skill pages that all cross-reference each other.

We kept marketing pages (services, industries, tech stacks) as Markdown in the repo using Astro Content Collections. Blog posts live in Sanity where I can publish without touching code. Best of both worlds: engineers own the structured pages, I own the editorial.

The SEO play that actually worked

We started at Domain Rating 21 with zero organic traffic. Zero indexed keywords. The Nuxt site had been invisible to search for years.

The strategy came from running 75+ keywords through Ahrefs Keywords Explorer. What we found was extraordinary: 41 keywords with KD 0-3 representing 25,000+ monthly searches. Several high-CPC keywords ($15-30) had literally zero competition. "Generative AI development services" — 3,000 monthly searches, KD 1, $20 CPC. Nobody had a dedicated page for it.

We built 60 pages targeting those keywords. Services, industries, tech stacks, staffing models, blog posts — each one targeting a specific keyword cluster with FAQ sections and JSON-LD schema.

The content architecture follows what we learned from studying competitors. Vention (DR 71, 17.5K traffic) wins by having a dedicated page for every keyword variant. Their MVP page alone captures 5 keyword variants totaling 1,420 monthly traffic from one URL. That's the model. One page per intent, not five intents crammed onto one page.

Ahrefs MCP changed how I work

This is the part that surprised me most. Ahrefs has an MCP (Model Context Protocol) integration that connects directly to Claude. I can ask Claude to check our site audit, pull keyword data, analyze competitor backlinks — and it queries Ahrefs in real time without me opening the dashboard.

I'd run a site audit, Claude would parse the results, identify the issues, and generate the exact code fixes — meta descriptions that were too long, title tags over 65 characters, broken image references, redirect chains. We went from a health score of 73 to 99 in three sessions. The meta description audit alone covered 31 pages that needed trimming under 155 characters.

The workflow is: Ahrefs finds the problem through MCP → Claude generates the fix → Claude Code applies it to the codebase → push to GitHub → Coolify auto-deploys. The entire cycle from "Ahrefs flagged this" to "fix is live in production" takes minutes, not hours.

Sanity MCP for content operations

Same pattern with Sanity's MCP integration. When we discovered that pasting blog content from Claude's chat interface into Sanity Studio was silently converting relative links (/blog/...) to https://claude.ai/blog/... — 146 links across 13 posts — we wrote a Node script that patched all of them through Sanity's API in one run.

But the MCP connection meant I could verify the fix instantly. "Query all posts for any href containing claude.ai." Zero results. Done. No need to open the Studio, no manual spot-checking.

We also use Sanity MCP to create blog posts, patch SEO fields, publish batches of documents, and query content for audits. I published 36 blog posts through a combination of MCP creation and Studio editing. All with full body content, proper author references, FAQ sections, and internal cross-links.

The legal pages nobody wants to write

Every website needs Terms of Service, Privacy Policy, and Cookie Policy. Every founder hates writing them. Most people use a generator that produces generic boilerplate or pay a lawyer $3-5K.

I found Raj Jha's mill-deterrent-pack — an open-source legal template specifically designed to deter mass-arbitration mills and serial litigants. Three tiers of protection:

• Tier 1: Pre-dispute notice gate with a 12-item disclosure requirement, class-action waiver, AAA arbitration, specific governing law and venue.
• Tier 2: 60-day informal resolution period, two mandatory principal-level meetings, fee-arrangement disclosure, 24-month prior-claims history.
• Tier 3: Pre-merits good-faith review by the arbitrator, claimant-pays cost allocation, bad-faith dismissal with fee-shifting.

It's serious legal engineering. The Terms include an ML training prohibition, a $100 liability cap, and indemnification. The Privacy Policy covers GDPR (with CNPD as lead authority since we're HQ'd in Lisbon), CCPA/CPRA, explicit tracking disclosures, and a "what we don't use" section. The Cookie Policy documents every cookie by name, purpose, and duration.

We adapted it for our entity (Icemint LLC d/b/a EltexSoft, Wyoming LLC) and our specific stack (GA4, Cloudflare, Google Fonts). Took an afternoon. The result is more thorough than what most $5K legal reviews produce, and it's open source.

Ditching GA4 for Cloudflare Web Analytics

While we were at it, we set up Cloudflare Web Analytics alongside GA4. Server-side, no client JavaScript, no cookies. GDPR-friendly by design — there's nothing to consent to because there's no tracking pixel in the browser.

GA4 is still running for now because Search Console integration requires it. But for actual traffic understanding — which pages get visited, where people come from, what devices they use — Cloudflare's server-side analytics gives cleaner data without the privacy overhead.

The Cookie Policy got simpler too. Two Cloudflare operational cookies (__cf_bm for bot management, _cfuvid for rate limiting) plus GA4's _ga cookies. That's the complete list. No pixels. No session replay. No heat maps. The privacy policy says what we don't use, and the list of things we don't use is longer than the list of things we do.

Infrastructure: $8.60/month for everything

The whole stack runs on a Hetzner Cloud VPS (CPX21, $8.60/month). Coolify manages the deployment — Nixpacks builds the Astro site, outputs static HTML to an nginx container. Cloudflare sits in front for CDN, WAF, and DDoS protection on the free tier. Sanity's free tier handles the CMS. GitHub Actions is free. Domain was already paid for.

Total marginal cost: $8.60/month. Down from whatever Contentful was going to start charging us.

SSL is Cloudflare Flexible — they terminate TLS at the edge and send HTTP to the origin. One less thing to manage on the VPS.

What I'd do differently

Start with the SEO strategy, not the design. We built pages and then optimized them for keywords. It should be the other way around. The keyword research should dictate the page architecture. Which pages to build, what to call them, how to structure the URLs — all of that should come from the data.

Verify your content proofread by LLMs before it reaches the CMS. The relative-to-absolute URL resolution bug cost us a full debugging session and a script to fix 146 links. Write content in Markdown, paste Markdown.

Set up Ahrefs site audit on day one. We caught 57 errors on the first crawl that were trivially fixable but had been silently hurting us. Broken favicon references, missing meta descriptions, redirect chains — all invisible unless you crawl.

Nginx redirects need absolute HTTPS URLs when Cloudflare Flexible SSL is in front. Relative redirects resolve to http:// at the origin because Cloudflare connects to your server over HTTP. Every rewrite ... permanent needs the full https://yourdomain.com/path/ target. We had 25+ redirects silently double-hopping (301 → http → https) before catching this.

Disk space on small VPS instances fills up fast with Docker. Coolify's Nixpacks builds accumulate overlay layers. We hit 100% disk on a 40GB instance after 16 deployments. Weekly docker system prune -a --volumes -f via cron is mandatory.

The numbers so far

• 116 static HTML pages
• 36 blog posts with full body content
• 13 case studies
• 10 industry pages
• 9 tech stack pages
• 22 course chapters (web edition of my book, "42: The AI Builder's Stack")
• Lighthouse mobile: 95+
• Ahrefs health score: 99/100
• Page weight: 5-15 KB HTML + CSS per page
• Build time: 2.66 seconds for 116 pages
• Deploy: push to GitHub → Coolify auto-build → live in under 3 minutes

We're still at DR 21. The content has been live for less than two weeks. Position data starts appearing at 60-90 days. But the foundation is there: 41 keywords with KD 0-3 targeting 25,000+ monthly searches, pure HTML that every bot on the internet can read, and a publishing workflow where I write in Sanity and it's live in minutes.

Ask me again in 90 days.

The stack: Astro + Sanity + Hetzner + Coolify + Cloudflare. Legal templates: mill-deterrent-pack by Raj Jha. SEO: Ahrefs. Code: Claude Code. The site: eltexsoft.com