Studios · Survival
Four months of runway. Start with the first fortnight.
Sixteen weeks is enough time to change the outcome, but only if the awkward decisions happen near the beginning rather than near the end.
If you are reading this at two in the morning, four months will not feel like much time.
It is sixteen weeks, so it is not nothing. A build can improve, a deal can move and a smaller game can become credible in sixteen weeks. The catch is that the decisions which preserve those options mostly happen in the first fortnight. Spending six weeks hoping the next publisher reply will solve everything is also a decision, just a rather expensive one.
I would split the work into two parts. First establish the truth, including the bits nobody enjoys putting in a deck. Then choose one main route and run it hard enough to learn whether it works.
Week one: find the real date
“Four months of runway” is normally a rounded answer to several different questions. I want the exact weekly cash position, payroll dates, tax, rent, software, hosting, contractor commitments and any receivables which are genuinely likely to arrive. I also want the cost and timing of an orderly wind-down. Cash reaching zero is not the date to begin discovering employment obligations.
There may be several useful dates:
- the last date at which the whole team can be paid normally;
- the date a smaller operating plan would have to begin;
- the point at which insolvency or director duties change what is possible; and
- the decision date which still leaves enough cash to act responsibly.
Get local legal and financial advice for the legal bits; they vary, and an article on a consultancy website is not the place to improvise them.
Alongside the cash model, establish the state of the project. Not the milestone description - the build. What runs, what is fun, what is missing, what is known production and what remains an unsolved design or technical problem? How long did the last three deliveries actually take?
This is a good week to call somebody experienced who is not financially or emotionally tied to the answer. Founders are asked to be optimistic for years and then, rather suddenly, to produce a brutally conservative forecast. That gear change is difficult.
I would also write down how the studio arrived here. A publisher withdrawal, schedule overrun, failed launch and high fixed cost lead to different plans. “We need more money” is true in all four cases and explains none of them.
Week two: choose the route
There are usually several theoretical options:
- ship a materially smaller version of the game;
- raise investment or sign a publishing deal;
- extend runway through contract or service work;
- reduce the team and fixed costs;
- add founder funding; or
- wind down in an orderly way.
The dangerous response is to pursue all of them at full volume. The leadership team spends its days in funding calls, the developers prepare multiple demos, contract proposals go out, scope stays unchanged and nobody is quite running the studio.
Choose a primary route, a fallback and the evidence which will distinguish them. For example: spend six weeks producing a small, stable slice for specific publisher conversations; if those conversations have not reached defined commercial steps by a fixed date, move to the smaller operating plan. The dates and definitions matter. “Interest” is not a stage in a funding process.
Weeks three and four: remove whole things
If the plan requires a smaller game, trim is rarely enough. Ten per cent from every feature leaves almost all of the integration, testing and management complexity. It also tends to create a thinner version of the same impossible schedule.
Remove complete modes, platforms, content families or system branches where the product allows it. Protect the smallest coherent experience which demonstrates why the game should exist. A shorter game which feels intentional is easier to explain than a larger one with half-finished edges everywhere.
This is where the build and the schedule need to be compared item by item. How much work is content production through a proven pipeline? How much depends on technology which is still unreliable? How much “polish” is actually first implementation? Put integration, bug fixing, certification and store work somewhere visible. They do not disappear when omitted from the plan.
If the runway plan involves contract work, apply the same honesty. Who sells it, who delivers it, and when does cash arrive? A signed piece of work which begins after the studio runs out of cash is not runway.
Tell the team when there is something definite to say
There is no perfect moment for this conversation. Too early, with no facts or plan, and leadership transfers its panic to everybody else. Too late, and people discover that decisions about their lives were being made while they were being reassured.
Once the cash position and route are real, I would explain:
- the situation and the date leadership is planning against;
- what caused it, without converting the meeting into a trial;
- what is changing now;
- what has not yet been decided; and
- when the next update will happen.
Specific uncertainty is easier to live with than confident vagueness. “We are waiting for a publisher” leaves everyone to invent a probability. “Two publishers have the build, both have meetings booked next week, and we will update you on Friday even if nothing changes” is information.
Weeks five to eight: make the small thing convincing
If funding or publishing is the chosen route, the job is not to make a broader pitch. It is to remove the reason somebody cannot yet say yes.
Often that means a smaller, better build. The first two minutes matter: startup, menus, load time, controller behaviour and the opening play. A reviewer should not need a developer standing beside them explaining which hitches are known. The slice must run well on the machine it is being shown on and make the central promise of the game legible quickly.
If publishers have gone quiet, ask what remains unresolved. Is the audience unclear? Is the scope unbelievable? Does the team appear unable to deliver the technology? Is the commercial request too large for the evidence? A generic “just checking in” email does not change any of those things. A build or plan which answers the concern might.
Do not manufacture urgency so aggressively that it reveals there are no alternatives. A weak position is already difficult enough without announcing desperation and then negotiating terms.
Weeks nine to sixteen: keep the decision date intact
By this point optimism tends to return in tiny administrative forms. A meeting moves by ten days. A potential investor asks for more information. Somebody says the deal is “looking positive”. The final decision date begins to slide because nothing has quite failed.
Keep a weekly view of cash and update the probability of each route with evidence, not mood. Protect the key people needed for the chosen plan, and be honest about the effect of departures. If the route no longer works after two specialists leave, the plan has changed even if the spreadsheet has not.
Set the last responsible date at the beginning and treat moving it as a board-level decision. If a transaction is genuinely close, the evidence will be visible: diligence underway, terms being negotiated, approvals scheduled. Another friendly call is not the same thing.
The final option may still be an orderly closure. That is painful, but it is not made kinder by arriving after payroll fails. Preserving enough cash to meet obligations, support people and leave the IP in a usable state is real management work.
A studio in this position is not uniquely foolish. Games are uncertain, deals move and schedules expose every optimistic assumption eventually. The useful distinction is whether leadership reacts while several choices remain.
Four months can be enough. I would be much more confident saying that in week one than in week twelve.
A short advisory session can help frame the decision. If the answer depends on the state of the build, schedule and pipeline, that is better handled as a performance review.