Tooling and Developer Experience

Great developer experience compounds over time. The minutes saved by strict linting become hours saved in debugging. The clarity enforced by good documentation becomes weeks saved in onboarding. DX is an investment in future velocity — and I treat it as essential, not optional.

Key takeaways

• DX is about clarity and discipline, not just fast pipelines
• Strict guardrails (TypeScript, linting) catch issues before they reach CI
• Good onboarding docs and clear README files accelerate every new contributor

My Priorities

For me, developer experience (DX) isn't just about fast builds or shiny tools. It's about clarity, discipline, and rigor. Code should be easy to read, understand, and maintain. Too often, DX is sacrificed for UX or speed of shipping. That's understandable in the short term — but in product-oriented projects, it shouldn't come at the cost of DX altogether. If we're in it for the long run, we need strong foundations.

Reliability first, speed second: A fast pipeline that fails silently is worse than a slower one that's solid

Strict guardrails: TypeScript and lint rules are not negotiable — they catch issues before they ever hit CI

Documentation matters: There's nothing worse than being parachuted into a repo with no README and no guidance. Good docs and clear onboarding save time and frustration

Why I Built Voyage Vibe as a Template

At some point I realized each project started with the same complaints: setup was brittle, pipelines too slow, tooling inconsistent. So I created Voyage Vibe not just as a travel buddy app, but as a rock-solid template project.

It pulls together versatile tools that make sense across many stacks:

• TurboRepo for monorepo orchestration
• Storybook for atomic UI components
• Plop for generators and consistency
• Stryker for mutation testing
• Maestro for e2e flows

The goal: spin up a project in minutes, confident that the tooling is already robust.

Why I Like Monorepos

Coming from a frontend-only background, I remember how frustrating it was to be blocked because backend code was invisible to me. Today, I work across the stack, and monorepos give me global visibility:

• I can trace issues end-to-end instead of guessing where they come from.
• Teams can gate specific workspaces while still seeing how everything connects.
• Knowledge flows better, silos break down.

CI/CD: Fast but Strict

I've seen both extremes: on Richemont, pipelines ran for nearly two hours to deploy apps. On GetGround, I refactored the web app pipeline from 10 minutes down to under 5 — cutting the time by more than half.

My philosophy is simple:

• Strict gates are non-negotiable. Every commit should pass linting, typing, tests, audits.
• Feedback must be fast. Developers shouldn't wait hours to know if something broke.

Guardrails and Onboarding

I set up very strict TypeScript and lint rules. It's not about making life harder — it's about surfacing potential issues early.

For onboarding, I always combine written docs (a clear README with expectations) and direct guidance (a call to walk new devs through the project). And I make sure people know they can reach out whenever they're blocked. Clear direction + open door = smoother ramp-up.

Observability & Cost

Frontend apps: Crash reporting and performance monitoring

Backend: Structured logging

Infrastructure: Optimizations that reduce cost without sacrificing quality

DX isn't just local — it extends to how systems behave in production.

Small Wins

Some of my favorite DX moments come from refactoring messy code. It's not glamorous, but rewriting something into a cleaner structure is often the change everyone notices and thanks you for.

My Philosophy in One Line

Set up strong rules at the beginning — and stick to them.