Before you approve any custom software, run it through one question: would a customer ever notice this exists? Would they pick you, stay longer, or mention you to a friend because of it? If yes, it might be worth building. If no, you are about to spend real money making something invisible, and you should buy it instead.
That single test has saved me from bad calls on both sides across 24 years in storage - as the operator itching to build, and as the one called in to clean up after someone built the wrong thing. It sorts almost every case correctly, and it does it before a dollar is committed.
The invisible things - buy them
A tenant renting a unit will never see your payment engine, your accounting, your ticketing, or the software running your billing. They notice whether the charge goes through and whether the gate opens. Everything behind that is invisible to them, which means building it wins you nothing they will ever reward. No tenant in history has renewed a lease because of the elegance of your invoice generator.
And building it costs far more than the quote says. Custom software is not a one-time buy; it is an ongoing bill you pay in upkeep. It breaks when a system it connects to changes, which happens constantly. It has to be re-secured every year it lives. It has to be re-explained to every new hire, and the only real documentation is inside the head of whoever wrote it. The day that person leaves, you own something critical that nobody left can fully explain - the software equivalent of a car only one mechanic in town will touch, and he just moved. I have watched operators pour real money into a homegrown version of what a vendor licenses for a modest monthly fee, and the build was the cheap part. The five years of keeping it breathing is where it got expensive, and none of that was on the original invoice, because the person quoting had no reason to put it there. Vendors carry that weight for the invisible systems. Let them.
The things they choose you for - build those
Now the cases where building is right, precisely because you cannot buy them without becoming identical to every competitor.
The path from "what does this cost" to a paid rental and a working access code, at eleven at night, on a phone, with nobody in the loop. Operators win real business on how little friction sits in that path. The off-the-shelf version is the same one your competitors run; the friction you strip out that they did not is yours alone, and a custom flow that nails it is a legitimate build.
The way your specific systems move as one - a rental dropping cleanly into the PMS, triggering the access code, starting the billing, and pinging the team, without anyone rekeying a thing. No vendor sells your exact combination working together, and across multiple sites that connective work is often the strongest edge you have.
If a customer would feel it, build it.
When you build, build so you can walk away from it
Even the right build turns into a trap if you build it heavy. Keep the custom layer sitting on top of purchased systems, never replacing them. Your booking flow should call the PMS through its interface, not reinvent unit management. Your integration work should pass data between vendors, not quietly become a second database. Write it so a new developer can follow it without the original author in the room, and structure it so that if it fails or ages out, you unplug it and drop back onto the bought systems underneath instead of operating on your own core.
Thin builds keep the upkeep bill in line with the value they return. Heavy builds - the homegrown PMS, the everything-platform - start looking like an asset and end up owning you.
Back to the test
Would a customer notice? Your booking experience, yes. Your invoice generator, never. They are renting a box; they register speed, simplicity, and whether the door opens. If they would notice, build it thin and make it the best in your market. If they would not, buy it, set it up well, and put the difference toward something they will.
Drawing that line deliberately - and keeping the builds thin enough to unplug - is the core of an architecture that survives growth. Deciding it on purpose, before the wrong build becomes load-bearing, is what the Blueprint does.
Start with a Blueprint