Prove the core interaction works before you build it.
You have an idea that only works if several things happen in the right order and talk to each other correctly.
- A voice that has to listen while it's still deciding what to say.
- A payment that has to clear before a door unlocks.
- A drawing that has to land on someone else's screen while your hand is still moving.
- An agent that has to chain three tool calls together and get the order right, every time.
You can draw your idea on a whiteboard and watch the idea look correct there. What you can't do is know whether the idea actually holds together until someone wires up the real pieces and you watch the idea run. Then two things happen at once. You find out whether the idea works. And you find out what the idea actually needs to be, because some of those requirements only exist inside the friction of a real interaction. There was never a way to list them from the outside.
Where this sits
There's a gap here too, and it sits in a specific place. On one side is the Figma clickthrough, the clickable mockup, the AI-flavored demo you can put together in an afternoon: fast, cheap, and it lies about the one thing you actually need to know. A clickthrough is an inference of the mechanic, not the mechanic itself. Mock up 'a voice that has to listen while it's still deciding what to say,' and what you're actually showing someone is a chat bubble that pops up right on cue. Nobody has watched it handle two people talking over each other. That's a performance, not proof.
On the other side is a full production build: the whole team, the whole system, the whole budget, committed against a spec that is still fictional in exactly the place that matters most.
We work in the middle, and what we build there is proof of life. Anyone can market a concept and get a nod: 'that could be a good idea.' Proof of life is different: it's the moment the idea stops being a story you tell and becomes a thing that happened, live, in front of a real person. That's not only proof for you. It's the moment belief becomes visible to someone else, which lets a founder bring in a co-founder, an investor, or a first hire who needed to see it to believe it.
If what you actually need is real strangers using this unsupervised, with accounts and their own data on the line, that's an MVP, and we'll tell you so rather than sell you this. If the uncertain part of your idea isn't software at all, if it's hardware, physical production, or some specialized craft in media, that's a different practice, and we'll say that too.
What you get
- The core mechanic, built for real and running, not simulated or faked for a demo.
- A written diagnosis naming the single riskiest unproven assumption in your idea, delivered before a line of code gets written.
- A repository you own, with one command that brings up the app and its database on a machine you control.
- Rounds of tuning on how the mechanic actually behaves: timing, edge cases, feel.
- An honest account of what carries forward into a real product and what was always going to be thrown away.
- Any third-party usage costs estimated and capped up front, billed to you at cost.
Everything below is defined in plain language: what each thing means, what it changes, and where the line falls. What each option costs is on the pricing page.
What these terms mean
What kind of mechanic you're proving
Four different kinds of uncertainty. Read each one and see if it sounds like your idea.
- Live coordination
- The uncertain part is the coordination itself: timing, turn-taking, rhythm, feel. A language-exchange video app that has to manage turn-taking between two strangers who've never met, so neither one talks over the other and neither one is left hanging. A multiplayer drawing-and-guessing game where the entire feel of the thing lives in how simultaneous everyone's actions actually are. You can write the rules of that down on paper. You cannot write down the feel.
- Reactive state
- The uncertain part is whether the logic holds, and stays readable to the person using it, once conditions start shifting mid-stream. A dispatch tool reassigning drivers in real time as traffic backs up and jobs get canceled out from under it. A small warehouse's inventory that has to reflect a sale the instant it happens, or the next sale oversells something that's already gone. On a whiteboard the logic is a clean flowchart. Under real, moving conditions, it either holds together or it quietly breaks in a corner nobody thought to check.
- Judgment under live stakes
- The uncertain part is what a person actually does when something they care about is moving in front of them, live. A trading or budgeting practice tool where a number is changing in real time and you have to make a call before it changes again. A poker trainer with a real pot and a running clock, built to find out whether you actually fold when folding is the correct, unglamorous answer. None of that shows up on a static screen. It only shows up once the stakes are live and the clock is running.
- Perception against a messy world
- The uncertain part isn't whether an existing model or service works in principle. That capability is usually already proven, built and trained by whoever makes the vision or audio service you're building on — you call it the same way you'd call any other API. The uncertain part is whether the interface you build around it survives contact with a messy, unpredictable world. A plant-health app calling an existing plant-disease API: the actual build is a Next.js front end that takes a phone photo shot under real kitchen lighting, not a studio reference shot, and decides what to show when the API comes back uncertain instead of confident. A snoring app calling an existing audio-classification API: the build is the interface deciding what to do when it can't tell a real snore from a box fan or a dog on a hardwood floor — ask, flag, or stay quiet, rather than guess and look broken. The logic works perfectly against a tidy example. Real input is dirtier than that, every time, and the only way to find out how much dirtier is to point it at the real thing.
- What moves the price
- Sign-in and accounts. A backend that stores something and gives it back. Fetching an outside service and showing what it returns. A front end onto a system you already run. The pieces are known; the work is composing them correctly and fast.Retrieval across your own documents. Real-time coordination between people. Video or media processing. A genuine fetch-transform-return pipeline. More unknowns, more integration risk, and the failure modes only show up under real conditions. Most of what lands here right now is agentic work — plugging into an existing system as an MCP server, or building a workflow that plans and chains its own steps. That's not incidental. It's where the market's actually asking. Agentic workflows that plan and chain steps. Wrapping one of your services as an MCP server. A task-specific agent embedded in an app you already run. Real-time voice agents. Retrieval across your own documents. Workflow chains across systems. Live collaboration and presence. Reactive dashboards.Some mechanics stop being one contained thing. We size those together once we've seen the shape, rather than quoting a number we'd have to walk back. Several live participants affecting each other at once. A chain of agents or steps handing off live. Real-time on top of heavy processing, stacked. State that has to stay in sync across sessions or devices: reconnect, resume, reconcile. Integrating against an existing system we can't fully see.If you could search "how to integrate X" and be done, that's plumbing, not a prototype. It's a prototype when nobody can tell you in advance whether the interaction will actually work, or feel right.
Who's actually going to use it
This is the real fork in scope, the same way page count is on a landing page. Who's in the room when it runs changes everything about what has to be built.
- Watching it together, in the room
- The default, and the cheapest version of this by a wide margin. You, and whoever you're showing it to, in the same room or on the same call, watching it run live. No accounts. No sign-in. Nobody using it when you're not there to see what happens.
- Real strangers, unsupervised
- A different thing entirely. Someone you've never met opens a link, alone, with nobody from your team watching over their shoulder. That needs sign-in, needs usage limits so one person can't run up an unbounded bill, needs sessions that expire cleanly instead of leaking into each other. It costs more, and it costs more precisely because you are not in the room.Past a certain point, this stops being a prototype and starts being an MVP. That's a different project, with a different shape, not a bigger version of this one.
What it costs to run
This is broader than the AI bill, even though that's usually the first thing anyone pictures.
- A bill that isn't studio time
- Some of what a prototype needs isn't our time at all. It's a running bill from somewhere else: an AI provider charging per call, a search database charging per query, a specialized service charging by usage or by seat. That bill exists whether we build for you or you build it yourselves.
- One-time versus every time
- Some of that cost is one-time setup: standing up an account, configuring a service, wiring in a key. Some of it charges every single time someone actually uses the thing, which means the bill moves with how much the prototype gets used rather than sitting still.We can estimate it and we can cap it. We don't control it and we don't mark it up.
What done looks like
Two states, and the distinction between them is the sharpest thing on this page.
- Proven
- The mechanic runs, and it works, verified live together with you watching it happen. That might still need a developer environment to launch it: someone's laptop, a local setup, a terminal window open in the background. Proven doesn't require it to be pretty or public. It requires it to actually work, in front of you, for real.
What it looks like
Two states, and the line between them is firmer than it sounds.
- Plain by default
- Black and white, default spacing, nothing decorative. The mechanic is the point, and at the floor price nothing is spent making it handsome. This is not an oversight. It's where the money isn't going.
- Made presentable
- You pick from a set of ready-made themes and we apply the one you choose, as-is. It stops looking like a developer's screen and starts looking like a product. There's no design round, no mockup to approve first, and no back-and-forth: you chose the suit off the rack, and we're not tailoring it.This buys applying an existing design system, not authoring a new one. Custom design, pixel-level work, and rounds of visual revision are an MVP conversation.
Every one of these has a price on the pricing page.
How it runs
- Formative
A first conversation
Free, and it's not a diagnosis yet. We talk about what you're trying to prove, whether there's a real fit between what you need and what we do, and whether this is even the right shape of engagement for your idea.
- Formative
Discovery
Paid, and deliberately so, because this is real diagnostic work rather than a sales call wearing a different hat. We find the single riskiest unproven assumption inside your idea, scope what actually needs building, and ask the specific questions about behavior that a mockup could never answer for us. The principle behind charging for this step is simple: you're not paying for a guaranteed yes, you're paying for a real, honest answer. If that answer turns out to be that this isn't ours to build, you're still only charged for the time it took to find that out.
- Architectural
The work happens out of sight
Risk analysis, system design, an architecture sketch: the part of the job that doesn't need you in the room. We're working out how the riskiest piece would actually get built, and where it's likely to break.
- Legible
A written document comes back
It lands in your project portal, and it's deliberately short. The problem, stated plainly. What's in scope and what isn't. A sketch of how it would be built. The biggest risks we can see. And priced options, each with a plain-English recommendation, so you're never staring at a menu with no sense of which item we'd actually order.
- Legible
You pick an option
The real approval gate. Nothing gets built before this point, and nothing gets built without your say.
- Calibrated
Build
The mechanic gets built for real, tuned against how it actually behaves once it's running: timing, edge cases, feel. That tuning is bounded to what discovery agreed on, not an open invitation to redesign the thing from scratch on a whim. If running it surfaces something genuinely new and necessary, and surfacing exactly that is the whole job of a prototype, that isn't a revision. That's a new conversation, priced honestly, the same way discovery was. The step ends with the mechanic proven, verified live together.
- Legible
The honest conversation, if it's needed
Sometimes what a prototype turns up is bigger than what this tier can responsibly carry: real users, accounts, a system meant to run unsupervised at scale. Sometimes the uncertain part turns out to live outside a screen entirely, in hardware or physical production. When that happens we say so directly, instead of quietly stretching the scope and handing you something thin on schedule. Sometimes that means moving up to an MVP with us. Sometimes it means pointing you toward someone whose work is the right call even though it isn't ours. Either way, you hear it while it's still useful to you.
What this isn’t
This isn't the finished product. If what you need is real users, real accounts, and a system built to run unsupervised at scale, that's an MVP, and we'll scope it as one. It isn't a mockup either. It actually runs, which is the whole point. It isn't hardware or physical production. If the uncertain part lives outside a screen, that's a different practice. And it isn't open-ended revision. We tune the mechanic until it feels right. We don't redesign it from scratch on a whim. If something new comes up that wasn't in the original diagnosis, that's not a revision. That's a new conversation.
Still deciding between tiers, or wondering what a project actually costs? See how the tiers differ and what a project costs on the FAQ page.