The Operator Problem


## The Big Idea

At some point, a successful prototype changes jobs. It stops being a fast way to prove an idea, and starts becoming the thing your business depends on.

## What happens when your prototype becomes a product?

There is endless writing on the internet about building v0. Ship the MVP. Get something into people's hands. Find your first customers. Move fast enough to learn something before you run out of time, money, or emotional fortitude.

I love that part of the work. I will probably spend the rest of my life building little v0s, because there are few feelings better than turning an idea into something real enough for someone else to touch.

But there is a quiet threshold you cross if the product starts to work.

One day, the scrappy prototype is no longer just a prototype. It is how people do their jobs. It is how your team answers questions. It is how customers get what they paid for. It is where the rules of the business live, even the rules no one remembers writing down.

That is the moment you stop being only a builder. You become an operator.

This is the first post in [a series about that shift](https://mikebifulco.com/newsletter/operator-problem-after-mvp): what changes when your relationship with a tool, product, service, or SDK moves from “hello world” to “what do I need to know to keep the lights on?”

## v0 Did Its Job

Our first internal product at [Craftwork](https://www.craftwork.com) was built with Ruby on Rails, in a far off time before Claude Code existed.

Rails was good enough to get started with, and for a little while, it made velocity feel great. We could see a problem in the morning, scaffold something to address it in the afternoon, and have someone using it soon after. That kind of speed matters early on, because the job of v0 is not to build the perfect system. The job of v0 is to learn which system deserves to exist.

But I do think Rails was fundamentally the wrong choice for what we needed to become.

The scaffolding that helped us move quickly started making the product harder to shape. We found ourselves anchored in snap-decisions that were difficult to unwind. Performance became painful in the places where speed mattered most.

Hiring for Rails was harder than we wanted it to be.

And, maybe most frustratingly, it made it harder for us to take advantage of some of the best libraries on the web for building modern interfaces, especially tools like shadcnui that fit much more naturally into a TypeScript and React world.

All of this does not make Craftwork's initial software architecture a failure. It got us far enough down the driveway to discover what the real road looked like.

But once the product started to matter, the thing that got us started was no longer the thing that could help us scale.

It was time to rebuild.

## Rebuilding Without Disappearing

Rebuilding is an exciting, daunting, and scary prospect.

The work is hard. It is technical. It is full of tradeoffs. It requires patience, taste, discipline, and a willingness to live in an awkward in-between state for much longer than you want.

Here's the thing: your customers don't care that your rewrite is hard, or time consuming, or complex. They also don't need to.

"Bear with us, this is complicated" isn't a product strategy. People don't experience your architecture. They experience whether the product helps them do the thing they came to do.

It's tempting to hit `File + N`, and start from a blank slate. But that is a luxury we couldn't afford once our team and our customers were depending on the product to keep the business running.

So a big, dramatic cutover was a fantasy. We couldn't disappear into a cave, rebuild the whole product, and return with a perfect v1 while the business politely waited for us to finish.

The business was already running. People were already depending on the system. The old product could not simply be thrown away because it was inconvenient to maintain.

So we had to strangle it.

## What is the Strangler Fig Pattern?

The [Strangler Fig Pattern](https://en.wikipedia.org/wiki/Strangler_fig_pattern) is a way to replace an old system without rewriting the whole thing at once.

Instead of disappearing into a long, risky rebuild, you route one piece of behavior at a time through the new system. One workflow. One screen. One service boundary. One painful process.

The old system keeps running while the new one grows around it. Eventually, the new system handles enough responsibility that the old system can safely go away.

It's far less exciting than a clean-sheet rewrite.

However, it gave us more chances to get things right, and smaller consequences when we needed to change direction. Our team has been shipping improvements in smaller pieces, learning from them, and keeping the business moving while rebuilding the core of what the business depends on.

This _also_ means supporting the old system, and Keeping the Lights On™️ while the new system quietly takes over. The team building your product pays the tax of keeping both systems on, but also becomes more familiar with the old and the new as a result.

The Strangler Fig pattern allows everyone to do their job.

That's not just an engineering strategy. It's a product growth strategy.

## The Operator's Lesson

The most useful part of this process was treating the rebuild like product work instead of engineering housekeeping.

We watched where people struggled. We listened to what they complained about, but also what they were quietly telling us underneath the complaint. People are not always precise reporters of their own pain. Someone might say a workflow takes [too many clicks](https://mikebifulco.com/newsletter/stop-counting-clicks) when what they really mean is, “This workflow isn't working for me.”

Often times we'd discover behavioral patterns that started as a cheeky workaround and quickly became an invisible part of the system - a required step for getting things done. Peers using our tools would have no idea that the workaround was a workaround, because it had become a ritual. It was the only way to get the job done.

That is the operator's trap: the longer a broken workflow exists, the more people build little rituals around surviving it. If you only see the words of a feature request literally, you may rebuild the ritual instead of solving the problem.

## Rebuilding without the ritual

So, what do you do when the old system is broken, but people have built rituals around it?

You prototype, as cheaply as possible. We watched replays, interviewed people about their workflows, and put rough mockups in front of the team, asking them to show us how they would do their work. When something was confusing, we changed it. When something seemed obvious to us and useless to them, we changed it.

We also made [short video demos](https://mikebifulco.com/newsletter/reverse-devrel-as-core-engineering-skill) as we shipped updates. Not polished launch videos, just simple walkthroughs that said, “Here is what is changing. Here is how this works. Here is what we think this will make easier.”

That made the future less abstract. It gave people a chance to test changes and respond quickly, and it made feedback feel invited rather than tolerated.

The lesson I am taking from this is simple, but it took me a long time to learn:

**The goal of v0 is to learn fast enough to earn the right to build v1.**

Once you get there, the job changes. You are no longer proving that something can exist. You are responsible for helping it mature without breaking the business it now supports.

A good product is not a monument. It is a garden. You prune it. You graft new branches onto old roots. You remove what no longer belongs. You let the healthy parts keep growing while you carefully make room for what comes next.

That is the real work of being an operator: keeping the thing useful after it starts to matter.

---

## Some related reading

- [The Messy Middle](https://www.themessymiddle.com/) is a book by Scott Belsky about the challenges of growing a business after the initial idea has been proven.
- Microsoft has a great writeup on embracing [The Strangler Fig Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig)
- For a bit of _actual_ nature and the origins of the metaphor, check out this 5-minute explainer from ABC Science on the [Strangler Fig Tree](https://www.youtube.com/watch?v=B4XoYONdtb4).


The Strangler Fig Pattern: Rebuild Everything, without losing your mind

What happens when your prototype becomes a product?


## The Big Idea

Every tutorial teaches you how to get started. Almost none of them teach you what to do after the MVP, once your company depends on the thing you built. That gap is what I've been calling The Operator Problem - and if you're running into it, congratulations. It usually means you did something right.

Last time, I wrote about [rebuilding Craftwork's first product without stopping the business](https://mikebifulco.com/newsletter/stangler-fig-pattern). This is the problem hiding underneath that story.

## When our Twilio integration quietly broke

When we first set up texting at [Craftwork](https://craftwork.com), we did everything by the book. We followed Twilio's docs to the letter: create the account, install the SDK, send a test message.

A few seconds later, an engineer's phone buzzed. _Hello, World!_

If you've built software, you know that feeling - the little jolt of joy you feel the first time something you cobbled together actually works.

Today, our Twilio integration is one of the most important things we've built. Every call and text with a customer flows through our own internal tools, so anyone on our team can open a project and see the whole conversation, whether it started as a phone call, a text, or an email. When a homeowner texts Craftwork at 7am to say their door codes have changed, that message needs to land in front of the right person, right away.

For a long time, it did. Then one day, one of our most important customer service teammates suddenly couldn't send messages.

Not to one customer - to anyone. Texts he wrote went nowhere, while everyone else on the team kept texting customers like nothing was wrong. There was no outage, and no obvious culprit. Outbound messages from one person simply started failing.

The cause turned out to be success. That teammate was the heaviest user of our entire account - the person who talked to more customers than anyone else at Craftwork. And [Twilio Conversations](https://www.twilio.com/docs/conversations/conversations-limits), it turns out, caps any individual user at 1,000 conversations. Once you hit that ceiling, nothing new goes out until you close old conversations or remove the user from them to make room.

We didn't know the limit existed. It was documented, technically, but it took real digging to find - and nothing about the failure mode pointed us toward it. From where we sat, a critical person on our team had gone quiet, and we had no idea why. (If you landed here searching for it: Twilio's name for this one is error 50214, "User conversation limit exceeded.")

The getting-started docs we'd followed so carefully on day one were still excellent at explaining how to send a message. They had very little to say about what happens when your best people send _too many_.

(This isn't a knock on Twilio, by the way. We've had some version of this experience with nearly every service we depend on. Twilio just happens to be the one I have the best story about.)

## Day 100: the questions change after launch

Here's what nobody tells you as a founder: **the questions you ask change after the first hundred days.**

On day one, you're asking whether the thing works. On day 100 - after thousands of conversations, projects, and customers have passed through it - you're not looking for "getting started" docs anymore. Your team has leveled up.

Why is this failing for one teammate, but nobody else? How would we even know if messages stopped going out? Who on the team understands this well enough to fix it at 7am on a Saturday? And what happens six months from now, when someone asks why it works this way and the person who built it has moved on?

There's very little _day-100_ documentation in the world, and there's a reason for that. Getting-started guides are easy to write and satisfying to read: install the package, copy the code, see the success message. Operator knowledge is the opposite. It's specific to your company, tangled up in years of decisions, and mostly learned the hard way. It's also nearly impossible to market.

Nobody writes articles about the outage that didn't happen.

Most tutorials help you create a dependency. Very few help you live with one.

## Builder mode vs. operator mode

Builder mode asks:

> Can we make this work?

Operator mode asks:

> How do we keep this working?

Nearly all the startup advice you'll ever read is about the first question: validate the idea, [ship the MVP](https://mikebifulco.com/newsletter/your-mvp-is-too-damn-big), find your first customers. That makes sense - most startups never get far enough to worry about the second one.

But the two questions reward very different instincts. When you're still finding out whether an idea works, hardcoding a value or handling an edge case by hand isn't sloppy - it's good judgment. There's no sense building something sturdy until you know it should exist. Operating is different. An operator needs to know what happened, who it happened to, whether it's still happening, and how to keep it from happening again. The happy path becomes table stakes. The real job is understanding all the other paths.

## The moment you become an operator

The strangest part of becoming an operator is that it doesn't feel like a moment at all. You don't wake up one day and say, "I am now an operator." You just notice that the questions you ask have changed.

Nothing changes in the code when an experiment becomes a workflow, or when that workflow becomes something the business can't run without. What changes is what happens when it breaks. A scrappy prototype is perfectly reasonable when three people are kicking the tires. The very same code becomes dangerous once dozens of people need it to do their jobs.

It's easy to miss, because from the inside, success mostly looks like _more_: more customers, more data, more teammates, more integrations, more edge cases. Underneath all that _more_, the nature of the work has quietly changed - and the habits that got you here keep running on autopilot.

## A receipt for success

Here's where it gets counterintuitive.

The problems that keep operators up at night - the flaky integration, the failure nobody can explain, the system only one person understands - feel like evidence that you did something wrong. Sometimes they are. More often, they're evidence that you did something right.

Nobody hits a 1,000-conversation limit in their first month. You only run into that wall after your team has talked to an awful lot of customers. You don't worry about institutional memory until your systems have more history than any one person can hold in their head. A system can't become critical until it has succeeded at something first. Most startups never get to have these problems at all; they run out of money, customers, or momentum long before.

Operator problems aren't a punishment for building badly. They're a receipt for building something that survived.

## Signs your startup is in operator mode

You might be in operator mode if:

- a failure affects real customers or teammates, not just you
- fixing one thing breaks something that seems unrelated
- debugging requires knowing _why_ something was built the way it was
- the person who built a system is no longer the only one maintaining it
- a third-party API has quietly become a business dependency
- reliability work competes with feature work for the same people

The clearest signal is the simplest one: people rely on this now. Once that's true, the definition of "working" has changed - whether or not anyone announced it.

## What's next

You made it past the tutorial. Now you have to keep the lights on.

There's a twist, though. Startups don't flip from builder to operator all at once. One of your systems might be critical infrastructure while another is an experiment that may not survive the month - and they might share the same codebase, the same database, and the same engineers. Next, I'll dig into how to tell which mode each system actually needs.


The Operator Problem: What Startups Face After the MVP

When our Twilio integration quietly broke

Day 100: the questions change after launch

The Strangler Fig Pattern: Rebuild Everything, without losing your mind

The Operator Problem: What Startups Face After the MVP

💌 Tiny Improvements Newsletter