Why I build my own products alongside client work
Clients benefit when the developer they hire also has to live with the code. Here's how that plays out day to day.
Shipping my own tools forces practical decisions: performance budgets, accessible UI, and maintainable code. The same playbook goes into client work — so delivery is faster and safer.
What client work gets out of it
Client projects get the benefit of patterns that have already been through production. When I build a form component for one of my own apps, the edge cases are already solved. Error states, validation feedback, accessibility — all of it has been stress-tested somewhere real before it reaches a client project.
That means faster delivery. No research phase on best practices. No trial-and-error with an unfamiliar library. I use what I already know works.
What my own products get out of it
Building products keeps me honest about technical debt. When you’re maintaining something for years rather than weeks, you make different architectural choices.
Clean code stops being academic when you’re the one debugging it at 2am. Performance matters when it’s your hosting bill. User experience matters when it’s your conversion rate.
Why this matters to you
The combination creates a feedback loop:
- Client constraints improve my product decisions
- Product learnings speed up client delivery
- Both sides run on the same shared infrastructure
It isn’t really about code reuse. It’s about developing judgment through ownership.
When your own success depends on long-term maintainability, you build differently. When a client deadline forces a practical decision, you avoid over-engineering.
That’s the advantage of hiring the person who also has to keep the code running.