What I Did Before Shipping My First Personal Site (kimura512.dev)

Conclusion

When shipping kimura512.dev for the first time, the biggest time sink wasn't writing feature logic—it was transforming the project into something a third party could actually read and trust. A website running only on localhost with unclear operator identity, no contact route, and no explicit privacy statement fails as a portfolio. Before going public, I put About, Privacy, Contact routes, and a baseline set of experiential essays into the very same milestone.

1. Repository and Build Hygiene

Locally, dependencies are strictly pinned with pnpm; production deploys follow pnpm run build followed by wrangler deploy. API keys reside strictly within Cloudflare Workers secrets, and .env files are never committed to version control. To avoid confusion, I instituted a non-negotiable rule: "Never push a commit to production if the local build fails." Running pnpm build before every push catches type regressions and routing mismatches long before they reach live users.

2. Pre-launch Visual Checklist

Before every deployment, I manually verify several critical UI points in an actual browser: ensuring no placeholder "Coming Soon" cards linger on the homepage, checking that localized routes with language prefixes do not return 404s, confirming open graph meta tags, and testing the live contact form. Recording these checkpoints as an explicit checklist prevents accidental omissions during late-night releases.

3. The Content Baseline

Showcasing only project works cards makes a personal site feel one-dimensional. I prepared several in-depth articles detailing technical decisions and post-mortems to avoid shipping a thin site with mere "Hello World" placeholders. My publishing threshold was simple: "Would this article genuinely help someone solving the same problem?" Having substantive prose at launch provides credibility when potential clients or collaborators visit.

4. Post-Deployment Verification

Once deployed, I immediately verify that blog listings, individual articles, and privacy pages return HTTP 200 on the apex domain. While Search Console verification can follow later, spotting unintended noindex directives early is paramount. I routinely inspect page HTML source in incognito windows to bypass local caching and verify metadata directly.

5. Domain Routing and Email Consolidation

All incoming inquiries are consolidated through info@kimura512.dev, synchronizing form destinations with the About page and footer credits. Inconsistent contact addresses confuse both users and operators. Every release involves sending a test message to ensure end-to-end delivery before marking the release complete.

6. Navigational Cohesion

Clear footer links ensure direct access to Blog, About, Privacy, and Contact from every subpage. Operator credentials reside cleanly in About, while incomplete side projects are removed from the homepage. A first-time visitor should be able to navigate the entire site seamlessly with single-click hops.

7. Local vs. Production Parity

Because local hot-reloading masks production edge cases, routing quirks and trailing-slash redirects must be verified against actual production builds. Since Contact routes dispatch emails through Workers API endpoints, validating parity between local staging and the production network prevents silent submission failures.

8. Separation of Portfolio and Prose

The homepage serves as a focused portfolio, while extensive narratives live on the blog. Framing lessons learned and technical architectures as dedicated articles is far more valuable and readable than cramming text onto project cards. During the first week post-launch, I froze new feature additions to focus exclusively on fixing typos, verifying external links, and resolving policy inconsistencies.

Summary

A first public release does not require perfection; it requires explainability. Aligning infrastructure, legal disclosures, and editorial content in the same sprint establishes operational credibility that pays compounding dividends.

FAQ

Q. What is the fastest path to shipping?
Bundle About, Privacy, Contact, two substantive articles, and the removal of unfinished cards into one sprint. Once that core foundation is live, you can iterate steadily.

Q. How many dry runs before pointing DNS?
I tested three deployments on preview Workers and two full audits after switching DNS to the apex domain. Staging the build on preview environments eliminates live surprises.