I'm a full-time clinic director. I see patients, perform surgeries, and manage a team. My days start early and end late. Building a personal website was never at the top of my priority list.
But I needed one. Not for the clinic — that already exists. For myself. A place where the plastic surgeon and the engineer could exist together without the constraints of a medical blog or a social media platform.
This is how slowdoctor.dev went from nothing to deployed in about a week.
Why build it at all
The short answer: SEO and GEO.
Search engines and AI systems are increasingly how people find doctors. Google indexes structured data. AI models cite sources with clear, well-organized information. A personal site with proper schema markup — Person, Physician, MedicalBusiness, all wired together — gives these systems something concrete to reference.
My clinic website handles the clinic. But when someone asks an AI "who is a plastic surgeon in Gangnam who also codes," I want there to be a real answer pointing to a real site. That requires a domain I own and content I control.
The longer answer is simpler: I had things I wanted to write that didn't belong anywhere else.
The timeline
Here's what actually happened, based on the git history:
April 6 — create-next-app. The first commit. Nothing but a scaffold.
April 7 — The big push. Full site build in a single day: home, physician, engineer, links, blog, CV — six pages total. SEO metadata, sitemap, RSS feed, structured data, content editing tools. Sixteen commits. Between patients and after clinic hours.
The CV page deserves a mention. Most personal sites for doctors either skip the CV entirely or dump a PDF. I wanted something that lived on the site — education, training, publications, all structured and searchable. It also feeds into the JSON-LD schema, so search engines can connect the publications to the person.
April 8 — Content refinement. Restructured the physician and engineer pages, added social icons, improved accessibility, added an eighth publication I'd verified on ResearchGate.
April 9 — Schema hardening. Deduplicated JSON-LD constants, aligned design with brand specs, added structured Person/Physician schema with @id anchoring.
April 10 — Clinic only. No commits.
April 11 — Deployment day. Bought the domain in the morning, configured Cloudflare Workers between appointments, deployed during lunch. Then five pull requests in a row: profile image, content pipeline simplification, SEO fixes, Codex code review, and final refinements.
Every single day from April 7 through 11 was a full clinic day. Surgeries, consultations, follow-ups. The commits happened in the margins — early mornings, lunch breaks, late evenings. Around 40 commits across five working days, squeezed into the gaps of a regular clinical schedule. One domain purchase at the very end, when the site was already built and just needed somewhere to live.
Building with AI
I should be direct about this: I didn't write every line of code by hand. I used Claude Code for the bulk of development and OpenAI Codex for code review.
Claude Code handled the heavy lifting — scaffolding pages, writing components, setting up the build pipeline, generating structured data schemas. I directed. It executed. When it made mistakes, I caught them and corrected course. When it made good decisions, I kept them.
Codex reviewed the codebase after the main build was done. It filed a PR with fixes for schema issues, validation gaps, and documentation inconsistencies. The kind of careful, methodical review that's easy to skip when you're building fast.
This workflow — Claude Code for creation, Codex for review — turned out to be surprisingly effective. Not because the AI did everything perfectly, but because it compressed what would have been weeks of evening-and-weekend work into a few focused days.
What I actually did
The AI wrote code. But the decisions were mine.
Which pages to include. What to say on each one. How to structure the navigation. Whether the site should be dark or light. What the physician page should emphasize — not credentials, but philosophy. What the engineer page should show — not skills, but actual projects.
I decided to remove the API-based content classification system that had been built. It was clever, but unnecessary. Some things are better decided by hand.
I decided to use a simple axes system for blog posts — three numbers adding up to 10, split across physician, engineer, and life. No automation. Just a moment of reflection before each post: what is this really about?
I decided to buy the domain last, not first. The site needed to exist before it needed an address.
AI usage vs. AI results
There's a distinction I keep thinking about. Using AI tools is easy. Everyone can prompt. The gap is between using AI and producing something with it.
I've seen people spend hours refining prompts and end up with nothing shipped. I've also seen people ship things that clearly nobody reviewed — AI-generated content with that unmistakable hollow quality.
The sweet spot, I think, is treating AI as a collaborator who works fast but needs supervision. You bring the judgment. It brings the speed. Together, you build something that neither of you would have built alone — and you build it in a week instead of a quarter.
This site is a small example of that. It's not a complex application. It's five pages and a blog. But it's live, it's mine, and it exists because I stopped treating "build a personal site" as a someday project and started treating it as a week-long sprint with the right tools.
What's here now
The site is simple. Dark background, one gold accent color, generous whitespace. Six pages:
- Home — who I am, in one screen
- CV — education, training, publications, structured and searchable
- Physician — what I care about clinically: slow-aging, scars, natural results
- Engineer — what I build: clinic tools, this site, things that solve real problems
- Links — everything connected in one place
- Blog — this, and whatever comes next
No animations. No interactive demos. No newsletter signup. Just words and structure, deployed on Cloudflare Workers, building to static HTML in seconds.
What comes next
I don't have a content calendar for this blog. That feels right. The clinic channels have schedules and strategies and editorial calendars. This site doesn't need that.
I'll write when I have something to say. About medicine, about engineering, about the intersection where the two meet. About building things that work and last.
The site is stable now. The structured data is in place. The domain is live. The hard part — which was never the code — is writing things worth reading.
We'll see how that goes.