Two ways to approach
AR development
Neither approach is wrong — they suit different situations. This page lays out the differences honestly so you can decide what fits your project and where you are right now.
Back to homeAR projects fail in predictable ways
Most AR project difficulties trace back to the same cluster of decisions made early: scope set too ambitiously, device constraints underestimated, comfort and readability left to the end, costs that expand mid-build. These aren't failures of talent — they're structural patterns.
Understanding which approach is a better fit for your situation isn't about which is "better" in the abstract. It's about which matches your current knowledge, risk tolerance, team capacity, and the specific stage your project is at right now.
Traditional approach vs focused approach
Scope
Traditional
Broadly defined; expands as requirements emerge
Overlay
One deliverable, confirmed before starting
Pricing
Traditional
Estimates that frequently adjust mid-project
Overlay
Fixed, transparent price before work begins
Feasibility input
Traditional
After significant planning or build investment
Overlay
Available as a standalone first step
Device testing
Traditional
Controlled conditions; broad support later
Overlay
Real-world variable environments throughout
Decision ownership
Traditional
Momentum makes direction changes difficult
Overlay
Each service is self-contained; your choice always
The thinking behind the structure
Services that don't depend on each other
A concept review, a prototype build, and a comfort pass can be purchased in any order or in isolation. There's no required progression and no pressure to continue from one to the next.
Honest scope, not ambitious promises
We describe what each service actually covers, including what's out of scope. You won't find vague deliverables that leave room for disappointment. What's listed is what's delivered.
Early clarity is cheaper than late corrections
Understanding feasibility before building is the whole point of the concept review. The cost of early honest feedback is low. The cost of discovering fundamental problems after three months of build is not.
What each approach tends to produce
Traditional full-build approach
- Suitable for teams with strong AR experience and clear requirements
- Comprehensive but requires sustained investment before results are testable
- Difficult to course-correct once significant build work is underway
- Comfort and UX often reviewed last, when changes are most expensive
Focused service approach
- Works well for teams who want clarity before committing to a full build
- Smaller, faster cycles mean discoveries can be absorbed without large sunk costs
- Each deliverable is complete — you can pause, redirect, or continue at any point
- Comfort review available early, when adjustments are still straightforward
Where the value sits
$270
A full feasibility picture before any build investment. If it uncovers a structural issue, it has paid for itself many times over. If it confirms your approach, you proceed with confidence.
$740
A testable interaction, not a full system. The value is in having something real to evaluate and show — without needing months of development to get there.
$360
A careful second look at real-world usability. Finding readability or interaction problems before launch is considerably less costly than addressing negative feedback afterward.
Compared to the cost of discovering fundamental AR problems midway through a full build — which can run into several thousand dollars in rework and delay — these services are relatively contained investments. That said, we're not the right fit for every project; if you have a strong in-house AR team and clear requirements, a full-build approach may serve you better.
What the process actually feels like
Traditional engagement
Working with Overlay
AR experiences built carefully tend to hold up
The difference between AR that works reliably and AR that frustrates is usually not the feature set — it's the quality of decisions made in the planning and testing stages. Getting those early decisions right has compounding value as development continues.
A prototype that reveals a tracking problem early is worth considerably more than one that hides it. Comfort notes that catch readability issues before submission are less painful than one-star reviews that mention eye strain after launch.
Small, clear steps are easier to maintain direction through
One of the quieter benefits of a service-based approach is that it creates natural decision points. After a concept review, you have clear information. After a prototype, you have something testable. These checkpoints make it easier to stay aligned on direction without long periods of uncertainty.
Larger projects benefit from this too — not every AR feature needs a full upfront plan. A focused prototype for one interaction, evaluated carefully, can inform the rest of the build with minimal wasted effort.
A few things worth clarifying
"A focused approach means limited ambition"
Not necessarily. A well-executed prototype for one interaction is a foundation, not a ceiling. Many ambitious AR games are built on careful, incremental validation rather than large upfront builds. Focused doesn't mean small-minded.
"Concept reviews are just opinions"
A good concept review is grounded in device data, platform documentation, and practical experience with what actually causes problems in real conditions. It's not a gut feeling — it's a structured look at specific risk areas with specific findings.
"Comfort reviews are only relevant for accessibility"
Comfort affects everyone. Arm fatigue after ten minutes of play, difficulty reading text in afternoon sunlight, or interaction patterns that require awkward wrist angles — these are mainstream experience problems, not edge cases. Players don't label these as "comfort issues"; they just stop playing.
"Traditional build shops do all of this anyway"
Some do, and do it well. The difference is usually where in the project these concerns are addressed, and at what cost. In a full-build engagement, raising comfort concerns in month three of development is more disruptive than it would be in a dedicated review at any stage.
This approach suits you if…
You're early in exploring AR and want an honest picture before committing to a full build
You want a working prototype to evaluate internally or show to stakeholders without months of build time
Your team has built something and you want a careful independent review of how it reads and feels in real conditions
You prefer fixed costs and self-contained deliverables over estimates and ongoing engagements
You want to keep the decision of what comes next firmly with your team, not shaped by a vendor's interest in continued work
You value honest assessment over reassuring confirmation — even if the honest picture is more complicated
Still working out which approach fits?
Tell us where your project is and what you're trying to figure out. We'll give you a direct answer about whether we're the right people to help — and if not, what kind of support might suit you better.
Get in touch