Cost to Build an AR Furniture App in 2026: Complete Guide

You have decided an AR furniture app could earn its place. Now someone has asked the question that sets the budget: what will it cost. The honest answer is that an AR furniture app cost is not one number. It is a range, and the range is fixed by choices you make before a line of code is written.

Most cost articles on this topic either give you a flat figure or none at all. One well known post quotes a range so low it can only cover a demo. That is the trap. This guide is written by people who have shipped AR, so it shows you the whole iceberg: the drivers that move the number, a phase by phase split, the offshore rate reality, and the two line items that quotes tend to leave out.

What does it cost to build an AR furniture app?

Expect a range, not a figure. A small MVP on one platform with a handful of models is the low end. A full app on both platforms, with a large 3D catalogue, a backend and admin tools, sits far higher. At appico the published starting points are an MVP from $10,000, a mobile app from $12,000, and up to about $150,000 for a large build.

The spread is wide because two apps that both "let a shopper place furniture in their room" can be completely different projects underneath. One might show five sofas on iOS. Another might show ten thousand SKUs across iOS and Android, tied to live stock, with saved room layouts and a merchandising dashboard. Same sentence, very different builds. This is also why comparing it to what a standard web app costs only gets you so far: the 3D and device side changes the shape of the estimate.

What actually drives AR furniture app cost?

Six things drive the cost: the number of products you model in 3D, whether you build for one platform or both, how much depth and LiDAR the app uses, how tightly the catalogue syncs to live stock, the backend behind accounts and orders, and the upkeep after launch. The first of those, the 3D model count, usually moves the number most.

The number of SKUs is the biggest lever

This is the part every thin quote skips. The AR view is built once. But each product a shopper can place in their room needs its own 3D model, and each model has to be made, optimised to load fast on a phone, and exported in two formats. Apple's AR Quick Look requires the USDZ format on iPhone and iPad, while Android's Scene Viewer expects glTF or GLB. So most catalogues carry every item twice, once per ecosystem. (Apple AR Quick Look and the Google Scene Viewer docs confirm the formats.)

Ten models is a rounding error. A few hundred is a real cost. Tens of thousands, which is the scale a large retailer needs, becomes a production line that can rival the app itself in cost. This is why we treat the catalogue as its own workstream. If your range is large, read how to build a 3D model catalogue at scale and the detail on how the 3D models themselves get made before you sign off a number, because this line item alone can decide whether the project is worth doing.

One platform or both

Building for both iOS and Android is not simply double the work, but it is well more than single platform, and the extra sits mostly in testing. AR reads the real world through the camera and sensors, and behaviour changes across devices, lighting and rooms. Every supported phone needs real checks, not just a simulator pass.

Apple's AR hardware is more consistent, so many teams ship iOS first, prove the concept, then add Android. Google certifies Android devices for ARCore only after checks on camera, sensors, design and CPU, and the certified list is large and always changing (ARCore supported devices). That breadth is good for reach and harder for test coverage. If reach matters more than deep native features, WebAR instead of a native app can cover both from one build with no install, at the cost of some capability. The way ARKit and ARCore differ also feeds into which platform you lead with.

Depth, LiDAR and how far the AR goes

Placing a single sofa on the floor is the cheap end of AR. Costs climb as you add measurement, occlusion so a chair correctly hides behind a real table, and room scanning that captures a floor plan. Some of those features lean on a depth sensor. LiDAR, the scanner on higher end Apple devices, makes room capture faster and more accurate, but it only exists on Pro tier hardware.

That creates a choice with a price tag. Build LiDAR only features and you narrow your audience to the phones that have it. Support everyone and you build a fallback path as well, which is more work. For a place a single item flow, you often do not need it. Before you pay for depth features, decide whether you need LiDAR at all for your use case.

Catalogue sync, backend and accounts

A demo shows fixed models. A real store needs the AR catalogue tied to live stock, prices and variants, so a sofa that is out of stock or discontinued does not keep appearing in customers' rooms. That sync, plus user accounts, saved items, orders and an admin panel for your team, is a backend project sitting behind the AR view. It rarely shows up in a headline price, and it is often where a "simple AR app" quietly becomes a full product.

