Why I run my portfolio site on the same stack I use at work

My portfolio site runs Next.js 16, Payload CMS 3, PostgreSQL with pgvector, and deploys via Cloudflare. The same technologies I use at FinanceOps every day. This is not laziness. It is the most deliberate technology choice in my career.

Generate a realistic dark editorial illustration for a fintech engineering article: layered ledger rows, payment states, query bottleneck cues, subtle SQL-console influence, deep navy and amber palette, 16:9, no text, no clip art, no fake corporate stock feel.

By this point I cared less about sounding smart and more about making the tradeoff legible. It also builds on what I learned earlier in “Building a fintech reconciliation engine that handles ten million transactions a day.” The systems had enough history that every database or eventing opinion had receipts behind it. That is the same posture I now bring to longer-lived experiments like ftryos and pipeline-sdk: if the constraint is real, say it plainly and design around it.

Editorial supporting image for the section "The Gym Analogy" in the article "Why I run my portfolio site on the same stack I use at work". Show open laptop with SQL query plan or ledger-like table visible, printed reconciliation notes, payment terminal receipt, notebook full of arrows and constraints for "Why I run my portfolio site on the same stack I use at work". Focus on one operational artifact that makes the post feel lived-in rather than conceptual. Color palette: deep blues, oxidized steel, warm amber monitor spill. Mood: measured, confident, strategic, scarred enough to sound calm while saying hard things. Composition: 16:9 landscape image, documentary/editorial feel, no text overlays, no stock-photo polish. Avoid: No floating database icons, no cartoon locks, no holograms, no generic fintech stock imagery, no text overlays.

The Gym Analogy

Athletes do not train by playing games. They train in the gym, where they can isolate specific muscles, push past failure safely, and experiment with form without the pressure of competition. The portfolio is my engineering gym. Production at FinanceOps is the game.

On the portfolio site, I can experiment with zero consequences. Try a new Next.js caching strategy. Test a different PostgreSQL indexing approach. Explore Payload CMS features that we have not adopted at work yet. If something breaks, my personal site is down for an hour. Nobody loses money. Nobody files a ticket. I fix it, learn from it, and bring the knowledge back to work.

The key is that the experiments are directly applicable. If I ran my portfolio on a different stack, the learning would be interesting but abstract. Because the stack is identical, every optimization I discover, every bug I debug, and every pattern I develop transfers directly to production work.

What the Portfolio Has Taught Me

Specific things I learned on the portfolio that directly improved FinanceOps production:

• Payload CMS custom field hooks for automated content validation. I built a slug-generation hook on the portfolio that became the template for FinanceOps’s automated compliance tagging.
• pgvector performance tuning. The RAG pipeline on my portfolio chatbot uses the same embedding model and vector search patterns as FinanceOps’s internal knowledge base. I tuned HNSW parameters on the portfolio first, where bad performance means a slow chatbot, not a slow business operation.
• Cloudflare Workers edge caching patterns. The portfolio uses edge caching for static pages with on-demand revalidation. The same pattern now powers FinanceOps’s public documentation site.
• Next.js App Router migration gotchas. I migrated the portfolio from Pages Router to App Router six months before we started the same migration at FinanceOps. The list of pitfalls I compiled saved the team an estimated two weeks of debugging.
• PostgreSQL connection pooling under sustained load. The portfolio’s chat system stress-tested our pgBouncer configuration in ways that CI tests never could.

Why Not Use Something Different

The counterargument is that personal projects should be playgrounds for exploring new technologies. Try Rust. Build something in Go. Experiment with Svelte. Broaden your horizons.

I did that for a decade. I have personal projects in Python, Go, Ruby, and Elixir. Each one taught me something, and none of them made me better at my day job. The learning was broad but shallow. I understood the syntax and conventions of five languages without mastering the deep operational knowledge of any production stack.

The shift to running the same stack for personal projects was a deliberate choice to prioritize depth over breadth. I know PostgreSQL deeply because I operate it in two environments. I know Next.js deeply because I have hit its edge cases in both low-stakes and high-stakes contexts. I know Payload CMS deeply because I build with it every week, not just when a work ticket requires it.

The Professional Benefit

When I interview for roles or discuss architecture with other engineering leaders, the depth is visible. I do not say “I have used PostgreSQL.” I say “I have tuned pgvector HNSW parameters for 768-dimensional embeddings and found that ef_construction of 200 gives diminishing returns beyond 150 for our query patterns.” That specificity comes from operating the same technology in multiple environments over months and years.

Create a realistic systems-style editorial image: simplified financial workflow, tidy relational structure, subtle success signal, graphite and ledger-green palette, 4:3, no text labels, no infographic clip art.

By the time I wrote this, the lesson was bigger than the tool or incident. The job had become setting defaults a team could trust, then proving those defaults in systems like ftryos and pipeline-sdk. That is leadership work, not just technical taste.

The homelab is the gym. Production is the game. Running the same stack in both means every personal project makes you better at your job, and every work challenge makes your personal projects more sophisticated.

I will probably run this stack for the next five years. Not because I am uninterested in other technologies. Because the returns on depth compound faster than the returns on breadth, and my career at this stage benefits more from being world-class at one stack than adequate at five. The portfolio is the evidence. The production system is the proof.

Using the same stack for personal projects and professional work creates a compounding knowledge advantage. Every problem I solve on the portfolio site teaches me something applicable to the production systems I maintain at work, and every production debugging session makes my personal projects more robust. The stack convergence was not intentional at first — I chose Next.js and Payload CMS for the portfolio because they were the best tools for the job — but the knowledge transfer became the most valuable side effect. Engineers who maintain personal projects in their professional stack are not wasting time. They are building depth that compounds over years and surfaces during the moments that matter most: production incidents, architecture decisions, and technical evaluations that require hands-on experience rather than documentation familiarity.