What an MBA Changed About Shipping Software

For most of my career, "better software" meant cleaner code, faster pages, fewer bugs. Those still matter. But an MBA reframed a question I'd been answering badly for years: not how to build it, but whether to build it at all — and what building this instead of that actually costs.

That's what genuinely changed in my work.

I started pricing what I wasn't building

Every feature you build is a feature you chose instead of something else. An engineer feels this as a backlog; business school gives it a name: opportunity cost. The most expensive line of code is the one that does something ordinary well enough, while something more valuable sits on the ground.

Now, before building, I ask what else that week could have bought. Often the honest answer kills the feature. That's a win, not a loss — software that's never built has no maintenance cost, no bugs, no confusion.

A real example: in redesigning a marketplace platform with 400+ vendors, the temptation was to redesign everything at once. But research showed the real problem was one specific thing: a seven-step checkout with no guest option. Focusing on that single point — instead of spreading effort across ten smaller fixes — is exactly that "pricing what we're not building" in practice.

"Working" and "profitable" aren't the same thing

I used to judge a feature by whether it worked. Now I look at unit economics: what does running this cost per user, and what does it return? A feature that's technically beautiful and quietly loses money on every request is debt wearing a nice suit.

This changes architecture decisions too. Choosing "scalable" isn't about handling a million users you don't have — it's about making sure your cost curve tracks your actual revenue curve. On the IP Check project, a naive daily-polling approach generated roughly 170,000 requests per user — enough to get the check service itself rate-limited or banned. Switching to event-driven detection did the same job at real cost instead of assumed cost.

Deciding not to is the work itself

The strongest signal of an experienced operator — engineer or founder — is the quality of what they turn down. Saying yes is easy and feels productive. Saying no, with a reason, is the actual work of strategy.

I now see the roadmap as a list of bets, not a list of promises. Every item carries a cost, an expected return, and a confidence level. Most don't survive that framing, and the few that do deserve far more attention than they usually get.

Talking with the business, not for it

The most underrated MBA skill is translation: turning "we need to rewrite the auth layer" into "this reduces a definite risk that costs X and stops shipping." Same work, but now whoever holds the budget can actually weigh it. Engineering that can't justify itself in the language of the business gets set aside — not because it's wrong, but because it's illegible.

The synthesis

Good engineering and good business judgment aren't opposites; they're two halves of building something that lasts. Code quality keeps you alive at scale. Business judgment makes sure reaching scale was worth it. The best work I do now sits exactly where the two meet.

Frequently asked questions

Do engineers actually need an MBA? No. But the literacy it gives you — opportunity cost, unit economics, and the decision not to build — is genuinely useful, and most of it is learnable without the degree. The degree just made the practice mandatory.

What was the biggest mental shift? Pricing what I wasn't building. Every feature is chosen over some other option; once you honestly price that other option, a lot of "obvious" features quietly fall off the roadmap.

How do I justify technical work to non-technical stakeholders? Translate it into the language of risk, cost, and revenue. "Rewrite the auth layer" becomes "this reduces a definite risk that costs X and stops shipping." Same work — now whoever holds the budget can actually weigh it.

---

That intersection is the whole idea behind how I work — see my services or the about page for the longer story. Building something that needs both the engineering and the business case to be right? Let's talk.