Aug 30, 2026
I’ve spent years working with non-technical stakeholders, and even non-technical direct managers. If you’re a non-technical person reading this, surely you don’t want to get choked with technical jargon, don’t you?
So, suppose I’m building software or an app. What else do I need to care about as a non-technical person?
I’m sure you understand about fuel efficiency in cars. You won’t be surprised that the principle is more or less the same in software.
To run your software, you tend to need a server. But why do I need a server? in simple words, to store the database and run the “brain” of the program. What about offline apps? they don’t need a server. That’s true. However, chances are you don’t want offline apps because you can only sell them once (and you can’t sell services there).
So what does it have to do with efficiency? the more efficient your software, the less powerful server you need to rent. It is the same as the more efficient your car, the less you need to refuel (or charge). Take for instance an efficient software may need 2 CPU and 8GB RAM, while an inefficiently-built software may need 8 CPU and 64GB RAM.
The OpEx (Operating Expenses) can be staggering for inefficiently-built software. Search it up, there are people who got their server bill skyrocketed because of the inefficiency.
In principle, the more efficient your software, the less server you need to rent. The more efficient your car, the less you need to refuel or recharge.
We might be well aware of hidden costs in building construction. Suddenly you need to buy more materials, etc.
This is particularly true too for software. Especially now there are a lot of “Pay as you Go” services. In hindsight they are good because we have lower OpEx if there are fewer users using our software. However, they are also bad because it makes the cost substantially unpredictable.
But is it justifiable? In economics we know there’s this “Elasticity” and “Unit Economics” concept. So, let’s say if revenue grows 2x while server cost grow 4x, probably not. But, if revenue grow 2x while server costs grow 1x, it is probably justifiable.
I’ve seen countless of software vendors giving bad proposals to me. The proposed software tend to be something that can be done quickly, but extremely unmaintainable and inefficient. I understand, it is true we have to go to market quickly, but do we want a building without a strong foundation? surely not, we will need to demolish the whole building and rework the foundation had we want to upgrade into two-story building.
I’ve become a speaker and pick up a topic of “Overengineering and Underengineering: Don’t overcook or undercook your software” back in 2025. I see a pattern software vendors love to underengineer, and in-house team love to overengineer. I wonder why.
The strongest contender is because of misaligned incentives. Chances are you are paying your software vendor a fixed price based on man-days. Of course, they are incentivized to get more “work” out of you. What about fixed price project? they are also incentivized to quickly finish the project even if it means low quality code and system design. Furthermore, good software engineers tend to already “absorbed” into larger big tech companies.
Economists call this the principal-agent problem: the person doing the work does not necessarily have exactly the same incentives as the person paying for it. You probably have this problem without realizing.
So, the incentive is wrong in the first place. Then you might ask, what should be the incentive? My argument is, if we live in an ideal and beautiful world, we should be rewarded for an outcome-based incentive. Like pay a certain amount if they can have create a resource-efficient software, a scalable software, etc etc depending on what you need. However this is still highly debated as its also hard to measure. Still if you can measure it, I highly suggest an outcome-based incentive.
There’s a high chance vendors (even myself) would reject an outcome-based incentive if we don’t control the entire outcome. Suppose the outcome is increase conversion by 30%, probably vendors would reject that because marketing has huge influence there too. But there might be a chance vendors accept a delivery milestone, latency, uptime, test coverage, and load capacity outcomes which are good proxies to a good efficient reliable software.
Did you know, that even software companies buy software too? this is the biggest misconception most people have who never work at a software company. Once my non-technical friend joined my company and keep thinking why should we buy this software instead of just building it. Even as big as Google, Amazon, and regional giant like Shopee still buy software.
If you’re comfortable with numbers, I’m sure you can calculate return on investment. It’s the same with build vs. buy tradeoffs. In-house engineers have salary, vendors have service charge, SaaS have subscription fee. Even-if you’re good with numbers, probably you have a “judgement” problem. We cannot reliably judge how long a software development will be. We can only roughly estimate it.
A rule of thumb is, estimate the worst case. Let’s say the engineering manager / vendor said the software will be done in 5 months, up your calculation to 8 months or higher (depending on your risk management) for buffer. You can then count the engineers’ salaries of 8 months, the vendor’s service charge, and the SaaS subscription cost.
Of course there’s this “Discounting” principle in economics too, where money in the present day are worth more than in the future. Because money today is worth more than the same money several years from now, compare build and buy over the expected lifetime of the software, not only by looking at today's price.
Yes you can. In fact, I highly recommend it if you’re building prototypes and testing the market. But when you have validated the market, and cost of failure is higher than the cost of a professional, I highly recommend hiring a professional. Be very careful with this, because remember it will be your first impression to the market too. Try to not mess it up.
However never overstep your boundary. You would not tell “why should I hire a finance? I can do excel myself” right? and certainly you don’t want to be told “why I should hire you? I can do it with AI now” by your customers too. AI is making code cheaper. It is not making correct decisions equally cheap. So does grinder machine makes grinding coffee beans easy, but not necessarily makes creating good coffee equally easier.
Build if strategic value of ownership is higher than total cost of ownership + opportunity cost. Does it matter for you to own the database? are you planning to sell the software? does existing opportunity in the market cannot satisfy your use case?
There’s so much variable, and probably worth having a coffee with me.
