There's a category of advice-giver everyone quietly distrusts: the consultant who's never run the thing they consult on. The fitness coach you've never seen train. The business guru whose only business is the guru business.
Agencies live dangerously close to that category. We advise clients on products we hand over and walk away from, we design the ship, but the client sails it, and the sea teaches the sailor things the shipwright never learns.
So we built our own ship and put it in the water: a SaaS product, a proposal-generation tool for freelancers, that we don't just maintain but operate, with real users, real churn, and real 11pm decisions. This is what the sea taught us, and what it changed about how we build for clients.
Lesson 1: Users ignored our favorite feature (and the roadmap in our heads)
We launched with confident assumptions about which capability was the hook, the clever part, the part we'd have led every demo with.
Users shrugged at it. What they leaned on, hard, was a part we'd considered almost too obvious to mention. The usage data was unambiguous and slightly insulting.
Here's why this lesson was worth the bruise: we'd read this happens. Every product book says it. But reading "users will surprise you" and watching your own conviction get politely stepped over by real behavior are different educations, and only the second one transfers. Now, when a client is certain about their feature list, we recognize the certainty from inside. It's why the MVP mindset stopped being methodology we recommend and became something closer to a scar we show: launch small because your favorite assumption is probably the wrong one, and the only affordable time to learn which is early.
Lesson 2: Launch day is the beginning, not the finish line
As an agency, our old relationship with software had a natural climax: delivery. Ship it, hand it over, champagne.
Running our own product deleted that finish line. After launch came the actual product: onboarding confusion we hadn't predicted, edge cases from real usage, dependency updates, the platform change that broke a flow on a Tuesday, the support message that reveals your "intuitive" screen isn't. None of this is failure, it's what operating software is, permanently.
This rewired how we scope client work. We'd always told clients that software never stops needing care, but as sellers of a service, which is easy to discount as upselling. Now we say it as fellow operators with our own maintenance calendar and our own war stories, and we structure every handover for the life after launch, because we've personally lived in that after.
Lesson 3: Every screen is a support ticket you haven't received yet
When your own inbox catches the confusion, design philosophy gets ruthless fast. That slightly ambiguous button label? It's not a style choice, it's four support conversations a week. The onboarding step that assumes knowledge? That's churn with a timestamp.
Client-work designers are partly shielded from this feedback; the confusion lands in the client's inbox, months later, diluted into "users are finding it a bit tricky." Operating our own product connected the wire directly: design decision, human confusion, our evening. We design differently now, more boringly, in the best sense, because we've paid retail price for cleverness.
Lesson 4: The economics of software look different from the owner's chair
Running a product means personally feeling things we'd previously only modeled for clients: what per-user infrastructure costs do to pricing decisions, why a free tier needs a hard cap, how churn quietly outranks acquisition, why "just add this small feature" competes against support, maintenance, and sleep.
That felt knowledge now sits in our client consultations. When we push back on a pricing plan or a free-tier design, it's not theory, it's arithmetic we've done on our own money. There is no faster way to develop respect for a client's budget than burning some of your own.
Why this is on the blog instead of in a drawer
Partly, honestly, because it's proof, "we operate our own product" is a sentence most agencies can't say, and unlike portfolio claims, a live product with real users can't be faked.
But mostly because the lessons themselves are the service. Every client who reads this arrives at our discovery call already knowing why we'll ask about the problem before the features, insist on a small first version, and put maintenance in the first conversation instead of the last. The product made us better shipwrights precisely because it made us sailors, and clients get the benefit of both without paying for our bruises.
We did that part already.