The Business Problem Matters More Than the Framework

A framework is not the product. It's the way you deliver whatever actually moves a business metric, revenue, retention, time saved, risk removed. I've shipped code in languages and frameworks that don't even matter to this story, because the framework was never the thing that decided whether any of these businesses worked. The business problem was. I learned that the expensive way, three separate times.

The best-engineered product with zero customers is not a business

It's tempting to measure a project by how well it's built: clean architecture, good test coverage, a well-oiled machine under the hood. None of that is worth anything if nobody is paying for it. A beautifully engineered product with zero customers isn't a business with an engineering advantage, it's a hobby with a changelog. And it isn't engineering job security either, because there is no engineering job to secure if there's no revenue funding it.

That's the part a lot of engineers, myself included for a long time, don't want to internalize: engineering is a business-first job. Not because code quality doesn't matter, it does, but because code quality is in service of something. If nothing is coming in the door, the quality of the code behind the door is irrelevant to whether the door stays open.

Kalast, Inc.: a mission statement, not a market

About fourteen years ago, I started a company called Kalast, Inc. The pitch, if you can call it that, was to "help small businesses grow." I want you to notice how that sentence contains zero information about who, what problem, or why anyone would pay for it. It wasn't a business idea, it was a feeling wearing a business idea's clothes.

I did what a lot of engineers do when they're excited: I started building before I understood who the customer was or what specific, painful problem I was solving for them. The machine I built was fine. The market research behind it was nonexistent. Guess where that landed? Nowhere. Not because the code was bad, but because "help small businesses grow" isn't a problem, it's a category of a thousand different problems, and I hadn't picked one, let alone validated it with an actual small business owner.

Footrr: a real idea, skipped the homework anyway

Later came Footrr, a side project built around email-footer advertising: the idea that a line of ad space at the bottom of everyone's outgoing email signature was an untapped channel. Unlike Kalast, this one actually had a specific mechanism. But I made the same underlying mistake: I started building before doing any real market exploration. No conversations with potential advertisers about budget or channel preference, no conversations with potential senders about whether they'd ever allow it, just a cool idea and a weekend of code.

Guess where that landed? Nowhere, again. Footrr never took off, and it didn't fail because the technology was hard, the technology was the easy part. It failed because I never found out, before writing a line of code, whether the demand I imagined actually existed at a price anyone would pay.

Arbington.com: finally doing the homework, and a different outcome

Arbington.com, a peer-to-peer education platform I built between 2021 and 2022, was the first time I actually did the work before the work. I talked to potential customers. I tried to understand what people teaching and learning peer-to-peer actually needed, not what I assumed they needed. I built a real MVP instead of a finished vision, and I used what I learned from actual usage to keep adjusting the product instead of defending my original plan.

It landed in a much better place. Not because I'd finally written better code, the code wasn't meaningfully more impressive than Kalast's or Footrr's, but because the product existed in response to something real instead of something assumed.

And here's the part that matters even more than the early traction: I still closed Arbington. After about a year of actually understanding the market, I concluded there wasn't a durable product/market fit, and that AI was about to consume a large part of the peer-to-peer education category outright. I made that call in 2022, before "AI is going to change education" was the consensus take it is now. I'd rather be the founder who understood the market well enough to shut the right thing down on time than the founder who kept refactoring a doomed product because the sunk cost felt too large to walk away from. Understanding the market isn't just about knowing when to build, it's about knowing when to stop.

The pattern underneath all three

Kalast and Footrr shared the same root cause even though they looked nothing alike on the surface: I built a cool, well-oiled machine in response to a problem I didn't actually understand yet. And because the problem underneath kept shifting as reality pushed back, so did the code. I pivoted, and pivoted again, and rewrote the same features under new assumptions over and over, not because the architecture was wrong, but because the business homework that should have come before any architecture never happened. Every rewrite was downstream of a market question I should have answered with a conversation instead of a commit.

Arbington didn't skip that step, and that's the entire difference between "nowhere" twice in a row and an outcome I'm still proud of, even though it ended in a shutdown.

What I'd tell myself fourteen years ago

• Learn the problem before you learn the stack. Talk to potential customers before you touch a framework decision, they will tell you things no amount of technical cleverness will reveal on its own.
• Build the smallest possible MVP, then get iterative feedback from real usage. The MVP's job is to generate information, not to impress anyone.
• Start with small, boring technology and scale it as the business actually grows. A billion-dollar-scale architecture is worthless if you're sitting at $0 in monthly recurring revenue, you are solving a problem you do not have yet.
• Separate what the market wants from what the market needs. "Help small businesses grow" was a want-shaped wish. A specific, painful, provable need is a business.
• The technology is the delivery mechanism, not the product. Nobody has ever paid for a framework. They pay for a problem going away.

The framework was never the risk in any of these three companies. The risk, every time, was whether I understood the market well enough to know what to build, and when, if ever, to stop building it. Kalast and Footrr taught me that lesson by failing quietly. Arbington taught me the harder version of the same lesson: understanding the market well enough to build something real, and understanding it well enough, a year later, to walk away before the market finished saying no.

← Back to writing Get in touch