Resume Factory v3.0

Architectural Deep Dive

Or, The Great Sanity Migration

TL;DR

We spent two weeks building a Python resume pipeline. It worked. Then we immediately decided to throw it away and rebuild it in Sanity + React. This is that story.

The Uncomfortable Truth About v2.0

Let’s be honest: Resume Factory v2.0 is fantastic… for me. I love command-line tools. I love Python scripts that go brrr and spit out perfectly formatted PDFs. I love the green checkmark in my terminal.

But here’s what I don’t love: the fact that nobody else can use it.

Want to help me proofread a bullet? Better learn Python. Want to add a new variant? Hope you’re comfortable with CSV schemas. Want to preview changes? Run three separate scripts in sequence. It’s beautiful engineering wrapped in a hostile UX.

Enter: The Sanity Check

So we asked ourselves: “What if we could keep all the good parts (structured data, variant logic, master fallback) but make it… you know… usable?”

The answer: Migrate to Sanity CMS + React.

This isn’t a rewrite; it’s a replatforming. We’re not changing what the system does—we’re changing who can do it.

The PRD: A Love Letter to Structured Thinking

Before writing a single line of code, we wrote a 32-page Product Requirements Document. Yes, for a personal resume tool. Yes, I’m aware this is overkill. No, I don’t care.

The PRD covers everything:

It’s a case study in treating personal projects like product launches. Because if I can’t ship a resume builder with proper documentation, how can I expect to ship enterprise software?

The Open Question: Monorepo or Divorce?

Here’s where it gets spicy. Right now, we have sugartown-cms (Python + WordPress). Soon, we’ll have resume-factory (Sanity + React). The question is: do they live together or apart?

Option 1: The Monorepo (Cozy But Complicated)

Structure:

Pros: Shared design system, single deployment pipeline, version control stays unified Cons: Python + Node.js dependencies clash, harder to open-source resume-factory independently

Option 2: The Clean Split (Freedom With Overhead)

Structure:

Pros: Clear separation of concerns, easier to white-label resume-factory, independent deployments Cons: Have to maintain shared design system as a separate package, potential version drift

Option 3: The Hybrid (Because We Love Pain)

Structure:

Pros: Monorepo benefits with logical separation, turborepo/nx for orchestration Cons: Most complex setup, need tooling expertise to maintain

The Verdict: Monorepo Wins

We’re going with Option 3 (Monorepo with Workspaces) because:

What’s Next?

We’re currently in Phase 0: Schema Design. The Python pipeline stays live while we build v3.0 in parallel. The migration happens when Sanity reaches feature parity with v2.0.

The Timeline:

Why This Matters

On the surface, this is about making better resumes. But the real project is about building reusable infrastructure for structured content.

The same Sanity + React patterns we’re building for resumes can power:

We’re not just migrating a resume builder. We’re building a content assembly engine that happens to start with resumes.

Next up: The Schema Wars (or: How Portable Text Almost Broke Me) 🎯