The Setup
Two sites, one domain, shared infrastructure:- amandamashburn.com — Personal site. Who I am, what I do, how to work with me.
- docs.amandamashburn.com — Public knowledge base. Evergreen articles, my extended mind system, things I’m learning.
| Component | Role |
|---|---|
| GoDaddy | DNS — routes traffic to the right place |
| GitHub | Version control — all content lives in markdown files |
| Vercel | Hosts the personal site |
| Mintlify | Hosts the knowledge base |
| Cloudflare R2 | Object storage — images and assets for both sites |
Why Build It at All
I have a lot I want to share — notes, frameworks, things I’ve learned over the years. But for a long time, I didn’t share much of it. The friction wasn’t a lack of ideas. It was that I didn’t have a system that felt right. Squarespace works. Notion works. But they didn’t align with what I wanted. And that misalignment was a legitimate blocker. I couldn’t bring myself to pour good content into a vessel that felt wrong. This might sound precious, but I think the infrastructure — the system through which knowledge is written, organized, and delivered — is as important as the content itself. The medium shapes the experience on both ends. For the author, a misaligned system creates friction that makes it hard to do the work. For the reader, even if they can’t articulate it, a well-crafted experience feels different than something cobbled together. Think of a book. You can print the same words on cheap paper with a flimsy cover, or bind it in leather with pages that are pleasant to touch. The content is identical. The experience isn’t. Or think of power lines: overhead wires and buried cables deliver the same electricity, but one is more resilient, more visually clean, more considered. The function is the same. The craft is not. Steve Jobs understood this. Apple made the inside of the computer beautiful even though users would never see it. Because the parts you can’t see still affect the integrity of the whole. They affect how it feels to build, how long it lasts, how much you trust it. I don’t know why I have such a strong urge to build my own systems rather than rent someone else’s. It’s a compulsion I can’t fully explain. But I know this: I couldn’t start sharing until the foundation felt right. Now it does.Looks Simple, Wasn’t Easy
From the outside, this setup looks deceptively straightforward. Two sites, a few services, some DNS records. How hard could it be? Harder than I expected. Once you get into the details, there’s a lot of tinkering. Each platform has its own interface, terminology, and quirks. DNS propagation doesn’t happen instantly. Things that should connect cleanly sometimes don’t. Error messages are cryptic. You make one decision and it unlocks three more decisions you didn’t know you needed to make. I ran into a Mintlify error that told me my domain was “already added” — it wasn’t. Turns out it was an issue on their end, but debugging that took time and back-and-forth. That’s the kind of thing that doesn’t show up in architecture diagrams. The point isn’t to complain. The point is: if you’re building something similar and it’s taking longer than you expected, that’s normal. The finished product looks clean because the messiness got worked out along the way.Design Principles
A few values drove every decision: Portability. All content is markdown in Git. If any platform disappears tomorrow, I can move the files somewhere else and be back online quickly. No proprietary formats. No content trapped in a database I don’t control. No vendor lock-in. Every component is swappable. Don’t like Vercel? Switch to Netlify or Cloudflare Pages. Mintlify not working out? Move the markdown to Docusaurus or Astro. The domain is mine. The content is mine. The services are just rendering layers. Separation of concerns. The personal site and knowledge base serve different purposes and audiences. Keeping them separate means each can evolve independently. I can redesign one without touching the other. Built to scale. The system is designed to grow. I can addblog.amandamashburn.com or tools.amandamashburn.com without rethinking the architecture. Add a DNS record, spin up a new repo, point it at a host. The pattern holds. I didn’t want to build something that works for today — I wanted something that works for where I’m going.
Aesthetics matter. Functional isn’t enough. I care about how things look and feel. The architecture diagram you see above went through several iterations until it matched the clarity I wanted. That same attention applies to the sites themselves.
Why These Tools
Vercel — I have AWS experience. I spent a semester learning it academically and worked with it in an enterprise environment — Terraform, EC2 instances, S3, DynamoDB. At Ally Financial, I contributed to building a secure AWS environment for hosting machine learning models. But AWS makes me squirm for a project like this. It’s powerful, but it’s also complex in ways that create risk. Security is easy to misconfigure — leave a port open, set a permission wrong, and you’ve got a problem. Billing is unpredictable and opaque. I’ve seen enough horror stories of unexpected charges to be cautious. There’s a time and place for AWS. This isn’t it. For a personal site, I wanted something simpler, more straightforward, and secure by default. Vercel deploys from GitHub with zero configuration. It’s fast, reliable, and stays out of my way. Right tool for the job. Mintlify — I chose them specifically because they’re building for both humans and machines. Docs that are readable and structured for AI, search, and automation. They have serious customers and momentum. I’m confident they’ll keep building something great. Cloudflare R2 — S3-compatible object storage without egress fees. I’m using it for both sites, so centralizing assets made sense. GitHub — Industry standard. Version history, collaboration if I ever want it, and the content stays portable. GoDaddy — Consolidated my domains here after Google Domains shut down and Squarespace inherited everything. Not glamorous, but it works.How I Built It (With AI)
I’m a technical non-engineer. I have a CS degree and 10+ years working in technical environments — but my roles have focused on knowledge management, product management, governance, compliance, and developer relations. I’ve worked alongside engineers in infrastructure and software development teams. I’ve put hands on keyboards for exposure and perspective. But typically, I’ve been focused on all the other things that needed to get done — the work that enables engineers to do their work. I understood what I wanted to build. I did not have all the knowledge to execute it cleanly on my own. I used Claude and Claude Code throughout the entire process:- DNS configuration — Claude walked me through exactly which records to add in GoDaddy and what values Mintlify needed.
- Debugging — When Mintlify threw a “domain already added” error, we troubleshot it together and identified it was on their end.
- Architecture decisions — I talked through options and tradeoffs. What should live where? How should things connect?
- This diagram — Claude built it based on my description. I asked for minimalist. We iterated on colors, fonts, layout until it was right.
- This article — I described what I wanted to communicate. Claude helped structure and write it.
Level of Effort
I tinkered with this on and off over a couple of months. But if I sat down with a clear playbook and focused, this is roughly 10-15 hours of work for someone with my background. That includes: domain transfers, DNS configuration, setting up deployments, connecting object storage, debugging issues, and learning each platform’s quirks. And it was a lot of learning. Git and GitHub were my foundation — I was comfortable there. But Vercel, Mintlify, and Cloudflare R2 were all new to me. Each platform has its own mental model. You’re not just configuring things; you’re learning how the tool thinks so you can work with it effectively. An experienced DevOps engineer could do this faster. But that’s the point — I didn’t need to be one. And I didn’t need to pull one off other work to help me.Why This Matters
This is not hard work for a senior engineer. It’s well below their pay grade. But it’s exactly the kind of work that piles up, gets deprioritized, or requires waiting for someone else’s availability. With AI, I executed this myself. No tickets filed. No waiting in a sprint backlog. No engineer context-switching away from harder problems to help me configure DNS. This is the shift: technical non-engineers can now self-serve on work that previously required specialists. That frees up those specialists for the problems that actually need them.What’s Next
The infrastructure is done. And “done” is the key word — this isn’t something I’ll need to revisit constantly. The setup took effort, but it should require relatively little maintenance going forward. The pipes are connected. The foundation is laid. Now I can shift focus to the content — the ideas, the things worth sharing. But the infrastructure isn’t separate from that. It’s part of it. The vessel shapes what it holds.This is how I approach building: Modular, portable, intentional. Start with what you need, design for where you’re going, and choose tools you can leave if you have to. Every component must serve a purpose. There’s no fluff in this system. Nothing here exists because it seemed like a good idea or because someone else was doing it. Every piece is wanted and needed. Let friction prove the need. I don’t rush to solve discomfort with new tools, added complexity, or irreversible choices. Friction is data. I let real-world experience demonstrate a clear need before I build or buy. This system exists because I felt the friction of not having it — repeatedly, over time — until the need was undeniable.