2025-09-09 6 minute read

Engineering Quality For Acquisition

Welcome back to the end of the eighth week of business development and international travel! In this week's episode, I wanted to talk about over-engineering, and how as an academic purist you might be tempted to put profit on hold whilst you build the perfect infrastructure, but that this pursuit will lead to zero gains in the short term. Plus a bit about the final boss of entrepreneurship - acquisition.

Understanding Your Job

As a founder, entrepreneur, tech shaman, or whichever title you feel most suitably describes your situation, you have only one job. That job is to make money, and not only to make money; but to do so in a sustainable and repeatable way. If we're being specific, your job is actually to plan, build, and maintain, revenue engines . A revenue engine is a like any other engine, but instead of an input and output of petrol and mechanical power respectively, it takes in cash and time, and outputs more cash. For context, the global stock market has grown (- inflation) by roughly 7% every year for the last 100 years. In this sense, a global index is a bit like a revenue engine; if you put in $1000 and one year, you'll probably get $1070 back. The goal then is to build revenue engines with a higher annual return than this, otherwise it makes more sense to just sit and do nothing, or enjoy gainful employment as a reliable way to get money to then buy more of the global index (not financial advice).

If you read my earlier episode about How To Bootstrap A Business , you'll know that getting a business started can be done very cost effectively. It's important to remember (since we're thinking in terms of revenue engines) that these are only the visible costs . You also need to account for the cost of your own time, and the opportunity cost of other pursuits (e.g. emploment), when you're deciding which revenue engines to pursue. For example, growing and selling house plants is an almost guaranteed revenue engine in most western countries (if you're reading this and are passionate about killing plants, I recommend this book ), however, when considering the opportunity cost of employment or other ventures it might not be worthwhile. It's also important to consider the upper limit of the engine, taking the house plant venture as an example; there is a maximum cash input before space, market, and management constraints will choke the engine. This means it's hard to scale, which makes heavily constrained ventures like this less attractive from a business development perspective, but if you can mitigate these issues then they can become worthwhile (looking at you, house plant NFTs *).

Over-Engineering

The technical infrastructure I'm building has enabled me to create at least one revenue engine already, with others on the way ( nothing to do with plants, yet ). This is exciting but it introduces other questions like; is it better to spend time improving the infrastructure for building engines, or just to build more engines ? I've been improving infrastructure only when it directly contributes to an existing engine, or one which is under construction, which I think makes sense. The follow up issue is what 'done' looks like, since like in most areas of life, there is a 'bare minimum' implementation, one which is a bit more polished, and a perfect solution. I'm only slightly ashamed to admit that I'm yet to create a solid test framework for my core internal services, which is what I would consider a polished implementation. This doesn't affect the execution of the engine, but does affect its maintainability and extensibility in the short term , so is something I'll be working on this week.

Long Term Planning

In other news; if you're interested in the world of startups and business, then you'll be familiar with the concept of acquisition. If not, this is when a larger company buys a smaller company, either to strip it for parts (take e.g. an engineering team out and put it in another area, or extract datasets and information), or to assert control over the direction and growth whilst letting it exist in/close to its current form (and hopefully making more than a 7% return). If you're building a startup with AI in the name, then your mission is to get someone less intelligent but wealthier than you to do this. However, if you're building anything else, then acquisition is about how your revenue engines work , how reliable they are, and how transferrable they are.

When it comes to building something like technical infrastructure, this means asking how easy your systems are to maintain, how much technical expertise is required to understand and use them, and ultimately how replaceable you are as the tech shaman in the middle of your spiders web of systems**. If however your goal is not acquisition, then your replaceability factors in much less to your overall plan, and you can therefore spend less time on polishing your systems, and more time on building engines. I don't have any stats on this but I don't think many businesses are acquired out of all the businesses which ever exist (and most fail), but I think it's still a worthwhile pursuit if only for the nudge towards better engineering and more explainable processes that it provides.

Maybe one day OJS Group will be absorbed into Alphabetflix Megacorp for $250 and all of this will become a distant memory, but until then, I'll be writing more about what I'm doing, where I'm going, and what I'm working on, so next time please join me for a comprehensive boots-on-the-ground review of France, and just a few short days after that I'll be packing up and travelling to Da Nang. I hope everything is going well wherever you are in the world, and if you haven't already, please let your favourite colleague/parent/group chat know that if they haven't subscribed to this newsletter, they're not going to be invited to the 2030 subscriber gala.

Thanks and all the best,

Oliver

* this is of course a joke, please don't buy NFTs
** a clean, well organised, and fully documented spiders web

Previous Episode: In Pursuit Of Sustainability