Why the technology question is the wrong place to start

This article works through the product lifecycle, from design to service, and for each stage describes what actually helps, what it requires, and how you know it's working.

A product configurator, an AR application and VR training are different applications, but they can all be built on the same central foundation: a cleanly prepared product dataset. The effort isn't in the application — it's in the foundation. Get that right once, and you can have all three.

The reverse is also true: start with the application, and you rebuild the foundation every single time. That's the most common reason a company's second project ends up costing as much as its first — and why nobody signs off on a third attempt after two.

The foundation: a prepared product dataset

What 'preparation' actually means

Your engineering department holds CAD data. It describes the product completely and precisely — but for manufacturing. In that form, it's unusable for presentation and explanation: it contains millions of surfaces, standard parts, tolerances, design history and internal geometry nobody needs to see. Full engineering data generally isn't optimised to run smoothly in a browser — and no salesperson can work with it as it stands.

Preparation means reducing the data without losing what it needs to say. In practice, the data is broken down into sensible, named assemblies, cut down to a displayable number of surfaces, given materials and finishes, enriched with motion (what opens, what rotates, what extends), and supplemented with the information needed in conversation.

This is hands-on work with tool support, and it's the line item most people underestimate when planning. It's also the one that pays for itself.

Why this is the real investment

Once the dataset has been prepared, the web presentation, the configurator, the AR view, the trade show exhibit, the training module and the service instructions can all be built from it. Once this foundation exists, it can be reused for further applications, which often cuts the effort for each additional use case considerably.

That has an uncomfortable consequence for project planning: the first use case carries the cost of all the ones that follow. Calculate only the first, and the numbers look bad. Calculate all six but only implement one, and you've fooled yourself. An honest calculation names upfront which use cases are actually coming, and in what order.

The six stages

1 · Design and development

What happens there: variants are locked in, installation situations are checked, approvals are obtained. It's not just design engineers involved — manufacturing, procurement, quality assurance and often the customer are too.

Where it goes wrong: some of the people involved can't read a technical drawing. They sign off without seeing the consequences, and the objection surfaces at pre-series stage, when changes are expensive.

What helps: an interactive model that runs in the browser and requires no CAD knowledge whatsoever. Collisions, maintenance access and installation dimensions can then be judged by non-engineers too.

Format: a web-based 3D model, supplemented with a 1:1 scale AR view for spatial questions.

How you'll notice the effect: objections come earlier. At first that feels like more discussion — and it's the cheapest discussion you'll ever have.

2 · Marketing and communications

What happens there: product images, data sheets, catalogues, the website, campaign material, trade show graphics — in several languages and for several variants.

Where it goes wrong: imagery is shot on the physical product. That means it doesn't exist until the product does, it shows exactly one configuration, and every further variant costs a new photoshoot. For products built to customer order, there's often no presentable unit at all.

What helps: renderings from the prepared dataset. Every variant, every colour, every cutaway, every angle — before the product has even been built.

Format: a rendering pipeline built on the web 3D model. Automated for high variant counts.

How you'll notice the effect: a new product's market launch begins months earlier, because communications no longer has to wait for the first production unit.

3 · Sales and advisory

What happens there: initial meeting, needs assessment, variant selection, proposal, renegotiation.

Where it goes wrong: sales staff explain a product the other side can't see, using documents written for experts. Misunderstandings about variants lead to wrongly configured quotes and correction loops.

What helps: a tool that runs in the meeting and shows exactly the variant being discussed. Usability matters more here than the underlying technology: it has to work without training, without an internet connection, and without preparation.

Format: a web 3D model, or a configurator for high variant counts that hands the structured selection straight over to quoting.

How you'll notice the effect: fewer rounds of proposals. That's the easiest figure to measure in this whole field, because it's sitting right there in your CRM.

4 · Trade shows, showrooms and live communication

What happens there: creating attention, opening conversations, showing the product.

Where it goes wrong: what gets shown is a function of what could be transported. Large systems appear as a fragment; software doesn't appear at all.

What helps: put the whole thing next to the fragment. Via AR, the installation appears true to scale in the room; via VR, an environment becomes walkable that could never exist on the stand — a driver's cab, a tunnel, a production line.

Format: AR for scale and fit, VR for environments. Both built on the same dataset.

How you'll notice the effect: the stand gets smaller, or the conversation gets longer — usually both.

