Most software studios build exclusively for clients. It is a clean business: scope, build, deliver, invoice, move on.
We do that, and we also build and operate our own products. That is unusual enough that clients ask about it, usually with a reasonable underlying question — does this mean my project competes for attention?
Fair question. Here is the honest answer, including the tradeoff.
What you learn only by living with it
A studio that ships and moves on learns a great deal about building software and almost nothing about owning it.
The lessons that change how you design things arrive in year two. The clever abstraction that turned out to be a maintenance burden. The infrastructure choice that was cheap at launch and expensive at scale. The admin panel you underbuilt and now your team fights daily. The dependency that stopped being maintained.
When you hand a project off at launch, none of that reaches you. The client absorbs it, and if they mention it at all it is a year later when you have already made the same decision on three other projects.
Running our own products means we eat it. Hookah Royale has real players on real networks at 11pm. When the reconnect logic is wrong, we find out. That knowledge goes straight into what we build for clients — not as theory but as scar tissue.
What it lets us say no to
The more useful effect is on what we are willing to tell clients.
A studio whose entire revenue is billable hours has a structural incentive to agree that you need the thing you asked for. Nobody sets out to be that studio. It just happens, gradually, when saying "you don't need this" costs you money every time.
Operating our own products gives us a second thing to be busy with, which makes it much easier to tell a client that their scope is too large, that they should buy instead of build, or that the right move is a landing page and forty phone calls rather than a twelve-week build. We give that advice regularly. It costs us work and it is the most valuable thing we do.
The tradeoff, stated plainly
The real cost is attention. A studio splitting focus between client work and its own products can do both badly — and clients are right to worry about it.
The way we handle it is boring: client work has committed timelines and named people, and internal products get the remainder. When those conflict, client commitments win, because a missed client deadline damages a relationship and a slipped internal feature damages a roadmap only we can see.
That is a choice we have to keep making rather than one we made once. We would rather say that than claim there is no tension.
What it means for a client project
Practically, three things:
We have opinions and we will share them. You are hiring people who have made these decisions with their own money on the line, which produces stronger and occasionally less comfortable opinions than a team optimizing for scope agreement.
We think about year two. Maintenance cost, operational burden, and what happens when the person who built it is gone are part of the design conversation, not an afterthought — because we live in year two on our own products.
We will sometimes tell you not to build. Including when it costs us the project.
The portfolio in practice
We have built across the range: real-time consumer gaming, internal operations software, marketplace and exchange mechanics, and nonprofit technology on nonprofit budgets. Some of that work is ours and some belongs to clients, and the useful part is that the lessons move between them.
The client project that benefits most from Hookah Royale is not another card game. It is the next product where someone's connection drops at the worst moment, and we already know what that costs to get wrong.
If you want to work with a studio that will argue with your scope, tell us what you're trying to build.