Part 4: Building PhysicianTechnologist - Deployment and Future Vision

The Deployment: Where Theory Meets Reality

Choosing Vercel: The Path of Least Resistance

The deployment decision took 30 seconds. I asked Claude where to deploy, it suggested Vercel for its Next.js optimisation and automatic CI/CD, and I agreed. Why overthink it when you could be shipping?

The First Deploy: Everything Breaks

$ git push origin main
# Vercel: "Deployment failed"

Build Error:
- Type error in 14 files
- Missing environment variables
- Module not found: 'openai'
- RLS policies blocking everything

The localhost illusion shattered. Production is a different beast entirely.

The Environment Variable Maze

What started as 5 environment variables in development somehow became 23 in production. Each one told a story of a feature added, an integration attempted, or a service adopted. The "simple blog" needed configurations for Supabase, OpenAI, Google Analytics, Vercel Analytics, email services, and more.

After 7 failed deployments, Claude and I worked through TypeScript errors from strict mode, missing API route exports, date serialisation issues in getStaticProps, dynamic imports breaking Edge runtime, and unused variables blocking the build. Forty-five minutes later, we finally saw "Deployment successful 🎉".

Writing the First Blog Posts: Content Meets Platform

The Irony of the Empty Blog

I had built semantic search with vector embeddings, an AI-powered chat interface, newsletter automation, an analytics dashboard, and a content recommendation engine. What I didn't have was content.

Writing the first post, "A GP Registrar's Journey with Heidi AI Scribe," revealed the platform's quirks. The markdown editor worked flawlessly and image uploads were seamless, but the status workflow required three clicks to publish. Embedding generation took 30 seconds. The newsletter queue triggered despite having zero subscribers. Related posts showed nothing because you need at least two posts for that feature to make sense.

My content creation workflow became a comedy of over-engineering. Write in Obsidian for the better markdown experience, copy to the platform editor, add metadata, save as draft, preview, submit for review to myself, approve as myself, publish, wait for embeddings, check if newsletter queued, realise I have no subscribers, question life choices.

The 404 Mystery: When Production Diverges

Blog posts worked perfectly locally but returned 404 errors on production. Claude diagnosed it as a static generation issue - the posts existed in the database but weren't being built during deployment. Even with fallback: 'blocking' which should generate pages on-demand, it wasn't working. The solution? Force rebuild deployment. The reality? Next.js ISR is more complex than the documentation suggests.

The Analytics Reality Check

Week 1 analytics painted a humbling picture: 3 visitors (all me), 147 page views (me testing), 0% bounce rate (I was very engaged with my own content), zero newsletter subscribers, and 23 search queries testing if search actually worked.

I had built analytics infrastructure that could handle thousands of concurrent users with real-time visitor tracking, geographic distribution maps, device breakdown charts, and Web Vitals monitoring. What I actually needed to know was simple: did anyone read my post?

Maintenance Reality: The Hidden Costs

The daily development ritual became predictable. Run npm dev, get a module not found error, run npm install, get a port 3000 already in use error, kill the process, try again. Check production, find the Supabase free tier has paused the database. Restart everything.

The dependency updates grew exponentially. Month 1 brought 23 packages needing updates. Month 2 had 47. By Month 3, npm audit was screaming about 68 vulnerabilities, 2 critical. Running npm audit fix would break three components. Running it with --force would break everything. Git reset --hard HEAD became my most-used command.

What's Next: The Roadmap to Sanity

The path forward is clear: simplification. Remove unused features, consolidate the sprawling API endpoints, eliminate the newsletter system until there are actual subscribers, and perhaps admit that vector search for single-digit blog posts is unnecessary.

Then comes optimisation - proper caching, monitoring and alerts, improved build times, and yes, finally adding those tests Claude kept suggesting. Eventually, the focus needs to shift to what actually matters: creating content, building an audience, and only re-enabling features when they're genuinely needed.

The dream, perhaps foolishly, is to eventually open source this over-engineered platform as "BlogOS" - a cautionary tale and learning resource. Help others avoid my mistakes, or at least make different ones.

If I Started Over Today

Knowing what I know now, I'd keep Next.js with TypeScript as the foundation, Supabase despite its complexity, and the CLAUDE.md pattern that made AI development so effective. The component library choices of Tailwind and Radix UI proved solid.

