Scope and cut list
We define the one question the build has to answer, then write down what is deliberately left out. The cut list matters as much as the feature list, because it is what keeps the first release small enough to actually finish.
Services · MVP Development
We build the smallest version of your product that can prove or disprove the idea, ship it in short cycles with a demo every week, and instrument it so what you learn is measurable rather than a matter of opinion.
You own the code and IP Weekly demos Reply within one business day
build-orchestrator
mainsrc/
queue.ts
pool.ts
retry.ts
types.ts
index.ts
1
2
3
4
5
6
7
8
export interface BuildJob {
repo: string;
region: "ca-west-1";
}
export async function queue(
job: BuildJob,
): Promise<Run> {
return await pool.add(job);
212
Tests passed
0
Type errors
1.4s
Build time
Watching src/ — optimised rebuild on save
OlDevs is a full-stack technology studio in Vancouver, British Columbia that builds MVPs and product validation releases for founders and corporate innovation teams.We scope the smallest build that can answer your riskiest question, choose a stack that survives early growth, and ship in short cycles with a working demo every week. Instrumentation and user testing are part of the first release, so the decision to continue, pivot or stop rests on evidence rather than opinion. When an off the shelf product would answer the question faster, we say so before you spend on custom code.
Key facts
Build to learn, not to impress
We define the one question the build has to answer, then write down what is deliberately left out. The cut list matters as much as the feature list, because it is what keeps the first release small enough to actually finish.
Scoping · Prioritisation · Roadmap
We pick well supported, unremarkable technology that a small team can run and a larger team can inherit. No framework chosen for novelty, no architecture that assumes traffic you do not have yet, and no lock-in you cannot undo later.
Architecture · Full-stack · Hosting
Every week you see the product running rather than a status report. Short cycles keep scope honest, surface misunderstandings while they are still cheap to fix, and give you something real to put in front of users and stakeholders.
Delivery · Demos · Iteration
Analytics, event tracking and error reporting ship with the first release, tied to the questions you are trying to answer. You get numbers on activation, drop-off and repeat use instead of reasoning from a handful of anecdotes.
Analytics · Event tracking · Reporting
We recruit people who match your intended user, watch them use the build, and record what actually happened rather than what was supposed to happen. Sessions are short and scheduled around your cycle so findings land while there is time to act.
Research · Usability · Recruiting
At the end of each cycle we recommend continue, pivot or stop, with the evidence behind the recommendation. You own the code, designs, accounts and IP throughout, so you can carry on with us, your own team or another studio.
Validation · Handover · Governance
Process
Frame the question
We work out what you are actually trying to learn, who the intended user is, and what a good result would look like before any design or code starts.
Scope and cut
We agree the smallest build that answers the question, write the cut list, choose the stack, and set the measures the release will be judged against.
Build and demo
Short cycles with a working demo every week. You use the product as it grows, and scope changes are decided with the cut list open in front of us.
Test and measure
Real users work through real tasks while instrumentation records activation, drop-off and repeat use. Findings are written up plainly, good or bad.
Decide and plan
We recommend continue, pivot or stop against the measures agreed at the start, then plan the next cycle or hand over everything cleanly.
How we work
We list what has to be true for the idea to work, rank the assumptions by how badly a wrong answer would hurt, and build against the top one first.
The release has to be real enough for a real person to finish a real task, and small enough that changing your mind about it costs very little.
Everything left out is recorded with the reason and revisited later. Nothing quietly disappears, and nothing quietly creeps back in mid cycle.
One accountable team, a working demo each week, and a short written note on what changed, what we learned and what we plan to do next.
A small set of events tied to the assumption under test. Dashboards full of numbers nobody acts on are a distraction, not evidence.
If configured off the shelf tools would settle the question sooner, we recommend that instead. Custom code should earn its place.
Who it's for
Innovation and digital teams testing a new product line without waiting on a full program. We fit your security, procurement and governance reviews and plan for them in the first cycle.
Member services, portals and public tools that need a small, accessible pilot before a wider commitment. WCAG 2.2 AA and bilingual English and French capability are available from the first release.
Head office teams validating a tool for franchisees before rolling it network wide. We pilot with a few locations, measure real use, and only then design for scale.
Founders who need working software in front of users and investors quickly, without a stack that has to be thrown away the moment the idea starts working.
Weekly
Working demo every cycle
Full
Client owns code, designs and IP
1 business day
Reply to every enquiry
FAQ
The smallest build that can prove or disprove a specific assumption about your product. It is not a cheap version of the finished thing and it is not a prototype nobody can use. It has to be real enough for a real person to complete a real task, and small enough that you can change your mind about it without losing much.
It depends on how narrow the question is and how much of it can be answered without custom code. We scope in cycles rather than quarters: you see a working demo every week, and after the first two or three cycles the pace is predictable enough to plan around. If the scope you want will not fit a short build, we say so early.
More often than founders expect. If the idea is mostly a workflow that existing tools already handle, a configured set of off the shelf products will answer your question sooner and for less than custom code. Building earns its place when the software itself is the thing that makes you different, or when nothing on the market fits without awkward contortions.
Sometimes, yes. Concierge tests, a landing page with real sign-ups, and manual delivery behind a simple form can answer demand questions before a line of product code exists. We use those when they fit, because a cheap answer is still an answer. A build makes sense once the question narrows to something only working software can settle.
A running product plus the source code, designs, analytics and accounts, all in your name. You also get the evidence: what people did, where they dropped off, and what we would do next. Nothing is held inside our own tooling, so you can continue with us, hire in-house or move the work to another studio without a rebuild.
Before the build starts we agree what a good result looks like, so the decision is not made on mood at the end of a long cycle. Each cycle reports against those measures and against what users did. If the evidence says stop, we say stop. Recommending more work you do not need is a poor way to keep a client.
Yes. The studio is in Vancouver and we work with clients across Canada and beyond, with video calls scheduled in your time zone and on-site visits when the work genuinely calls for them. Corporate and public sector clients often need us to fit their security and procurement reviews, which we plan for in the first cycle.
Let’s connect
Tell us what you’re building. We’ll reply within one business day with next steps and a tailored quote — no obligation.
Thanks — we’ll reply within one business day.