Ar-range was never planned as a single project. We built it over seven years, on our own account, one live catalogue at a time. Rendering and automation came first. They led to a catalogue engine, and the configurator was built to read from it. Each piece was added when a live catalogue showed us it was missing.
Built that way, the platform never had a budget for the whole of it. So I was curious what it would cost to build Ar-range today, from scratch, as a one-off venture: a production-grade copy built by a software house in Poland, and again by one in New York. The scope covers Content Hub, variant visuals, the modular configurator, AI search, fabric digitisation, AR, showroom tools and integrations. That is the whole platform. A project applying Ar-range to one brand’s catalogue has a different scope and budget.
For a furniture manufacturer considering its own configurator, the same exercise answers a practical question: what would it need to own behind the interface? Product records, valid combinations, material visuals and the connection to the shop all need somewhere to live, and someone responsible for keeping them working.
The platform, priced as a one-off build
Here is roughly how it breaks down. The ranges are there to discuss scope. No software house has quoted them, they do not record what we spent, and nobody should read them as a minimum budget.
| Component | Poland, software house |
|---|---|
| Content Hub, the catalogue engine | EUR 150k to 220k |
| Variant and rules engine | EUR 100k to 160k |
| 3D and automated rendering pipeline | EUR 180k to 300k |
| Modular 3D configurator | EUR 120k to 180k |
| AI search | EUR 50k to 100k |
| Fabric and material digitisation | EUR 60k to 120k |
| AR | EUR 50k to 100k |
| Showroom, POS and deal pages | EUR 70k to 120k |
| ERP, PIM and ecommerce integrations | EUR 80k to 150k |
| Cloud, security, QA, DevOps | EUR 100k to 150k |
| Total | about EUR 960k to 1.6M |
In New York the same scope comes to roughly USD 2M to 3.5M. Either way it is 18 to 24 months of work, with a team of 8 to 14 people in Poland or 10 to 18 in New York.
The line for cloud, security, QA and DevOps raises a question any real budget has to answer: what belongs to the build, and what continues after launch? Hosting, rendering, support and maintenance carry on long after the last feature ships, and a usable budget separates the two.
Where the money would go
The rendering pipeline deserves its own budget. Getting a scene to render velvet that looks like velvet, at catalogue scale, on a queue that does not fall over, takes work across materials, modelling and software. In our experience, the visual pipeline needs to be proved on the client’s products early. A working interface cannot tell you whether the upholstery will look convincing.
The product schema, rules engine and compositing pipeline carry much of the accumulated knowledge. They determine what a brand can sell, which options combine and which images need to exist. The configurator depends on those decisions.
Prove the catalogue and visual engine before committing to the full interface. For a platform with this scope, we would start with a representative set of real products, their rules and their hardest materials. That gives the interface something reliable to work with and exposes gaps while the project is still small.
What a one-off budget leaves out
A feature list leaves discovery work unresolved. We started without an investor or a complete specification, and part of the investment went into rewrites and approaches we abandoned. A software house can budget for discovery, prototypes and iteration, but a list of finished features does not tell it how much of that work remains. What we spent over seven years says little about today’s price either.
The important requirements are often inside the small decisions. Can the chosen visual approach show chenille at the required fidelity and load quickly on the buyer’s phone? Should two size options share a cached image when they do not change the visible upholstery? Which questions does a buyer ask a salesperson before ordering a bed? A rebuild needs answers to those questions, and a way to test them. We learned ours one live site at a time.
Headcount does not describe a team’s readiness. The table assumes a team can be assembled to cover software, 3D and rendering. Our senior developers had been working together since 2007, on banking systems, before the first sofa. The 3D side, modelling, photogrammetry, physically accurate materials and ray-traced rendering, was a practice before it was a business. A new team’s budget needs to account for learning the catalogue and learning to work together. Continuity is cheaper than headcount, and it does not appear in a day rate.
What this means if you are buying
When you buy an Ar-range implementation, the scope is applying an existing platform to your catalogue: preparing the product data and assets, configuring the experience and connecting it to your shop. What your project produces, your models, your renders, your catalogue records, is yours, and it stays yours.
The MyBed project is the clearest example of what that looks like from the client’s side: 120 bed configurators and 2.2 million visuals, with the rendering done in five days inside a project of about two months. The five days are the visible part. The years underneath them are why five days were enough.
For what a project actually costs, and which parts of your catalogue move the total, Łukasz has written the arithmetic out, and why the cheapest vendor is rarely the cheapest project.
What this means if you are thinking of building it yourself
Some brands should. Owning the pipeline can make sense when it supports a lasting business requirement and the manufacturer is prepared to fund a team beyond launch. Before choosing, work through these questions:
- Which capabilities do you need to own? A catalogue with fixed fabric and size variants may need a different visual approach from a modular system with many possible layouts. AI search, AR and showroom tools each need their own business case.
- What can your current systems already do? Map where product records, rules, prices and assets live, then identify the missing capabilities and the integrations required.
- Who will maintain the system after launch? Assign responsibility for catalogue changes, material quality, rendering failures, security updates and changes to the shop or ERP. Include that work in the budget.
- What would prove the approach works? Test representative products, difficult materials, invalid combinations and the path from a saved configuration to an order before committing to a full rollout.
Building becomes a stronger option when control over those capabilities is central to the business and there is a team to maintain them. Buying becomes a stronger option when an existing platform meets the requirements and the brand wants to focus its resources on its catalogue and sales. Either decision needs a defined scope and an operating budget.
The table is a starting point for that scope discussion. A credible rebuild budget would follow a tested slice of the catalogue, explicit acceptance criteria and a delivery plan. Seven years of building Ar-range taught us which questions to ask before putting a price beside a feature.