Upkeep after launch

The build is not the end of spending. Furniture ranges change every season, so new models keep coming. iOS and Android ship new versions that need testing and sometimes fixes. The backend and model delivery have hosting and usage costs. And real users find edge cases. This is ongoing, so appico handles it as a separate monthly maintenance plan rather than pretending a one off build fee covers the whole life of the app.

How the cost splits by phase

A build runs through five phases: scope and specs, the 3D model pipeline, the core app build, testing on real devices, then launch and upkeep. The model pipeline and testing are the two that most often stretch a budget, because they scale with your catalogue size and your device list rather than with the app's screens.

Here is the same picture as a table, with what moves each line and where appico's published starting points land. Only appico prices appear as numbers; the rest are drivers, because inventing a precise figure for your project would be dishonest.

A simple rule of thumb keeps you out of trouble. Multiply your ambition in three places, not one: the number of SKUs times the number of platforms times the depth of AR features. Push all three at once and the cost compounds fast. Hold two of them steady while you prove the third, and the budget stays predictable. Most first builds go wrong by maxing all three before a single customer has placed a chair in a room.

Read the table top to bottom and the shape of your own project appears. A single item viewer on one platform with a small catalogue sits near the MVP line. A full room planner across both platforms with a large catalogue and a merchandising backend climbs toward the upper end. A full room planner rather than a single item viewer is a larger build again, with its own drivers.

The US and UK versus India rate reality

The same scope costs very different amounts depending on who builds it. A US or UK agency carries higher local rates, so an identical feature set is priced well above what a senior offshore team charges for the same work. This is the single biggest reason two honest quotes for "the same app" can be far apart, and it is not about quality. It is about where the salaries are paid.

appico's position is a US, UK and global facing brand with a senior India build team, sold as fixed scope with transparent pricing, and you own the source code, accounts and models from day one. That combination is how the number stays sensible without cutting the engineering that AR actually needs. If you are still shaping the concept, our guide on how to turn an idea into a scoped app helps you get to a spec a team can price.

appico's published starting points

These are the only prices in this guide, and they are appico's own published starting points. We do not print competitor ranges, because we cannot verify them and inventing them would break the one rule that makes an estimate useful.

• Marketing website, from $1,000. If the AR sits on the web, or you need a product site alongside the app.
• MVP, from $10,000. One platform, one clear flow, a small test catalogue. Built to prove customers use AR before you fund the full thing.
• Mobile app, from $12,000. A shippable native app, with the final number set by platforms, catalogue size and how deep the AR features go.
• Large build, up to about $150,000. Big catalogue pipeline, both platforms, backend, admin, integrations and roles.
• Maintenance, a separate monthly plan. New models, OS updates, hosting and fixes, priced apart from the build.

For a rough self serve estimate before you talk to anyone, the cost calculator gives a starting figure you can sanity check against the drivers above.

When an AR furniture app is not worth it

Building is not always the right call, and no incumbent article will tell you that. An AR furniture app is hard to justify when your range is tiny, when your products are low value so a wrong purchase is cheap to return anyway, or when you cannot commit to keeping the 3D catalogue current. AR that shows last season's stock is worse than no AR.

It is also the wrong first spend if your basics are missing. If shoppers cannot find products, check out cleanly, or trust the site, AR will not fix that, and the money is better spent elsewhere first. The catalogue moat is real too: a giant like IKEA carries tens of thousands of models, and matching that is a serious operation, not a weekend of modelling. Know what you are taking on before you commit. For the full picture of a flagship build, see our pillar guide on building a full AR furniture app like IKEA Place.

Our take

The cost of an AR furniture app is decided long before development, in three questions: how many products, how many platforms, and how far the AR goes. Answer those honestly and the number stops being a mystery. Answer them with wishful thinking and you get the low quote that cannot ship.

Start narrow. One platform, a small catalogue, a single clear flow, and prove that customers actually place items in their rooms. Then spend on the catalogue and the second platform once the demand is real. If you want that first number scoped properly, our app development team can price a fixed scope build, and you can scope an AR build with us without a sales script attached.

Frequently asked questions