--- title: "Fast Builds: prove the idea before you commit to the build" description: "Bring the problem and the people who will use it. Fast Builds puts a working prototype in their hands within a fortnight, so the decision rests on evidence." canonical: https://peopletechrevolution.com/fast-builds --- 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. 2 business days Rapid prototype: for a tightly scoped idea, the first working version is ready to hand to someone. Around 8 weeks Full build: an estimate for a typical project. Complexity decides, and work that keeps going runs longer. 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](https://labs.peopletechrevolution.com/play) 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](https://peopletechrevolution.com/fast-builds/web-experiences) [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](https://peopletechrevolution.com/fast-builds/mobile-experiences) [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](https://peopletechrevolution.com/fast-builds/games-interactive) [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](https://peopletechrevolution.com/ai) [XR A room you can stand in. Headset scenes and spatial interfaces blocked out and walked through before production begins. See XR builds](https://peopletechrevolution.com/fast-builds/xr-ar-mr-vr-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](https://peopletechrevolution.com/fast-builds/360-experiences) [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](https://peopletechrevolution.com/fast-builds/event-experiences-activations) [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](https://peopletechrevolution.com/fast-builds/rapid-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 builds](https://peopletechrevolution.com/fast-builds/computer-vision) TALK 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. [Schedule an Intro Call](https://calendly.com/simon-ptrvr/30min?utm_content=fastbuilds-carkedit) Contact form [The Carked It! box and its decks.](https://peopletechrevolution.com/fast-builds/games/carked-it) ### 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. [The Carked It! story](https://peopletechrevolution.com/fast-builds/games/carked-it) ### 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. Immersive prototype build: putting on a VR headset Interactive XR prototype, a reflection mirrored back at its wearer Hospital training scenario, working build in motion 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. A build still coming together. ### 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. The same build, finished and still. ### 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. The brief, written with you on day one. 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. A working version, handed over, not presented. 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](https://medium.com/aeroxelerated/spotlight-people-tech-revolution-62d11e4ae535) Feedback sorted into the next round of work. 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](https://peopletechrevolution.com/fast-builds/event-experiences-activations). 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. A review of what the test showed. 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. Checked with the people who need it most. 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. The handover to the people who tested it. 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. The handover: a build in someone else's hand. ## 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. [Talk to us about a build](https://peopletechrevolution.com/talk-to-us) ## 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. The tablet check-in, tried in the waiting room. The classroom map, tested from a student's desk. The office model, checked between the desks. The trail guide, opened on the trail. 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. The kitchen form, shaped by hand first. The stage set, blocked out in the headset. The audio enclosure, turned over before printing. 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. Artists smooth bands around a shoulder. Developers compare matching figures side by side. Builders stand among desktop stations. Questions buyers ask ## What do buyers ask before a fast build? Short answers, each with a link to the full answer. A working build checked on laptop and tablet. ### 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](https://peopletechrevolution.com/fast-builds/rapid-custom-builds) covers the shapes it takes. A team works around a table of models. ### 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](https://peopletechrevolution.com/fast-builds/rapid-custom-builds) covers what you bring and what you get. A builder hands over the prototype for review. ### 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](https://peopletechrevolution.com/terms). Adjusting a build while it is worn. ### 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](https://peopletechrevolution.com/about/approach) covers each stage, from discovery and co-design to ongoing support. A headset scene rehearsed before a large screen. ### 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](https://peopletechrevolution.com/fast-builds/xr-ar-mr-vr-builds) walks through how a build runs. A web build checked across several screens. ### 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](https://labs.peopletechrevolution.com/play) 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](https://peopletechrevolution.com/fast-builds/web-experiences) covers browser builds. Designer and developer at side-by-side desks. ### 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](https://peopletechrevolution.com/fast-builds/rapid-custom-builds) covers the difference. Bring us the brief. See what a fortnight does with it. Open the contact form Ask our CEO Simon Lowe’s Digital Twin a question 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. [Web experiences. A page that works by Friday. Landing pages, portals and small tools, live in a browser tab for the people who asked for them, before anyone commits to the full build.](https://peopletechrevolution.com/fast-builds/web-experiences) [Mobile experiences. A build in someone's pocket. Phone and tablet experiences tested where they will be used: a ward, a warehouse aisle, a classroom.](https://peopletechrevolution.com/fast-builds/mobile-experiences) [Games and interactive. Playable rules. A mechanic, a score and a decision made real in days, so the idea is judged on how it plays, not how it is described.](https://peopletechrevolution.com/fast-builds/games-interactive) [360 experiences. A place you can look around. Panoramic scenes for browsers and headsets that put someone in a room before the room exists.](https://peopletechrevolution.com/fast-builds/360-experiences) [Event experiences and activations. Something a crowd can walk up and use. Activations built for a stand, a stage or a foyer, and tested on the floor they will run on.](https://peopletechrevolution.com/fast-builds/event-experiences-activations) [Rapid custom builds. The build nobody has a template for. A one-off problem, a working answer in a fortnight, refined with the people who will run it.](https://peopletechrevolution.com/fast-builds/rapid-custom-builds)