What Client Work Teaches Me That My Own Products Never Could
Building my own products, I set the deadlines, pick the requirements, and keep the code forever. Client work takes all three away. That's exactly why it makes my own products better.
XenneX does two kinds of work: our own products, and software for clients. People sometimes assume the client side is just what pays for the product side. It does help with that. But the bigger thing it does is teach me lessons my own products never would, because when I'm the only stakeholder, I get to skip all the hard parts.
Deadlines I Didn't Choose
On my own products, a deadline is a suggestion. If a feature takes longer than I thought, I move the date, and the only person disappointed is me.
Client work doesn't allow that. A launch is tied to an event, a funding round, a season, a board meeting. The date is real, and somebody else is counting on it. That pressure forces a skill that's easy to avoid on your own projects: deciding early what actually has to ship and what can wait, and then holding that line.
I've brought that habit back to my own products. I still set my own dates, but I treat them more seriously than I used to, and I scope down earlier instead of letting a release drift.
Requirements I Wouldn't Have Picked
When I build for myself, I build for my own taste. That's part of the fun, but it's also a blind spot. I'll skip a feature because I don't need it, without asking whether my users do.
Clients bring requirements I'd never have come up with: industry rules, odd workflows, integrations with systems I've never heard of, users who work completely differently from me. Building those well means taking someone else's problem seriously even when my first instinct is that it shouldn't work that way.
That's made me a better listener on my own products. When a support email asks for something that seems strange, I'm a lot quicker now to assume there's a real reason behind it.
Handing the Code Off
Everything I build for a client eventually belongs to someone else. Another developer might maintain it, or extend it years from now without me around to explain anything. That changes how you write. No clever shortcuts only I understand. No undocumented setup steps. No "I'll remember why I did this."
My own products used to get away with all of that, because I was always going to be the one maintaining them. Writing for a handoff made me realize how much my own codebases depended on my memory. These days I try to write my own code as if I'm handing it to a stranger, because a year from now, I basically am.
Accountability That Isn't Mine to Set
On my own products, "good enough" is whatever I decide it is. With a client, it's measured against what they needed and what we agreed to. That's a useful outside standard, and it's humbling in a good way. It's very easy to grade your own work on a curve when nobody else is checking.
Why I'd Keep Both
I could focus only on my own products, and some weeks that's tempting. But the client side keeps me honest in ways my own projects can't: real deadlines, real requirements, real handoffs, and a standard set by someone else. Every one of those has made the products I build for myself better.