But I'd start with MDX files instead of a database, skip the vector search until hitting 50+ posts, use an existing newsletter service, implement simpler authentication with NextAuth.js, and eliminate the complex status workflow entirely. Most importantly, I'd focus on writing content instead of building features - platform development is just sophisticated procrastination.

The Technical and Personal Lessons

The technical lessons were valuable but predictable. Over-engineering is surprisingly easy when building is frictionless. Production behaves nothing like development. Simple features hide complex edge cases. Type safety genuinely pays dividends. Documentation, however boring, is crucial.

The AI collaboration lessons were more nuanced. Claude Code is an incredible accelerator, but acceleration without direction just gets you lost faster. It suggests what's possible, not what's necessary. Human judgment remains absolutely irreplaceable, and perhaps most interestingly, the tool shapes the solution in ways you don't expect.

The personal lessons hit harder. Building is addictive - there's always one more feature to add. Shipping is scary - suddenly your code faces reality. Perfect is genuinely the enemy of done. Users don't care about your elegant architecture or clever abstractions. And despite all the technology, content is still king.

The Unexpected Success: Learning in Public

The real value wasn't the platform itself but the journey of building it. This blog series about building the blog has resonated more than the blog ever could. The honest discussion of over-engineering, real code examples, admission of mistakes, and the human side of AI collaboration - these stories connect with developers facing similar challenges.

Final Reflections: Was It Worth It?

Financially? Absolutely not. I spent hundreds of hours building a free blog platform that already exists in dozens of forms.

Educationally? Without question. I learned modern web development patterns, database design principles, AI collaboration techniques, deployment realities, and most importantly, the value of shipping over perfecting.

Professionally? Yes. Every skill gained is immediately applicable to real projects.

Personally? It's complicated. The satisfaction of building something from scratch is real and valuable. But so is the maintenance burden that follows you forever.

The Claude Code Verdict

Claude Code is revolutionary, but it's not magic. It excels at rapid prototyping, learning new technologies, handling boilerplate, refactoring existing code, and solving specific technical problems.

It struggles with knowing when to stop adding complexity, understanding actual business needs, maintaining simplicity, making strategic decisions, and designing user experiences that make sense to humans rather than machines.

The Future of PhysicianTechnologist

The platform exists. It works. It's absurdly over-engineered for a personal blog. But it's mine.

Moving forward, the focus shifts to content creation - the platform is done, or at least done enough. I'll simplify gradually, removing complexity as I go. These technical posts about the building process seem to resonate, so I'll continue sharing the journey. Building in public creates unexpected connections. And hopefully, I can help others learn from my elaborate mistakes.

Closing Thoughts: The Beauty of Building

There's something beautiful about building something unnecessarily complex. It's not efficient or practical, but it's deeply satisfying. I built a platform that could handle millions of users for an audience of dozens. I implemented enterprise patterns for a personal blog. I automated everything for an audience of one.

But I learned. I grew. I shipped. And in the end, that's what matters.

Epilogue: A Message to Future Builders

If you're considering building with Claude Code or any AI assistant, start small - you can always add complexity later. Ship early because perfect doesn't exist. Document everything because your future self will thank you. Embrace mistakes as the best teachers. And most importantly, have fun - if you're not enjoying it, why build?

The tools will get better. The AI will get smarter. But the fundamental challenge remains: knowing what to build, not how to build it.

Choose wisely. Build boldly. Ship regularly.

And when you inevitably over-engineer something, write about it. Others will learn from your journey too.

Thank you for following this journey. If you're building something with AI assistance, I'd love to hear about it. Reach out via contact or connect on LinkedIn.

Navigate This Series

← Previous: Part 3: Claude Code Acceleration and Development

The Complete Series:

• •Part 1: Discovery and Initial Learning
• •Part 2: Architecture Decisions and Database Design
• •Part 3: Claude Code Acceleration and Development
• •Part 4: Deployment, First Posts, and Future Vision (You are here)

Resources:

• •GitHub Repository (Coming soon - needs cleanup first)
• •Platform Architecture Diagram
• •CLAUDE.md Template
• •Over-Engineering Anonymous Support Group (I should start one)