We Built the Same Product Twice. Only 6% of It Carried Over.
Our second product reused 6% of the first one's business logic and still shipped far faster. The savings came from somewhere most people never budget.
The number that surprised us
We build software for two businesses that sound like the same business. One rents things out by the day. The other sells and manages property. Described in a sentence, both are someone paying to use a building or a vehicle for some period of time.
When we started the second one, everyone involved assumed most of the first would carry over.
Between them, the two products describe 113 business concepts — the things the software has to know about, like a customer, a contract, a price rule, a booking. Seven are shared.
Six percent.
The second product still shipped far faster than the first. Understanding why is worth more than the number itself, because the same logic decides whether an automation project inside your own company pays for itself.
Why two similar businesses share almost nothing
The sentence that makes them sound alike is the sentence hiding all the differences.
A rental company has vehicles. They exist or they do not. A property developer has buildings under construction, where each apartment moves through stages — planned, framed, finished, ready to hand over — and half the business is tracking which stage each one is in. There is no version of a car that is sixty percent delivered, so there was nothing in the first product to borrow.
A rental booking opens and closes inside a week. A property sale runs for months and involves a buyer, a seller, an agent, and often a bank, each of whom needs their own view of the same transaction. We know exactly how far you get by treating that as a booking with extra fields: right up until the first commission has to be split three ways.
And a rental company has customers. A property company has customers, owners and investors — people who never buy anything through the system and log in only to see what their asset is doing. There is no equivalent at all in the first product, which is the clearest sign that these were never the same business.
Where the savings actually were
Nothing above is where a second product gets cheap. The savings sit underneath, in the part no customer ever sees and no proposal ever itemises.
Before a property platform can do anything about property, it needs all of this:
| What every product needs | Who notices it |
|---|---|
| Logins, companies, staff roles, permissions | Nobody, until it is wrong |
| Billing connected to a real payment provider | Finance, monthly |
| Messages from WhatsApp and Telegram in one queue | Whoever answers them |
| Notifications, translations, audit trail | Auditors and lawyers |
| Encryption of personal data | Everyone, once |
That list took months the first time. It is identical whether the message is about a hatchback or a two-bedroom flat. And roughly a third of our second product turned out to be exactly this — infrastructure with nothing to do with real estate. It is the same machinery any company ends up needing when it automates a process, which is why it is worth owning once.
Build it once and the second product begins where the interesting work begins. That is the whole trick, and it is unglamorous enough that most plans leave it out.
The rule we use
One question decides where anything goes: would a second product do this differently?
If two products would do it the same way, build it once. Letting each team write its own version is how a company ends up with four slightly different login systems and fixes the same bug four times.
If two products would genuinely differ, keep them separate. A single flexible version covering both cases usually ends up harder to follow than the duplication it was meant to remove.
Logins and permissions pass without argument. Pricing fails immediately — seasons and tiers on one side, commissions and multiple parties on the other. When we cannot tell, we keep things separate, because merging later costs an afternoon and separating later costs a quarter.
Why this matters if you are not building software
Most companies that ask us to automate something describe the process as unique to them. The business rules usually are.
What is almost never unique is everything around them: pulling enquiries in from several channels into one queue, deciding who handles what, escalating to a person when the system is not confident, recording what happened, and reporting on it afterwards. That machinery is the same for a clinic, a logistics firm and an equipment rental company. It is also the part that takes longest to build from nothing.
That is the real reason we can put one to three workflows into production in two to four weeks rather than two to three quarters. Nobody is rebuilding the machinery. You pay for the rules that are yours, which is also why the payback arithmetic works out at all.
The mistake worth avoiding is the one we nearly made ourselves: assuming that because two things sound alike, the expensive parts will transfer. They rarely do. Start by finding out which parts of your process are actually yours, and be honest about how ordinary the rest is — that ordinariness is exactly what makes it cheap.
01If almost nothing transferred, was the shared foundation worth building?+
It was the only reason the second product was fast. The confusing part is that the savings show up somewhere nobody puts on a plan. Before a property platform can do anything about property, it needs logins, companies, staff roles and permissions, a billing system connected to a real payment provider, a way to receive messages from customers on WhatsApp and Telegram, notifications, translations, an audit trail of who changed what, and encryption of personal data. That list is months of work, it is identical whether you rent out cars or sell apartments, and getting any of it subtly wrong is the kind of mistake that surfaces during a security review rather than a demo. Building it once means the second product starts at the point where the actual business begins. The industry rules were always going to be different - that was never where the money was.
02Why did two such similar businesses share so little?+
Because they only sound similar. Both are described as someone paying to use a property for a period, and that sentence hides every difference that matters. A rental has a vehicle that either exists or does not; a developer has a building under construction where each apartment moves through stages before anyone can live in it. A rental booking opens and closes in a few days; a property sale runs for months with a buyer, a seller, an agent and sometimes a bank, each needing their own view of the same deal. A rental company has customers; a property company also has owners and investors who never buy anything through the system and log in purely to watch what their asset is doing. Once you write those down, the surprise is not that the overlap was 6%. The surprise is that anyone expected more.
03How do we decide what to build once and what to build per product?+
The question we ask is whether a second product would do it differently. If two products would do it the same way, build it once, because letting each team write their own version is how a company ends up maintaining four slightly different login systems and fixing the same bug four times. If two products would genuinely differ, keep it separate, because a single flexible version covering both usually becomes harder to understand than the duplication it replaced. Logins and permissions pass that test without argument - a user, a company, who is allowed to do what - and any difference between products there is a bug rather than a feature. Pricing fails it: rental pricing has seasons and tiers, property pricing has commissions and multiple parties, and a universal pricing engine covering both would frustrate everyone. When we cannot tell, we keep it separate, because merging later is easy and separating later is not.
04What does this mean for a company automating its own operations?+
The same principle applies at a much smaller scale, and it is usually the difference between an automation that pays back and one that quietly does not. Most companies asking us to automate a process describe it as unique to them, and the specific business rules usually are. What is almost never unique is the surrounding machinery: getting messages in from several channels into one queue, deciding who handles what, escalating to a person when the system is unsure, keeping a record of what happened, and reporting on it. That part is the same for a clinic, a logistics firm and an equipment rental business, and it is also the part that takes the longest to build from scratch. When we quote 2-4 weeks for one to three workflows in production, the reason it can be weeks rather than quarters is that we are not rebuilding the machinery each time. You are paying for the rules that are yours, not for the plumbing that is nobody's.
