Most operators who ask us to scope a custom integration should not build one. The standard app plus a properly designed account structure covers what they described, costs nothing extra, and does not need a developer on retainer in eighteen months. We are saying that as the people who would supply the hardware either way, having seen enough half-finished integrations sitting on someone’s laptop after the developer moved on. Here are the tests worth applying before you commit, and the honest picture of what a build costs when it is the right call.
Five questions that decide it
Does access have to follow a record that already lives somewhere else?
This is the strongest signal. If your bookings, tenancies, or staff rota live in a system, and access has to mirror that system automatically, you have a real integration case. If a human already knows who should get in and could type it, you do not.
How often does access change?
Twenty doors with stable occupants is an admin task. Twenty doors turning over daily is a system. Frequency matters far more than door count, and people consistently get this backwards.
Do you have a compliance or audit obligation?
If you must produce a defensible record of who entered where, and reconcile it against another system, that reconciliation is the integration. If you only need to look something up occasionally, the standard log does it.
Will anyone maintain this in year two?
The question that kills most builds. Platform versions move, staff leave, and an integration nobody owns becomes a liability the first time it silently stops issuing codes. If you cannot name the person or the agency who owns it next year, do not start.
Is the standard app genuinely insufficient, or just unfamiliar?
Worth asking honestly. A lot of custom requests are really a request for a better admin structure. Groups, sub-admins, and per-property permissions solve more than people expect, and they cost nothing.
Two or more clear yeses is a build. One is a maybe. Zero is a configuration job.
What building actually involves
The integration itself is not the expensive part. A competent developer can have codes issuing against a booking record inside a couple of weeks.
The cost sits around it. Someone has to survey the site and confirm gateway coverage before a line of code is useful. Someone has to decide, in writing, what the system does when connectivity drops and whether doors fail open or stay locked, which is a safety and licensing question your client signs off, not a technical preference. Someone has to handle the developer account approval on the platform, which takes days and is not instant. Someone has to build the admin screens your operations team will actually use, because an integration with no interface just moves the problem into a database.
Then it has to be handed over with documentation, and it has to be monitored, because a silent failure in code issuance looks exactly like nothing happening until a guest is locked out at midnight.
The middle option people skip
Between doing it manually and building your own, there is usually an existing tool that already connects both ends.
In holiday-home operation, channel managers and property management systems already hold reservations and already talk to lock platforms. In co-working, several booking platforms have access control built in. In facilities, some management systems do the same.
Checking for that first is not lazy. It is a subscription against a build plus permanent maintenance, and it wins on nearly every comparison at small and medium scale. Build only when you have checked and the tool does not exist, or it exists and genuinely cannot do the specific thing you need.
When the answer really is build
A few situations where it is clearly right.
You already run your own platform that customers log into, and access is a feature of that product rather than an internal admin task. Your operation is large enough that manual issuance is a role rather than a task, meaning hundreds of doors or thousands of access events monthly. Your access rules are unusual enough that no off-the-shelf tool models them, such as tiered membership with different rights by time of day and location. Or you have a compliance requirement that forces reconciliation between access records and another system on a schedule.
Notice that all four are about the business, not the technology. The technology is available to everybody. What differs is whether you have a problem big enough to justify owning software.
What breaks in year two, and how to survive it
Platform APIs version, and endpoints get deprecated with notice that nobody at your company is reading because the developer who registered the account has left. Fix: put the developer account in a company mailbox, not a person’s.
Hardware gets replaced by facilities without telling anyone, and the new units are a different model with different capabilities. Fix: write the hardware model into your operating procedure so replacements are like for like.
Gateways get unplugged during cleaning or a fit-out and nobody notices until a code fails. Fix: monitor gateway status and alert on silence, rather than waiting for a complaint.
And the original scope quietly drifts, so a system built for time-limited guest codes ends up issuing permanent staff credentials, filling on-device storage that has a limit of roughly 100 credentials per type. Fix: expire everything, always, even for staff.
Where Altix fits
We do not write your application, and we have no incentive to tell you that you need one. What we bring is the layer underneath: the hardware, the site survey, and a reference design already proven in UAE buildings that covers credential strategy, gateway topology, failure behaviour and account structure.
That design is worth as much to the operators who decide not to build as to the ones who do, because it is the same set of decisions either way. Whether your access rules end up living in custom code or in an off-the-shelf tool, somebody still has to choose the credential types, survey the coverage, and define what happens when the connection drops.
Tell us what you are trying to automate and at what scale on WhatsApp. The first read is free and you will get a straight answer on whether it is a build, a subscription, or an afternoon of account configuration. If it turns into a deployment or an advisory engagement, we quote for that separately.
Frequently asked questions
How many doors before a custom build makes sense?
Door count is the wrong measure. Access events and rate of change matter more. Fifty stable doors need less than ten doors turning over three times a day.
Can we start manual and automate later?
Yes, and you should. Manual first tells you what your real rules are. Most operators discover their requirements were different from what they assumed.
Is a subscription tool really cheaper than building?
At small and medium scale, almost always, once you count maintenance rather than just the initial build. The comparison flips when your scale is large or your rules are genuinely unusual.
What is the single biggest risk?
Nobody owning it after launch. An unmaintained integration fails silently, and the failure surfaces as a locked-out customer rather than an error message.
Do we need special hardware for a custom integration?
Usually not, but confirm before buying. The constraint is more often credential storage limits and gateway coverage than the lock itself.
Altix supplies smart locks, gateways and deployment support for access projects across the UAE, and gives honest scoping advice even when the answer is do not build. Talk it through on WhatsApp.
