Matthew Gladding

Posted on Aug 27 Originally published at gladlabs.io

Fix the Tool, Not the Bank Balance: Why Builders Who Ignore Money Make More of It

#moneybyproducttheory #technicalbuilders #buildingtools #professionaldiscipline

Sawdust is a byproduct. Nobody sets out to make sawdust. You set out to cut a board straight, and the sawdust falls out the side of the blade whether you want it or not.

Money works the same way for a lot of the best technical builders I've watched. You don't sit down and decide to make $40,000 this month. You sit down and fix the thing that's broken, ship the tool that actually works, and the money falls out the side.

This isn't a new idea. Business writers have been saying some version of it for years. YourStory put it plainly back in 2018: the only way to make money in business is to stop focusing on the money itself and focus on growing your capability as the person who runs the business. Success, in that framing, isn't about the pile of cash -- it's about becoming someone capable of generating it. A Substack writer made almost the identical point more recently, arguing that money is just the byproduct of doing the right thing, and that we've all been trained to treat money as some mystical force to chase and hoard instead of what it actually is -- an output. Bonnie Gillespie framed it from the actor/creative side: money isn't success, it's a byproduct of success -- you can love your work and still call it work, because work is still the thing you do to earn the money that buys the things you need.

None of that is controversial in the self-help world. What's less obvious is what it means when you're the one writing code, tuning a model, or shipping a SaaS product at 1am with a cold coffee next to the keyboard. So let's take the theory out of the inspirational-quote graveyard and put it somewhere it can actually get tested: a technical build.

What "byproduct" actually means in an engineering context

Here's the failure mode I see constantly in indie dev circles: someone picks a revenue number first -- "I want $10K MRR" -- and then goes hunting for a product that hits it. They build backward from the number. Every decision gets filtered through "will this move the metric," which sounds disciplined but actually produces something worse: a product built to satisfy a spreadsheet instead of a user.

The byproduct theory flips the direction of causality. You pick the problem first. You get obsessively good at solving it. The revenue shows up as evidence that you solved it well, not as the goal you were optimizing toward the whole time.

Jonn Kim's story, covered by Vanderbilt's engineering school, is a clean example of this outside the software world specifically, but it maps directly. He started GaN Corporation with nothing to lose, willing to work at McDonald's if it fell apart. He didn't start with a revenue target. He started with the resources everyone actually has -- time and aptitude -- and treated money as the byproduct of applying both well. Ten years later the company was pulling public and private contracts across software, hardware, and cybersecurity. The money followed the capability. It didn't lead it.

That's the technical version of the theory: build the capability, and the revenue is the exhaust.

Where this shows up in real indie technical work

We've written before about the actual revenue mechanics for indie hackers -- the diversity of income streams beyond a single SaaS subscription that most solo builders end up cobbling together by year two. What's interesting reading that piece back through the byproduct lens is how few of those streams started as revenue plays. API wrapper tools, Chrome extensions, small utilities that scratch the builder's own itch -- they get built because the itch is real, and the money comes later, once other people turn out to have the same itch.

Same pattern shows up in the 90-day SaaS launch breakdown we did. The founders who actually hit meaningful traction in that window weren't the ones obsessing over pricing pages on day one. They were the ones who nailed the core workflow so hard that pricing became an afterthought -- a number you slap on something people already can't live without. The ones who front-loaded monetization mechanics before the product actually worked burned their 90 days on the wrong problem.

This is the technical version of what the Medium writer behind the "thought series" on money as byproduct is getting at: the events that generate money are downstream of a thought process, and if the thought process is aimed at the wrong target, the money either doesn't show up or shows up attached to something fragile.

The technical debt version of the theory

Here's where the theory gets teeth for engineers specifically, and where a lot of the soft, inspirational framing of it falls apart if you don't add a caveat.

Byproducts aren't always good. A sawmill also produces noise, heat, and waste that has to go somewhere. If you don't manage it, it piles up and becomes a liability instead of a footnote.

Technical debt is the negative byproduct of the same process that produces revenue. You ship fast, you solve the real problem, money starts flowing -- and quietly, in the background, you've accumulated a pile of shortcuts that will eventually cost you. We covered this directly in our piece on taking RAG pipelines from proof of concept to production: the demo that impresses a client in week one is rarely the same architecture that survives real traffic in month six. The gap between those two states is where a lot of "byproduct" money quietly evaporates, because the thing that made the money wasn't actually stable -- it was a proof of concept wearing a production costume.

If you're building with the byproduct theory in mind, this is the discipline it demands: you still have to manage the exhaust. You don't get to say "I'm focused on capability, not money" and use that as cover for ignoring the mess your capability-building leaves behind. The theory says money is downstream of good work. It does not say bad infrastructure is downstream of nothing.

Hardware, cost structure, and the byproduct trap

There's a version of this trap that shows up specifically in AI/ML tooling, and it's worth naming because it's easy to miss until your cloud bill lands.

We wrote about the VRAM currency problem -- the fact that the hardest limit in local AI work isn't compute, it's memory, and a 70B model in FP16 needs roughly 140 GB, which is nowhere near what a single consumer card gives you. That constraint is a physical fact, not a business decision. But here's the trap: if you're chasing money as a direct target rather than a byproduct of solving a real inference problem well, you'll make hardware decisions optimized for the wrong thing. You'll rent the biggest GPU instance you can justify on a spreadsheet instead of architecting around the actual memory ceiling you're hitting. You'll throw dollars at the problem instead of engineering around it.

