The tidy version of founding a company is that you raise some money, quit everything else, and pour yourself into one thing. The real version, for most people I know, is messier. You are building a startup while doing client work, funding the dream with the day job, and hoping the two do not pull you apart before the balance tips. That is exactly how we run Bluka, and after doing it for a while I want to write down what I have learned, because the honest account is more useful than the highlight reel.
Why we build on client revenue instead of raising
We took the client-funded route on purpose, not because we could not try to raise. Client work buys the one thing outside money cannot: the freedom to be wrong slowly. When your runway is a spreadsheet of invoices you control rather than a countdown to the next round, you can change your mind about the product without a board meeting, and you can say no to a bad-fit client because you are not desperate for the logo.
There is a quieter benefit too. Doing client work keeps us close to the exact problem we are trying to solve for founders. Every project brief that lands in our inbox is a live sample of what people struggle with when they try to get an app built, which is the same struggle our own product is meant to ease. You cannot buy that kind of market research. It walks in the door and pays you to learn from it. If you want the fuller picture of why founder-honest pricing matters here, we wrote about it in the £25k MVP myth.
The trade is obvious and I will not pretend otherwise. Client-funded means slower. The product gets the hours that are left over, and some weeks there are not many. Anyone building this way is choosing patience over speed, and it only works if you actually want the thing badly enough to build it in the margins.
The tension nobody warns you about
The hard part is not the workload, it is the context switching. A morning spent deep in a client’s problem, thinking in their domain, using their constraints, is a morning your brain is not in your own product. Switching back is not free. There is a real cost to picking up your own roadmap after eight hours of holding someone else’s, and on a bad week that cost is the whole evening you meant to spend building.
What makes it genuinely difficult is that client work is legible and the product is not. A client has a deadline, an invoice, a person who will be unhappy if you slip. Your own product has none of that. It has no one chasing it except you, which means it is always the thing that can wait, and if you are not careful it waits forever. The urgency gradient runs entirely the wrong way. The work that pays shouts, and the work that matters most to your future whispers.
I have watched this sink other founders, and I have felt it pull at us. The failure mode is not dramatic. You do not decide to abandon the product. You just keep choosing the urgent thing, week after week, each choice reasonable on its own, until a year has gone by and the product is exactly where it was. Building a startup while doing client work fails quietly, by a thousand sensible decisions to deal with the client first.
The rules that keep both alive
So we run a few rules, and they are boring on purpose, because boring is what survives a busy week. The first is that product time is booked like a client meeting, not left to whatever is spare. Spare time does not exist in a studio. If the product does not have a protected slot on the calendar with the same weight as a paid commitment, it gets nothing, so we give it one and defend it.
The second rule is that we do not take client work we would be embarrassed to show our own users. This sounds like a values statement and it is really a focus statement. Every project that is close to our own product makes us sharper at building it. Every project that is far away is just money, and money we could earn does not justify the context-switching tax if it teaches us nothing. We turn down work that would pay well and pull us off course, which is a harder discipline than it reads. Our note on how to write an app developer brief came directly out of the client work we did choose to take, which is the point.
The third rule is that we are honest with clients about who we are. We do not hide that we are a studio with its own product. Most clients like it, because it means the people building their app are the same people shipping something of their own and feeling every decision from the inside. A studio that only ever builds for others can drift into treating software as someone else’s problem. Keeping our own product in the mix stops us from ever being those people.
What I would tell a founder building a startup while doing client work
If you are about to build a startup while doing client work, I would tell you two things and neither is a warning. The first is that this is a legitimate way to start a company, not a lesser one. The stories that make it sound like everyone quit and raised are survivorship bias with good PR. Plenty of durable companies were funded by their founders doing paid work on the side, and there is no medal deducted for patience.
The second is that the discipline is the whole game. The client work will always try to expand to fill the time, because it has deadlines and people and money attached, and your product will always try to shrink, because it has none of those pressing on it. Your only job is to hold that line, week after week, and give the quiet work a fair share of your best hours rather than your leftover ones.
We are not done, and I am not writing this from the far side of some triumph. We are still in it, still balancing, still occasionally getting the balance wrong and correcting the following week. But building Bluka this way has made us a better studio and a more grounded product team, and I would choose it again. If you are weighing whether to build your own thing on the back of client work, or you want a partner who understands that balance because we live it, tell us what you are working on and we will give you an honest read.
.webp)
.webp)
