F2F #85: Build vs. fix

... or the trade-off every founder gets wrong.

Twelve years running MarsBased have taught me many things, but few lessons have been as poignant as this one: it is extremely hard to know when to build vs. when to fix.

Most founders are born to build. We start companies and projects because we want to create things, solve problems, help people, improve the world and, hopefully, make money as well. The CEOs, especially, are usually driven by the new shiny things, ripe low-hanging fruit and all that jazz.

Shipping new features, products and business lines is what gets us out of bed. Fixing is not that exciting and we do it reluctantly because it usually involves closing down projects, shutting down creative efforts, stopping collaborations and, generally speaking, shutting doors.

Well, you can't have one without the other. If you don't build enough, there's nothing to fix, but if you don't fix anything, you'll run out of resources to keep building, and that kills companies slowly, with an accumulating weight that compounds until the organisation stops being able to move.

This is a reflection about when to build and when to fix, and more specifically, about why the answer changes as you scale, and why founders are usually the last ones to notice.

That includes me.

The build bias is structural

It is not a character flaw. It is a feature that becomes a bug.

In the early days of startups, building is the right default. Move fast & break things, ask for forgiveness not for permission, and all that crap. You have next to nothing, so anything you ship is net positive. Speed matters more than quality if you're running on someone else's money, so you have to try to find the thing that sticks before you run out of money. Technical debt is therefore an acceptable trade-off when your company's demise is right around the corner.

The problem is that founders carry this operating mode into stages where it no longer fits. What worked with the founding team usually doesn't translate well into a team of 50. You keep shipping and you keep winning time and money, so you're incentivised to keep creating, postponing the moment to sit down and fix stuff indefinitely.

Your team won't tell you to stop because they're also not incentivised to do it. Who are they to question the founder, you'd think. The company just starts to feel harder to steer every quarter, hire after hire.

What "too much building" actually looks like

AI has actually worsened this. I've written extensively about the systemic problems of being able to do more with AI, and pushing the boundaries of what's possible further down the validation funnel. Read More AI, More Problems or Breadth vs depth.

Too much building looks like a roadmap that is always full, a Claude Code with 10+ concurrent sessions and many - way too many - intertwined and interconnected projects with several dependencies each, which will eventually make it to 80% of completion but never 100%. It looks like sprints that deliver features while the support queue quietly grows. It looks like a codebase that newer team members struggle to onboard into, but that everyone is too busy to document. It looks like an ever-growing backlog of tasks with more tasks going into it than out of it.

The signal that you have been building too much is almost never a single catastrophic event but a slow accumulation of friction: slower deployments, more bugs in production, more time spent coordinating and less time actually building, and the ever-growing feeling of being too busy to take a day off to watch things with perspective, question and fix broken stuff.

By the time it becomes visible, the debt has been compounding for months.

When to change as you scale

If I had to write a framework or a book about this, I'd probably estimate that in early stage (say, up to 15-20 people), the right ratio is probably eighty/twenty in favour of building. 90-10 in the lower end of the team size spectrum, 80-20 later on. But there should always be some time dedicated to fix something broken lest you discover too late that you can't do it.

Upwards from 20, that ratio should start to move, either in percentage or in responsible people. You are now onboarding people who did not build the original system, and these people will onboard other people in turn. Your codebase has accrued real decisions that are starting to constrain new ones. Most people in your team won't have been long enough in the company to have soaked up the culture or the processes, nor have the context to make the best decisions.

Around this stage, a 60-40 split starts to make more sense. One in three sprints, or one week in four, deliberately allocated to fixing, refactoring, and paying down debt. Code freeze for a few weeks every quarter and fix broken parts of the system, run more tests, upgrade libraries, clean up messy code, document, etc. Not only in the code, but you should do this company-wide as well.

I don't know if it ever makes more sense to have a split favouring fixing unless you fucked up real bad. Even a 50-50 split looks like a bad decision to me because, effectively speaking, you'd be moving forward 50% slower, and none of your competitors will do that.

The signals that tell you it is time to stop building

However, you have to draw the line somewhere. Company debt is like back pain: if it hurts, you change to a less painful posture and adapt. Instead of fixing it, you're getting used to a new kind of pain, and this is how you fuck up your back (I've got plenty experience in this) and your company (and that's why I'm not allowing it to happen here).

There are certain clear signals of approaching fix time: decisions get postponed indefinitely, teams deliver less, more bugs, costs surging, waiting times growing fast, patching stuff just to kick the can down the road, etc.

If that sounds too familiar, it's fixing time!

Fix vs. build at MarsBased

You were probably wondering what has been our fuckup here. You probably expected to read that we postponed fixing too much and something broke badly, and you'd be wrong.

We have the other problem: when we fix stuff, and we do it pretty often, we get too heads down and forget to build again. At MarsBased, we have a non-structure fix cycle every quarter, and we do audit everything in the company every three-four months, so we don't hoard too much.

I have spent an entire quarter fixing SEO, content and other internal things in the company that not all of them were urgent nor important, but I got so much into the zone - or the flow - that it took me a long time to go back into building mode.

Maybe that's just me, but I can't juggle between doing building and fixing in the same day nor in the same week. I have to do cycles and they have to be long enough for me to satisfy certain parts of my brain before moving to the opposite side.

The signals that tell you it is time to stop fixing

This is the less obvious half of the equation. Some teams, and some founders, overcorrect. They declare a "technical debt quarter" and disappear into refactoring. They forget to keep pushing forward, so when they're done fixing, it takes them ten times more to restart the building machine.

If you have a company, you can spend the day building, and we all know that, but past a certain stage, you could also spend the whole day fixing. Both things are valid but they'll take you to different places.

If by the end of the fix cycle you haven't substantially improved a few KPIs in the company, you haven't fixed enough. For instance, in our last cycle, we rebuilt the MarsBased website to reduce dependency from developers to 0. Now, our marketing guy and myself can change anything we want in the website because we got rid of a very strict CMS we used to have. We go from idea to production in minutes, when it used to be weeks.

Parting words

You probably cannot make this call from taking a look at your Linear/Jira board. You have to be close enough to the team to feel where the friction is, do the processes yourself, and be honest enough with yourself to admit that some of that friction was built by decisions you made under pressure (and they were right at the time - this is essential).

The founders I have seen handle this well share one habit: they ask their most senior engineers what is slowing them down. Then, they build the habit of alternating between build and fix regularly to ensure the engine keeps running.

I think it comes down to discipline: not a framework, not a ratio, not a rule, not a gospel from above. The discipline of consistently making space to fix the things that your building created before they become the things that stop you from building at all.