Buy or build a visitor management system?

Every few months someone asks us the same thing, usually after a quote has landed on their desk: should we just build this ourselves? It is a fair question. A visitor sign-in system looks like a form, a list and a badge printer. A competent developer could put that together in a fortnight.

We sell a visitor management system, so read the rest of this with that in mind. We are going to make the case for buying — but we are also going to be honest about the situations where building is the right call, because pretending they do not exist helps nobody.

The question is not really about money

Buy-versus-build gets framed as a budget comparison: licence fees on one side, developer days on the other. That comparison almost always flatters building, because it prices the first version and ignores the next five years.

The better question is: who is going to own this in year three? Not who writes it — who answers the phone when a tablet at the north gate stops printing badges the morning of an audit, and the person who built it left eighteen months ago.

What you are actually buying

The demo shows you sign-in. What you are paying for is the unglamorous tail behind it:

The evacuation list. A live roll call that is correct at the moment the alarm sounds, on a device someone can carry outside. This is the part that matters and the part that is hardest to get right, because it depends on sign-out being as reliable as sign-in.
Notifications that survive reality. Hosts who have left for the day, shared reception mailboxes, people who never read email but always read a text.
Hardware that moves on without you. Tablets get replaced, iPadOS changes how kiosk mode works, a badge printer model is discontinued and the replacement speaks a different dialect.
Data retention and privacy. Someone will eventually ask you to delete a specific person's history, and you will need to prove it happened. Retention rules, audit trails and export requests are all things you have to build deliberately.
Accessibility. A sign-in kiosk is a public terminal. Contrast, touch targets, text size and screen-reader behaviour are not optional extras.
Single sign-on and directory sync. The moment your host list has to match your staff list, you are integrating with an identity provider and keeping up with its changes.

None of that is hard, exactly. It is just endless, and none of it is your organisation's actual work.

What building actually costs

The honest cost of a built system is not the build. It is:

Ongoing maintenance — browsers, operating systems, dependencies and security patches, forever.
Key-person risk — the developer who understood it moves on, and their replacement inherits a system with no documentation and no other users to compare notes with.
Feature drift — every department wants one more field, and each one is a small change to a system nobody is being paid to look after.
The silent failure — a bought system that breaks gets a support ticket and a fix. A built one that quietly stops recording sign-outs can go unnoticed until the roll call is wrong.

For a standard front desk, buying wins on almost every axis. Not because bought software is better written, but because the cost of that tail is shared across every organisation using it instead of resting entirely on yours.

When building genuinely is the right call

There are real cases. If one of these describes you, a vendor is probably the wrong answer:

Your sign-in process is the regulated thing itself. Some sites have an induction, permit-to-work or competency workflow so specific to their regulator that bending a general product around it produces something worse than a purpose-built tool.
It has to drive physical equipment. Turnstiles, boom gates, lift controllers, existing access-control hardware with a proprietary protocol and no API worth the name.
It is part of your product. If you run venues or co-working space and arrival is the customer experience you sell, that experience is probably worth owning outright.
The data genuinely cannot leave. Defence, some health settings, air-gapped sites. Note the word "genuinely" — this gets claimed far more often than it is true, and most vendors have a sovereignty answer if you ask.
You have already tried three products and each failed on the same specific requirement. That is evidence, not impatience.

Notice what is not on that list: "we want it to look like our brand", "we need a custom field", "the pricing annoys us". Those are configuration questions, and if a product cannot answer them, try a different product before you write one.

If you are going to build, the hard part is who builds it

Here is where most custom projects actually go wrong. Not the decision — the hiring.

The usual approach is to ask the one developer you already know, or the agency that did your website, or whoever responds first. You get a single number with nothing to compare it against, from someone whose real specialism you have not verified. If that number is too high you have no way to know. If it is suspiciously low, you find out in month four.

What you want is three to five quotes from developers who have actually built something comparable, so you can see the spread and hear how differently they each describe the same problem. That conversation is worth more than the pricing — the way a developer scopes your evacuation requirement tells you immediately whether they have thought about it before.

If you are in New Zealand, 5Quotes is a straightforward way to do that: you describe the project in plain language, vetted developers ask permission to contact you, and you approve who gets through. Your contact details stay private until you say yes, introductions are capped at five so you are not buried in cold outreach, and it costs nothing as a buyer. Australian readers want 5Quotes Australia, which works the same way.

Two things we would look for whichever route you take. First, ask to see two projects you can actually open and use — not a logo wall. Second, ask each developer what they would not build, and who they think should own it in three years. The ones who answer that honestly are the ones worth talking to.

The middle path most organisations actually want

Buy-versus-build is rarely binary. The arrangement that works most often is: buy the platform, build the edge.

Take a product for the parts every site needs — sign-in, the live on-site list, evacuation, notifications, retention — and commission a developer for the specific thing that makes your site unusual. A bridge to your permit system. A panel on the wall of the control room. An overnight export into your own reporting.

That is a far smaller brief, which makes it cheaper to quote, faster to build and much easier to replace later. It is also a much better use of an independent developer's time than rebuilding a visitor book from scratch.

Common questions

Is it cheaper to build a visitor management system?

Usually only in year one. The build is the small part; maintenance, hardware churn, security patching and the loss of the person who wrote it are what make the total cost higher over any realistic lifespan. Compare five years, not the initial quote.

How long does a custom visitor management system take to build?

A basic sign-in and host-notification system is a few weeks. The parts that take real time are reliable sign-out, evacuation roll call, badge printing across mixed hardware, and identity integration — which is why most custom builds land at several months once the whole requirement is visible.

How do I find a developer for a custom build?

Get more than one quote, from developers who have built something comparable. Services like 5Quotes exist for exactly this: describe the project, compare up to five vetted developers, and choose who you speak to. Ask every one of them for two working projects you can open yourself.

Can I do both?

Yes, and most organisations should. Buy the platform for the common requirements and commission custom work only for the part that is genuinely specific to your site. Smaller brief, lower risk, easier to hand over.

Where we land

For the overwhelming majority of front desks, buying is the right answer, and we would say that even if we did not sell one — the tail of work behind a sign-in screen is longer than it looks, and it never ends.

But if your requirement really is specialist, do not let a product bend you into a worse process. Build it, and give the hiring as much thought as the build: get a handful of quotes, insist on seeing real work, and pick the developer who argues with your brief.