The builders who treat money as a byproduct behave differently here. They solve the VRAM constraint first -- quantization, offloading, smarter batching, whatever gets the model to actually fit and run at a workable speed -- and then the cost structure that falls out of that solution is what they charge against. The cost-conscious architecture becomes a byproduct of solving the technical problem properly. Flip it around, throw money at the problem before you understand the constraint, and you get an expensive workaround bolted onto a system that was never actually solved.

The professional discipline this requires

None of this works as an excuse to ignore your numbers. That's the part the soft version of the theory glosses over and the part worth being blunt about here.

"Money is a byproduct" is not the same claim as "money doesn't matter" or "don't look at your metrics." It's a claim about sequencing. You still track revenue. You still watch churn, watch your infra spend, watch conversion. What changes is what you optimize for when you're making a technical decision at 11pm with a deploy button in front of you.

Wrong question: "Will this feature increase MRR this month?"
Right question: "Does this solve the actual problem better than what exists?"

The first question gets you feature bloat aimed at a dashboard. The second question, asked consistently and answered honestly, produces a product good enough that the revenue question mostly answers itself. The Substack post on this made the point that we've all been trained to treat money as this mystical force to chase -- and the antidote isn't apathy about money, it's redirecting the chase toward the actual work that generates it.

This distinction matters more in technical work than almost anywhere else, because technical problems are unusually good at exposing when you've cut the wrong corner. A pricing page can hide a mediocre product for a while. A production incident cannot. If your RAG pipeline hallucinates in front of a paying customer, no amount of clever monetization language saves that conversation. The technical reality surfaces fast, and it surfaces in a way that a services business or a content business can sometimes paper over longer.

A worked example: the $5,000/month builders

We looked at this directly in the $5,000/month blueprint piece on indie hackers hitting acquisition speed. The pattern across those builders wasn't "find the fastest path to $5K." It was closer to: solve one specific, narrow, technically real problem, solve it completely, and let the acquisition speed be a signal that you'd actually nailed something rather than a target you engineered toward directly.

That's the byproduct theory doing real work in a specific, checkable dataset instead of floating as a motivational poster. The founders who hit that number fast weren't the ones with the best pricing psychology. They were the ones whose tool did the one thing it claimed to do, reliably, without you needing to read the FAQ to understand why it broke.

Where the theory needs a harder edge for technical builders

I want to push back on the softer, more spiritual version of this idea that shows up in a lot of the writing on it, because it can drift into something unfalsifiable if you let it. "Do the right thing and money follows" is true often enough to be worth repeating, but it's not a law of physics. Plenty of people build genuinely good, well-engineered things that never find distribution, never find the right audience, and the money never shows up regardless of how sound the underlying work is.

The honest version of the theory, for a technical audience, needs a second clause: money is the byproduct of solving a real problem well, and getting it in front of the people who have that problem. Drop either half and the theory breaks. Solve a real problem badly, and no amount of distribution saves you -- the churn numbers will tell you that within a month. Solve a real problem beautifully and never surface it to anyone who has it, and you've built a very elegant machine that produces nothing but your own satisfaction.

This is why the byproduct framing pairs so well with the more mechanical, revenue-stream-focused pieces we've written. The theory tells you where to point your attention while you're building. The mechanics -- pricing, channels, the actual diversified income streams indie hackers lean on -- tell you how to make sure the byproduct actually reaches a market instead of evaporating in a GitHub repo with twelve stars.

Applying it to your own build this week

If you're sitting on a technical project right now, trying to decide whether it's worth continuing, here's the practical test the theory gives you, stripped of the inspirational language.

Ask what capability you're actually building. Not what feature you're shipping -- what capability. Are you getting measurably better at solving a real class of problem, or are you bolting features onto a foundation that was never solid to begin with? If it's the latter, no revenue number you hit will be stable, because you haven't built the thing that's supposed to produce the byproduct in the first place.

Then ask what you're doing with the actual byproducts of your work so far -- the technical debt, the infra costs, the corners you cut to ship fast. Are you managing that exhaust, or is it piling up behind the mill? The engineers who treat this seriously build in cleanup passes the same way they build in features. The ones who don't end up rebuilding the whole pipeline eighteen months in, at a much higher cost than if they'd managed the byproduct as it accumulated.

And finally, ask whether the problem you've picked actually has people on the other end of it who need it solved. This is the part that separates the theory from wishful thinking. Doing excellent, disciplined, capability-building technical work on a problem nobody has is still going to produce zero revenue, and no amount of "money is just a byproduct" reframing changes that. The theory works because good work aimed at real problems tends to attract the people who have those problems. It doesn't work as a substitute for having a real problem in the first place.

The takeaway for builders, not dreamers

Money as a byproduct isn't a mood. It's a sequencing discipline. Solve the real technical problem first -- the VRAM ceiling, the pipeline reliability, the actual workflow your users are stuck on -- and manage the byproducts of that work honestly, the debt and the costs included, not just the revenue. Do that consistently, aimed at people who actually have the problem, and the money shows up as evidence you did it right.

Chase the number directly and you'll build something optimized for a spreadsheet instead of a person, and eventually the technical reality catches up with you faster than it would in almost any other kind of business. That's not a bug in software and AI work. It's the feature that keeps this theory honest.

DEV Community