← Blog Comparisons

Building Your Own Indoor Wayfinding vs. Buying QRCodeMaps: The Honest Numbers

Most engineering-led organizations eventually ask the same question: should we just build our own indoor wayfinding instead of paying for SaaS? It is a fair question. We work with teams who have shipped real software and know that "a few floor plans with QR codes" sounds like a weekend project. The numbers tell a different story. Here is an honest breakdown of what an in-house build actually costs, against what a SaaS plan from $99/month already delivers.

Why teams consider building it themselves

There are usually three motivations for going in-house. First, existing engineering capacity — a team that already ships product is reluctant to bring in another vendor. Second, control — concerns about branding, data ownership, and integration with internal systems like room booking, visitor management, or a patient portal. Third, the deceptively simple surface area — floor plan image, a few markers, a QR code generator, and a mobile-friendly map. How hard could it be?

These are all legitimate motivations. The branding and integration arguments in particular are real, and we will come back to them. The "how hard could it be" instinct is the one that gets teams in trouble.

What building it actually means

A production-grade indoor wayfinding system is not one feature. It is a stack of features that have to work together on every phone made in the last eight years. At minimum:

Floor plan editor — drag-and-drop placement, snap-to-grid, scale calibration, multi-floor linking. Marker CRUD with categories, icons, search keywords, and accessibility metadata. A search index that handles typos, synonyms, and partial matches (a visitor types "toilet" but the marker is "restroom"). Multi-floor rendering with smooth pan and zoom on mobile Safari. QR code generation with redirect-safe short links. Mobile-browser performance budget under 2 seconds on a mid-tier Android. Screen-reader compatibility and WCAG color contrast. Analytics on scans, searches, and zero-result queries. Multi-language support if your visitors are not all in one country.

Independent benchmarks from indoor-navigation app studios (Volpis, LetsNurture) put a production SDK build at roughly 1.5 to 2 years and 7,000 to 13,000 engineering hours. Even a stripped-down AR-style nav app starts around $12,000 to $15,000 for a basic prototype. None of those numbers include ongoing maintenance.

The dev-cost numbers

For a build that matches what an established SaaS already offers, expect $50,000 to $150,000 in initial development, plus $1,000 to $3,000 per month in ongoing hosting, mobile updates, accessibility audits, and security patches. This aligns with the figures we have published elsewhere for custom mobile wayfinding apps — a basic wayfinding app starts around $50,000 to $100,000 with months of development and ongoing app store management.

A QRCodeMaps plan starts at $99/month and is live the same afternoon. For the first-year cost of a custom build you could run QRCodeMaps for somewhere between 40 and 125 years.

The build math is even worse if you only need wayfinding for one or two venues. A custom system has to amortize its development cost across every property that uses it. SaaS amortizes across thousands of customers — that is the entire point of the SaaS model.

The maintenance tax nobody budgets

The dev cost is the easy number to estimate. The maintenance tax is the one that surprises every team that has built internal tooling before.

Mobile browsers change constantly. Safari ships a quirk that breaks pinch-zoom on SVG floor plans. Chrome on Android changes how the file picker behaves for image uploads. Both of these have happened in the past 18 months and required vendor patches. An in-house team has to notice, diagnose, and patch each one — usually while working on something else.

Then there is QR scanning behavior, which varies across iOS Camera, Android Camera, Samsung Camera, third-party readers, and the WeChat-style scan-from-photo flow. PWA installability rules change across iOS releases. Accessibility audits get tighter every year. The marker editor needs UX iteration based on actual operator behavior — the first version always feels wrong to whoever is placing 200 markers on a hospital floor plan.

SaaS absorbs all of this. The vendor patches Safari quirks, ships marker-editor improvements, and runs accessibility audits as part of the subscription. In-house teams re-discover each one, then schedule the fix behind whatever else the team is shipping.

Time-to-value

QRCodeMaps is live the same day. Upload a floor plan, drop markers, print QR codes, and visitors can scan that afternoon. Free trial available.

A custom build looks like this: month 1, requirements and architecture. Month 6, internal beta with one building. Month 12, v1.0 across the portfolio. Month 18, feature parity with what SaaS already had on day one (search, analytics, multi-floor, accessibility). Month 24, the team that built it has moved on, and the next engineer to inherit it discovers there are no tests.

For most organizations, the eight to twenty-four month gap between "we decided to build it" and "visitors can actually use it" is itself a cost. It is staff hours spent giving directions, missed appointments, frustrated visitors, and a problem that stays unsolved while engineering catches up.

When building actually makes sense

Building in-house makes sense in two cases. First, wayfinding is a sub-feature of a much larger product you are already shipping — a hospital patient portal, an enterprise workplace app, a stadium fan experience. The marginal cost of adding wayfinding to an existing app is much smaller than building it as a standalone project, and the integration is tighter.

Second, you have a regulatory or sovereignty constraint that prevents using third-party SaaS at all — for example, a classified government facility where no external map data may leave the network. These cases are rare but real.

For everyone else — hotels, mid-sized hospitals, campuses, offices, mid-sized malls, warehouses, conference centers — the build economics do not work. Use the engineering hours on something that is actually differentiating for your business. Let a web-based wayfinding SaaS do the boring infrastructure work.