FAST BUILDS
Prove the idea before you commit to the full build.
Bring the problem, the people who will use it and the decision the build has to support. Within a fortnight it is in their hands, and the decision gets made on something real.
Rapid prototype: for a tightly scoped idea, the first working version is ready to hand to someone.
Full build: an estimate for a typical project. Complexity decides, and work that keeps going runs longer.
Tell us what you're working on.
WHAT WE BUILD
Every kind of build, in your hands within a fortnight
Each one starts as a working prototype, not a proposal. Pick the kind of build closest to your problem, and the first version is with the people who need it before the month is out.
Try the browser demos to see what a finished one feels like: a hand-tracked game, a full-body gesture wall, an AR business card and a 360 environment viewer.
WEB
A page people can use by Friday.
Landing pages, portals and small tools that prove an idea in a browser before anyone commits to the full build.
See web builds
MOBILE
The build in someone's hand.
iOS and Android apps, mobile web and AR experiences that open on the phone already in the pocket, tested in the workshop, waiting room or classroom they are for.
See mobile builds
GAMES
Play the rules instead of reading them.
Playable prototypes that make a mechanic, a score and a decision real in days.
See game builds
AI
A conversation that answers back.
Assistants, digital twins and practice partners built on approved material and tried by real users in week one.
See AI builds
XR
A room you can stand in.
Headset scenes and spatial interfaces blocked out and walked through before production begins.
See XR builds
360
A place you can look around.
Panoramic scenes for a browser tab or a headset: a ward, a depot, a street, so someone stands in the room before the room exists.
See 360 builds
EVENTS
Something a crowd can walk up and use.
Stands, stages and foyers get an experience people queue for: a headset moment, a screen they can drive, a game with a leaderboard, tested on the floor it will run on.
See event builds
CUSTOM
The build nobody has a template for.
A one-off problem, a working answer inside a fortnight, one slice cut all the way through so the decision is made on something real.
See custom builds
COMPUTER VISION
A camera that answers what it sees.
Pose and movement tracking, visual review, camera-based interaction and hand tracking in a headset, tried by real people in the real room.
See computer vision buildsTALK TO THE TEAM
Schedule an intro call with our team
Thirty minutes with Simon to scope the build, the timeline and who needs to be in the room.
Carked It!, built the Fast Builds way
PTR’s founders, Simon Lowe and Leonie Sanderson, made Carked It!, a card game about life, death and beyond, through their company The Ageing Revolution.
It was played with real people, rewritten from their notes, then put on sale.
What a fortnight of building looks like
Three builds on the go at once, each at a different stage. A prototype is judged beside the others on the table, which is how the good ones get picked.
HOW A BUILD HAPPENS
What happens in a build, and in what order?
Brief, build, test, refine, ship. Scroll through a fortnight the way a customer lives it: each step takes the whole screen, with the room it happens in behind the word.
- BRIEF
- BUILD
- TEST
- REFINE
- SHIP
01 of 05
BRIEF
Day one
You bring the problem, the people who will use it and the decision it has to support. Together we write the one-page brief and agree what a working version has to do.
02 of 05
BUILD
Days two to ten
The brief becomes something that runs: a page, a phone screen, a scene or a conversation you can hand to someone.
03 of 05
TEST
End of week two
The build goes to the people it is for. We watch what they do with it, not what they say about it.
04 of 05
REFINE
The week after
What people struggled with gets rebuilt and what they ignored gets cut. Every change traces back to something we saw in the test.
05 of 05
SHIP
Around eight weeks for a full build, depending on complexity
The build goes live where it will be used, with the people who tested it already knowing their way around it.
HALFWAY, AND FINISHED
A build looks unfinished right up until it is not
In the middle of a fortnight the work is still in pieces on purpose. At the end it stops moving, because your own people have run it and it held.
Week one is meant to look like this
Parts arrive out of order, get tried in front of people and get thrown away. What a client is buying in that week is the speed of being wrong early, because every version that does not work rules something out.
Then it stops changing, and that is the signal
The version that ships is the one that stopped needing edits because the people it is for kept using it anyway. From there the decision gets made on the build itself, not on a proposal about one.
WHAT WORKING WITH US LOOKS LIKE
Your first fortnight, and what you walk away with
You do not need a specification, a supplier panel or a quarter of lead time. You need the problem, the people who live with it and the decision the build has to support. What happens next, in the order it happens.
DAY ONE
You bring the problem. We write the brief together.
One meeting. You describe the situation, who has to deal with it and what a good outcome looks like. We turn that into a one-page brief: what the build has to prove, who will use it, and what "working" means.
No specification to write first. If you can describe the moment that goes wrong, we can start.
DAYS TWO TO TEN
Something you can hold, not something you have to imagine.
A web page you can open, a phone build you can hand to a colleague, a scene you can stand in or a conversation that answers back. The first working version exists before the second week starts.
You see it as it grows, not at the end.
"It's kind of like being in a big prototyping sandpit. We're also really lucky that the extended reality (XR) community in Australia is so advanced and supportive."
Leonie Sanderson
Co-founder, People Tech Revolution, on building from Australia. Startup Spotlight, Aerospace Xelerated, 2023
END OF WEEK TWO
Your people use it while we watch.
The build goes in front of the people it is for: staff, students, customers, a room at an event. We watch what they do with it, not what they say about it, and write down what stops them.
You get the findings the same day, in plain language, with the build still in your hands.
THE WEEK AFTER
We rebuild what people struggled with and cut what they ignored.
Every change traces back to something we saw in the test. You approve the list, we ship the changes, and the next test runs against the new version.
No surprises and no scope drift: the brief and the test notes decide what gets built.
AROUND EIGHT WEEKS
It ships where it will be used.
A browser tab, an app store, a headset library or a stand at an event. The accessibility check happens before launch, and the people who tested it already know their way around.
The full build lands inside eight working weeks, with the prototype still doing its job while the rest is finished.
WHAT CHANGES FOR YOU
Decisions get made on a working build, not on a proposal about one.
Fewer meetings about the idea and more time with the thing itself. The people who will run it have already used it. The budget conversation happens with evidence on the table.
If the idea does not hold up, you find out in a fortnight for the cost of a prototype, not at the end of a full build.
What you leave with
Not a deck, not a proposal, not a quote for a quarter of work: a working build your own people have already used, and a clear answer on whether to go further.
Leave with a working build, not a deck.
Two weeks in, you have something to hand a colleague, open on a phone, or put in front of a customer. Decisions get made on the build, not on a slide about it.
Phones and tablets, tried where they will be used
A waiting room, a classroom, an office, a trail. The build is only tested once it has been used there.
FULL SCALE, FIRST
Stand inside it before anyone cuts material
Walk the kitchen before the joiner starts. Stand on the stage set before a flat is built. Turn the speaker enclosure over before it prints. At full scale a wrong dimension shows in a minute, and it is fixed by hand.
HOW WE BUILD
Built in the engines the work needs
PTR builds in Unity and Unreal Engine for VR, AR and MR, WebXR for experiences that open in a browser, native mobile for the phone in the pocket, and modern web and AI stacks for everything around them. The device and the room decide the engine.
Questions buyers ask
What do buyers ask before a fast build?
Short answers, each with a link to the full answer.
What can a prototype prove?
A tightly scoped idea becomes a working version someone can use: a page, a phone screen, a scene or a conversation. The brief names who it is for, what they must be able to do and what would count as proof, and the decision is made on what people did with it. Rapid custom builds covers the shapes it takes.
What do we need to bring?
The problem, the people who will use it and the decision the build has to support. The brief also names what cannot change: the devices in the room, the systems it has to talk to and the date it is needed by. There is no specification to write beforehand. Rapid custom builds covers what you bring and what you get.
Who owns what at the end of a build?
PTR’s published Terms of Service say you retain rights in content you provide, and PTR and its licensors own the services, software, designs, documentation, brands and underlying technology; third-party assets remain subject to their licences. Enterprise terms, order forms or signed agreements control where they conflict, and ownership sits in the agreement for each build. Read the Terms of Service.
What happens after launch?
Testing and deployment prepare a build for its platforms, with analytics and support included, and ongoing support lets it evolve after launch as its owner learns what people do with it. The accessibility check happens before launch. Our approach covers each stage, from discovery and co-design to ongoing support.
Can a fast build be VR, AR or MR?
PTR builds in Unity and Unreal Engine for VR, AR and MR, and in WebXR for experiences that open in a browser. Headset scenes and spatial interfaces are blocked out and walked through by the people who will use them before production begins. XR builds walks through how a build runs.
Can people use it without installing anything?
Web builds open from a link on desktop or mobile with no download, and WebXR opens a scene in a browser without an install. The PTR Labs demos show what that feels like: a hand-tracked game, a full-body gesture wall, an AR business card and a 360 environment viewer. Web experiences covers browser builds.
Is a fast build right for every problem?
A fast build trades some scope for speed, so it suits a well-defined problem. When the brief is still being worked out, or the build has to integrate closely with existing systems and content, a longer engagement with more co-design is the better fit. Rapid custom builds covers the difference.
Bring us the brief. See what a fortnight does with it.
WHERE NEXT
Start with the build closest to your problem.
Each page shows what the build is, what it costs to get wrong, and what the first working version looks like in your hands.