5 · Training and qualification

What happens there: onboarding, product training for sales and service, customer training.

Where it goes wrong: practice happens on the actual plant. That means it stands idle for it, can be damaged, isn't always available, and only shows the normal case — not the fault case that training is really about.

What helps: a model on which procedures can be run through, fault scenarios included. Especially valuable where staff are scarce and onboarding time translates directly into cost.

Format: interactive 3D training in the browser for procedures and context; VR when spatial orientation and hands-on actions need practising.

How you'll notice the effect: time to first independent work shortens, and the plant stands idle less often for training purposes.

6 · Service and maintenance

What happens there: maintenance, fault clearance, spare parts identification — often under time pressure, often with rotating staff, often on plant that no longer matches the as-delivered state.

Where it goes wrong: the knowledge sits in a manual written for the normal state. Anyone seeing a piece of plant for the first time can't find the right bolt.

What helps: instructions overlaid on the real component for the technician, step by step, in the right order. If needed, with a colleague back at head office seeing exactly the same view.

Format: AR on a tablet, MR on a headset when hands need to stay free.

How you'll notice the effect: fewer callbacks from the field, fewer repeat visits, shorter time on site.

Where artificial intelligence genuinely adds value — and where it doesn't

The term gets used loosely in this field. Three distinctions keep the discussion honest:

Automation is not AI. A pipeline that automatically renders images for 240 variants from a dataset follows rules. It saves considerable time, and it's still not artificial intelligence. A product configurator is also rule-based: it knows combination rules, it doesn't make decisions.

AI with sign-off is the realistic high-volume case. Product descriptions for hundreds of variants, translations, summaries of technical documentation for different audiences: here a model generates suggestions, and a subject-matter expert approves them. With proper expert review, this approach can be applied sensibly to many use cases today.

Agentic is a different bar entirely — it means recognising intent. An application is agentic when it works out what the other person actually needs, chooses content and the next step accordingly, explains context, and even says when a variant is the wrong one for this case. That's a considerably higher bar than 'interactive', and most applications labelled this way don't clear it.

In practice, that means AI in this field today is mainly a production topic, not an experience topic. The value shows up where variants, languages and formats need to be handled at scale.

What order to start in

Three principles that have proven themselves in practice:

Start where it measurably hurts. Not with the use case that looks most impactful on paper, but with the one whose cost you already know today. If you can name your number of proposal rounds or the cost of your sample pieces, you already have your business case.

Build the foundation for more than you'll implement first. The preparation should be designed from the start so the other use cases can be served from it, even if you only implement one to begin with. The extra cost for that is small; retrofitting it later is expensive.

Take one component, not the whole portfolio. A single, real component that lets you play the whole route through end to end tells you more than a concept study of the entire product range — and it gives you something you can actually show around the building.

The most common mistakes

The application gets built before the question is settled. You can spot it because a technology shows up in the project name.

Data preparation is planned as an afterthought. It's the main line item. Underestimate it and the project ends up either more expensive or less accurate.

Only one use case gets served, but all six get costed. That comes back to bite you on the second project, when the promised scale effect fails to appear because the foundation wasn't built for it.

The tool is built for head office, not the field. Anything that needs training, an internet connection or preparation simply doesn't get used in a customer meeting.

Upkeep is never settled. Products change. If nobody's assigned to update the model, two years later you're left with an application showing a variant that no longer exists. That's worse than having no application at all.

Quick answers

Where do you start on a small budget? With a prepared model of a single, relevant component, deployed in sales. It's the use case with the shortest distance between effort and measurable impact.

How long does a model like this last? As long as the product doesn't change. When it does, the dataset gets updated — a far smaller job than the initial build, provided the preparation was cleanly structured in the first place.

Who in the company should drive this? The most robust setup is a combination: marketing or sales brings the occasion, engineering brings the data, management brings the decision. A project sitting in only one of these three corners tends to stall.

Do we need dedicated staff for this? Not for operation — but upkeep needs a named owner. What upkeep really needs, above all, is clearly assigned responsibility. The actual effort depends on the scope of the product range and how often it changes.

If you'd like to work out where in the product lifecycle 3D, AR, VR or AI could create real value, we're happy to look together at your starting point, existing product data and possible use cases. Feel free to arrange a no-obligation first conversation at info@hello-flame.com.