Lessons from Shipping Multiple Products as a Small, Fast-Moving Studio
Haven Command has shipped across a genuinely wide spread of products — an AI chess trainer, an AI therapy-documentation tool for clinicians, a multiplayer survival game, a retro-console hosting platform, and now Xibrary, sourcing infrastructure for AI agents. A few honest lessons from doing that instead of picking one thing and staying in a lane.
Finishing is the actual hard skill
Starting a project is easy and fun. Finishing one — getting it to a state where a real person can use it without you standing behind them explaining the rough edges — is the skill that actually compounds. Every Haven Command product that shipped taught us something the unfinished ones couldn't, because finished software gets used, and use is the only feedback that's honest.
Different domains cross-pollinate more than you'd expect
Building a chess trainer and building a therapy notes app have almost nothing in common on the surface. But the discipline of "structure the domain correctly before you write the feature" turned out to transfer directly. That same discipline is what let us design Xibrary's data model — parts, suppliers, listings, compliance records — cleanly on the first real pass, instead of iterating through several wrong shapes first. Game development in particular sharpened this more than anything else we've built; we wrote about that specific connection in what game design teaches you about designing for AI agents.
Small teams win by using leverage, not by working more hours
The honest reason a small studio can ship across this many surfaces isn't heroic effort, it's leverage — specifically, treating agentic AI coding tools as core infrastructure rather than a novelty. We wrote in detail about what that actually looks like day to day in how we use AI to build faster. The honest version of that post is the honest version of this one too: the leverage doesn't replace judgment, it just means the judgment gets applied to more decisions per day instead of getting consumed by typing.
Knowing when a new product is actually a new product
Xibrary didn't start as a plan. It started as a recurring, specific frustration — AI agents building things for us kept hitting the same wall sourcing real parts — that kept showing up across unrelated work until it was clearly its own problem, not a feature request for something else. That's usually the actual signal that something deserves to be its own product: not a good idea in the abstract, but a wall you keep hitting in practice, repeatedly, across contexts that otherwise have nothing to do with each other.
What's next
We're not done — Xibrary is early, and there's a lot of the roadmap still ahead of it. We wrote about where we think it's headed in what we're building next.