How to Make an AR Furniture App: Step by Step

You have decided a shopper should be able to point a phone at their living room and see your sofa sitting there at its real size before they buy. Good instinct. The question now is not whether AR furniture works, it is how to build it without the project sprawling into a year of 3D modelling and two app stores. This guide walks the build process end to end, in the order a team that has shipped AR would actually follow.

The plan matters because an AR furniture app is really three projects wearing one coat: a 3D asset operation, an AR placement layer, and an ordinary shopping app. Each has its own traps. Get the order right and a small team can put a useful version in people's hands quickly. Get it wrong and the 3D work alone can swallow the budget. If you want the wider strategy and the branded angle, our pillar on how to build an app like IKEA Place covers that; this post stays on the build itself.

What does it take to make an AR furniture app?

It takes eight stages: scope, platform choice, the 3D model pipeline, placement, catalogue and backend, checkout, testing, and launch. The core loop is simple. A phone finds a flat surface, drops a correctly sized 3D model onto it, and holds it in place while the shopper walks around. Everything else in the build exists to feed that one moment and to turn a good look into a sale.

Here is the whole path on one page, then the map of what each stage involves and where teams slip.

The rest of this guide takes each stage in turn. A word on order: the 3D models set the pace of the whole project, so even though you scope and choose a platform first, you should start the model work early and in parallel.

Step 1: Scope the smallest useful version

Scope down hard before you write any code. The smallest useful version of an AR furniture app is one product, placed at real size, on one platform, that a shopper can share as a photo and then buy. That is enough to test whether people want it. Every extra product, platform and feature is cost you can add once the first version proves itself.

The most expensive mistake in this space is scoping against IKEA. IKEA Place launched with a catalogue built over years and thousands of models. A first version does not compete on catalogue size, it competes on doing one job well. Pick your best selling category, choose about ten hero products, and cut the rest for v1.

This is the honest version of "start small". A view in room feature on ten products tells you almost everything: do people place the item, do they keep it, do they share the photo, do they come back to buy. If they do, you have earned the budget for the full catalogue. If they do not, you have saved yourself a year. Our guide on how to turn an idea into an app covers this cut it down first habit in more general terms.

Step 2: Choose your platform

Choose between WebAR and a native app, and decide which phone systems to support. WebAR opens from a link in the browser with no download, so it reaches people fast and suits a first test. A native app gives smoother tracking, richer features and store presence, at a higher build cost. Many furniture brands start with a web view in room feature and add a native app later.

The trade offs run deeper than download or no download. We break the full decision down in WebAR versus a native AR app, but the short version is this. WebAR is limited by what the phone browser exposes to it and cannot always reach the deepest tracking features, while a native app can use the platform AR frameworks directly and store models on the device. If your goal is reach and speed, start on the web. If your goal is the smoothest possible experience and repeat use, native pays off.

On which systems, the two platform frameworks are Apple ARKit and Google ARCore, and they differ in device reach, tracking behaviour and setup. If you go native, read our comparison of ARKit versus ARCore before you commit, because the choice affects which phones your app runs on. The practical rule: support the system your buyers actually hold, and do not build two native apps before one has traction.

Step 3: Build the 3D model pipeline

This is the mountain. Every product a shopper can place in a room needs its own 3D model: modelled or captured, sized to real world dimensions, textured, exported in two formats, and compressed to open in seconds on a phone. Ten products is a project you can do by hand. A full catalogue is an operation you have to design, and it often drives most of the cost.

Each model has to exist in two forms because the phones disagree. Apple AR Quick Look, the built in viewer on iPhone and iPad, displays USDZ files and lets the user place them in AR. Android Scene Viewer previews and places glTF 2.0 and glb models. A model made for one will not open in the other, so a working catalogue keeps a USDZ and a glTF copy of every product. Our explainer on USDZ and glTF covers how the two formats relate and how to export both from one source.

Three technical choices decide whether the app feels fast or heavy:

• Polygon budget. A phone renders a model made of triangles. Too many and the app stutters or the file is huge. Furniture rarely needs film quality geometry, so you reduce the triangle count until the shape still reads at arm's length.
• Texture and file compression. Uncompressed models and textures balloon to tens of megabytes. Compressing geometry and images brings a model down to a few megabytes, which is the difference between a two second load and a shopper giving up.
• Model or buy. You can model each piece in software like Blender, capture real products with photogrammetry, or buy or reuse a supplier's existing CAD. Most catalogues end up a mix. The deeper how to is in our guide on how to make 3D models for an AR furniture app.

Plan this stage first even though it comes third in the build. The models gate everything: no model, no placement, no app. A team that leaves 3D to the end always slips.

Step 4: Make placement feel real

Placement is the moment the app either earns trust or loses it. The phone has to find the floor, drop the model where the shopper taps, hold it steady as they move, and show it at its true size. The platform frameworks do the heavy lifting here, but getting it to feel solid takes calibration and testing.

Underneath, the mechanism is consistent across platforms. ARCore, for example, tracks the phone by following visual feature points and detecting horizontal or vertical planes like floors and walls, then uses a hit test to work out where a tap lands in the room and an anchor to keep the object fixed there. ARKit works on the same ideas. When you tap the floor, the app casts a ray, finds the plane, and anchors the sofa to that spot in the world.

Two things separate a convincing app from a toy:

• Real scale. The model must appear at its true dimensions, so a two metre sofa reads as two metres in the room. This is what lets a shopper judge fit, and it is the single most valued feature. If scale drifts, the whole app loses credibility. Our guide on accurate AR measurements covers how scale is calibrated and where it fails.
• Occlusion and lighting. A sofa should be hidden by a real coffee table in front of it and lit to match the room. Depth based occlusion makes this work on capable phones. Without it, furniture floats over everything, which looks wrong the moment a real object crosses in front.

Placement degrades in the real world. Low light starves the camera of feature points, plain or shiny floors give it nothing to lock onto, and small cluttered rooms confuse plane detection. Some higher end iPhones and iPads add a LiDAR sensor that improves floor detection and occlusion, but you should not require it. Most of your users will not have it, so build for the standard camera and treat LiDAR as a bonus, as we explain in do you need LiDAR for an AR furniture app.

Step 5: Connect the catalogue and backend

Behind the AR view sits an ordinary product system. Each item needs its usual data, price, dimensions, description and stock, plus a link to its two 3D files. The backend maps every product to its USDZ and glTF models, serves those files quickly from a content delivery network, and keeps the AR catalogue in step with the products you actually sell.

The part teams underestimate is asset delivery. 3D files are large compared with product photos, and a shopper will not wait. Serving them from a CDN, compressing them properly, and loading only the model a shopper is about to view keeps the app quick. If you already run an online store, you usually keep it and add AR on top rather than rebuilding, which saves both time and money. Managing a growing model library is a real discipline, and the batch 2 guide on building a 3D model catalogue at scale goes into it.

Step 6: Add a way to buy

An AR view that cannot lead to a purchase is a demo, not a product. Give the shopper a clear next step from the moment the furniture looks right in their room: add to cart, or a link straight to that product's page in your existing store. For a first version, linking out to a shop you already run is faster and cheaper than building checkout inside the app.

Keep the path from "it fits" to "it is mine" short. The value of AR is that it removes the doubt that stops an online furniture sale, so the buy step should be right there when the doubt clears. If you run a full store already, treat AR as a new front door to it, not a reason to rebuild the plumbing. The way these apps actually earn their keep, from fewer returns to higher conversion, is covered in the batch 2 post on the best features of an AR furniture app.

Step 7: Test with mock rooms before launch

Test in the messy real world, not the office. Before any shopper sees the app, run it through a set of mock scenes: a dark room, a bright room, a plain wooden floor, a busy patterned rug, a tiny bedroom, a large open plan space. AR that behaves in a tidy showroom often falls apart on a real living room floor at night, and mock rooms surface those failures while you can still fix them.

This is a habit worth building into the schedule rather than saving for the end. On our own AR builds we keep a fixed list of test rooms and place the same three products in every one before every release, so a change that helps a bright room but breaks a dark one gets caught the same day. It is dull work. It is also the difference between a five star review and a one star "the sofa keeps sliding through the wall".

What to check in each mock room: does the floor get detected within a few seconds, does the model land at true scale, does it stay anchored when you walk around it, does it load fast, and does a real object crossing in front hide it correctly. Write down which rooms fail and fix the most common failure first. Getting an app from a working build to a stable public release is its own stage, and our notes on taking an app from a first build to production apply here too.

Step 8: Launch and iterate

Launch small and treat it as the start, not the finish. Ship your ten products on one platform, whether that is a WebAR link you can put behind a "view in your room" button or a native app in one store. Then watch what real users do: which products they place, where placement fails on their phones, how many go on to buy. Fix the biggest failure, add the next batch of products, and repeat.

The apps that win are the ones that keep tightening this loop. Each round you widen the catalogue, add the second platform if the numbers justify it, and smooth the placement problems that only real devices in real homes reveal. A first version is a question you are asking your customers. Launch lets them answer it.

What it costs to build one

Cost tracks three things: the number of 3D models, how many platforms you support, and whether you add in app checkout. The 3D catalogue is usually the largest single driver, which is why scoping to ten products first matters so much. appico builds mobile apps from about $12,000 and well scoped MVPs from about $10,000, with larger, catalogue heavy builds costing more.

Because cost deserves a proper breakdown rather than a single number, the full driver by driver guide lives in our post on the cost to build an AR furniture app. To sketch a rough budget for your own scope, our cost calculator is a quick starting point. If you would rather talk it through against a real spec, our team can help you plan and build the app from scope to launch.

When making an AR furniture app is not worth it

AR is not free value, and some products do not need it. It is not worth building when your items are small, cheap or standard enough that a shopper has no real fit or scale doubt to resolve. A phone case or a set of coasters gains nothing from being placed in a room. AR earns its cost on large, expensive, hard to return items, sofas, beds, wardrobes, dining tables, where a wrong size decision is painful for both sides.

It is also not worth it if you cannot commit to the 3D model operation. An app with five good models and a hundred products that only show as photos frustrates shoppers more than no AR at all. If you do not have the budget or the supplier CAD to build models for the range that matters, keep the plan small until you do. And if your catalogue changes weekly with short lived stock, the modelling may never catch up. Honest limits like these decide more AR projects than any technical detail.

Our take

Build the small version, put it in real hands, and let the results buy the rest. The technology is ready: phones can place furniture at true size well enough to remove the doubt that stops an online sale. The risk is never the AR, it is scope. Teams that try to match a giant catalogue and both platforms and full checkout on day one run out of budget in the 3D pipeline before they learn anything.

So scope to one job, model ten products properly, get placement and scale right, test on messy real rooms, and ship. If you want a partner who has built this loop before and will keep the scope honest, that is the custom app development work we do. You own the code, the models and the app from day one.

Frequently asked questions