We Built the Same Product Twice. Only 6% of It Carried Over.

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 inquiries 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.