The engineering was the part I was ready for. Contracts, cash flow timing, handover documents, and knowing which work to refuse were not, and those are what actually determine whether a studio survives.
Going from freelancing to running Reivex as a studio was not primarily a technical transition. The code got easier over time. What got harder was everything sitting around the code, and almost none of it was covered by the years I had spent getting good at building software.
The Work Behind The Work
As a freelancer your operational surface is small. Find a client, do the work, send an invoice. When something goes wrong you absorb it personally and move on. The overhead is real but it fits in the gaps between building things.
A studio does not fit in the gaps. There are engagements running in parallel at different stages. There are people whose income depends on decisions you make about which work to take. There are commitments made months ago that have to be honoured whether or not the estimate was good. The overhead becomes a job, and if you keep treating it as something to squeeze between features, it degrades in ways you notice only when it fails.
What I underestimated most was context switching. Four active engagements is not four times one engagement. Every switch costs reload time, and reload time on a complex codebase is not five minutes. Some weeks the honest accounting is that a meaningful share of the day went to remembering where you were.
Contracts Are A Design Document
I used to think of contracts as legal overhead, a formality to clear before the real work. That was wrong in a way that cost me.
A good contract is a specification for the relationship. It answers the questions that otherwise get answered under pressure, badly, by whoever is more stubborn. What happens if the client goes quiet for three weeks and then wants to resume. Who owns the code if the engagement ends early. Whether unused hours roll over. What counts as a bug versus a change. Whether you can reference the work publicly.
Every one of those has a natural answer that both parties would agree to calmly in advance and would argue about bitterly in the moment. Writing them down is not distrust. It is the same instinct as writing tests, applied to a relationship instead of a function.
The clause I care most about is publicity. A studio that cannot show its work has no marketing. I now ask at signing whether the project can be referenced, and if the answer is no, I ask whether an anonymised case study is acceptable. Asking eighteen months later, after the relationship has cooled, gets a much worse answer than asking on day one when everyone is enthusiastic.
Cash Flow Is Not Revenue
This is the lesson that catches nearly everyone, and knowing it intellectually does not prevent it.
A signed engagement is not money. An invoice is not money. Money is money, and the gap between those three states is where studios quietly die. You can be fully booked, profitable on paper, and unable to make payroll, because profit is an accounting concept and payroll is a date.
What actually helped:
- Deposits before work starts. Not a negotiation. A client unwilling to commit anything before you begin is telling you something about how the rest of the engagement will go.
- Milestone billing rather than completion billing. Invoicing at the end means carrying the entire cost of the project yourself, which is a loan you are extending without interest or paperwork.
- Payment terms that are actually enforced. Terms nobody follows up on are not terms, they are suggestions. The follow up is uncomfortable exactly once and then becomes routine.
- A buffer sized in months, not weeks. Client work is lumpy. A quiet month is normal rather than a crisis, but only if the buffer exists.
I am deliberately not quoting numbers here, because the right figures depend entirely on your costs and market. The principle transfers regardless of scale: model the dates money arrives, not the total it adds up to.
Handover Is A Deliverable
The clearest signal that a studio has matured is what it hands over at the end.
Early on my handover was the repository and a conversation. That is not a handover. That is an invitation to call me at an inconvenient time in six months, and I had no right to be annoyed when it happened, because I had given the client no other option.
What ships now with every engagement:
- A README that gets a new developer running locally without asking anyone anything.
- An architecture note covering the decisions that would otherwise look arbitrary, and why they were made.
- Environment and deployment documentation, including how to roll back.
- An access inventory: every service, who owns the account, how to rotate credentials.
- A short list of known weak points and what I would do about them next.
That last item is the one clients remember. Volunteering the parts you are not proud of reads as confidence rather than weakness, and it is far better for them to hear it from you than to discover it from the next engineer, who will have no reason to be generous about it.
Saying No Is An Operational Skill
The hardest thing to learn, and the one with the largest effect on whether the business is pleasant to run.
Early on I took nearly everything. Work was uncertain, so declining felt reckless. The result was a portfolio containing several engagements that consumed disproportionate attention, generated disproportionate stress, and in a couple of cases were net negative once the true time was counted.
The patterns worth declining are recognisable in the first conversation:
- Nobody can articulate what success looks like, and the vagueness is treated as flexibility rather than as a problem to solve.
- The budget and the scope are not in the same universe, and the client's plan for closing the gap is your goodwill.
- There is no single decision maker, and the people in the room disagree with each other while you are watching.
- The previous vendor is described as incompetent with no reflection on what the client might have contributed. You are next in that narrative.
None of these are moral judgements. They are risk assessments. A project that is a poor fit will not become a good fit because you need the work, and taking it means the well fitting engagement that arrives next month competes with a commitment you should not have made.
What I Would Tell Someone Starting
Treat the operational layer as a system you are building, with the same seriousness you would give a production service. Write the contract properly. Bill in milestones. Document handover as though you plan to disappear. Track cash by date rather than by total. Decline the engagements that are wrong even when declining feels expensive.
None of it is the reason anyone becomes an engineer. All of it is the reason a studio is still standing in year three, and the engineering you actually want to do only exists on top of it.
Comments
Sign in to leave a comment.