There are two distinct modes of software development: building for business and building for personal fulfillment. The goals, constraints, and metrics differ radically. Mistaking one for the other will cost you time, money, and most importantly the success of your project.
There is a fundamental distinction between writing software as a business asset and writing it as a personal pursuit. One demands pragmatism. The other invites exploration. Understanding the boundary between the two is critical for anyone who wants to build sustainably, and win.
When building software for personal interest or intellectual pleasure, it’s reasonable to over-engineer, like I'm doing it here with this site, since it's a hobby for me, and almost all my GitHub projects are. You can chase elegant abstractions, refine naming conventions, experiment with architectural patterns, or pursue perfect type systems. The goal isn’t speed or ROI, it’s mostly expression, craftsmanship or maybe learning. That’s valid. But it’s not the mindset for building a business.
When writing code for business purposes, your priorities must change. Nothing matters unless it directly reduces CAC or increases LTV. That’s the core economic truth. Your engineering decisions should either help you get more users more efficiently, or retain them longer and increase their value over time.
Don’t confuse stack quality with business quality. Users don’t care whether you’re using TypeScript, Rust, PHP, or even Bash. They care whether your product works and feels reliable. Poor performance causes churn. Churn kills LTV. That’s the only metric that matters. A technically "correct" application that users abandon is a failed product.
That said, speed is not a license for chaos either. Early decisions compound. If foundational code is brittle, undocumented, or structured around shortcuts that don’t actually scale, it will become a bottleneck. Eventually, new features will slow down. Onboarding engineers will become difficult. Entire segments of the codebase may become untouchable. At that point, rewriting is often the only option, and it’s usually too late.
This is where discipline matters: write just enough quality to avoid future collapse, while resisting the urge to overpolish. Good enough is often exactly enough; if you know where that line is. Learning to see it is a strategic advantage, and it only comes from hard experience.
Make every decision through the lens of economic leverage: what unlocks growth, what removes friction, what preserves momentum.
So: build with intention. If you're coding for business, every decision should serve the business. If you're coding for the sake of craft, allow yourself to enjoy the process. Both are valid. But don’t confuse them.
Because one of them is trying to make money. And money doesn’t care how elegant your code looks. If code really mattered so much, dev shops would be the giants of industry and not Google.