How we work, start to finish.
The whole engagement, laid out in the open: what happens on the first call, what the first month looks like, and the rhythm it settles into after that. If you are deciding whether to book a call, this page is what you would be agreeing to.
It starts with a diagnosis.
A thirty minute working session, not a pitch.
Everything starts with a thirty minute working session, under NDA if you want one. Bring the problem as it actually is: the stalled build, the spreadsheet that runs the business, the deck that never became a product. We will ask what the software has to do, who has to use it, which constraints are fixed, like a deadline, a budget ceiling, or a compliance obligation, and what already exists that we can look at.
By the end of that call you have an honest read: how big this really is, where the risk lives, and whether we are the right team for it. When we are not, we say so and point you somewhere better. That costs us a project occasionally and it is still the right trade.
What the first four weeks look like.
From first call to software you can click, week by week.
Product diagnosis
The first call and the days around it. We dig into the problem, review whatever exists, whether that is code, a product, or a spreadsheet, and come back with a clear picture of size, risk, and fit.
Scope, architecture, design direction
A written scope of what ships first, the architecture we propose and why, and the design direction. It comes with a price and a timeline, and you sign off before we build anything.
First working release
Real software on a staging link you can click, growing every week. The first demo is usually rough, and that is the point: you steer the product while steering is still cheap.
The rhythm after that.
Once the build is running, the engagement settles into a cadence you can plan around.
A demo every week
Working software on a real link, walked through live. Decisions get made in that meeting, not summarised afterwards in a status deck.
Direct access to the builders
A shared Slack or WhatsApp channel with the engineers and designer on your product. No account managers translating in the middle. You ask the person who knows.
Sprint reviews
Every two weeks we look at what shipped, what we learned, and what comes next, and adjust the plan in the open. The roadmap bends to reality, not the other way around.
Your accounts, least privilege, clean exits.
The defaults on every engagement, whether or not anyone asks for them.
- Cloud, domains, and repositories are created under your accounts from day one
- We request the least access each piece of work needs, scoped and time-bound
- Development, staging, and production stay separate from the first deploy
- No production data on local machines; we develop against masked or synthetic data
- When someone rolls off the project, their access goes with them the same day
- When the engagement ends, we hand back every key and rotate what we touched
Documentation and handover.
Written as we build, so leaving us is always an option.
Documentation is written while we build, not scrambled together at the end: the decisions we made and why, how to run the system, and what to check when something looks off.
That means handover is not a cliff. Your own team, or a different vendor, could pick the product up at any sprint boundary and keep going. We believe you should never be trapped by the people who built your software, and that includes us.
Production support once it is live.
The part most vendors skip is the part we plan for.
Launch is the start of the real work, so we do not disappear at the launch photo. We watch the monitoring, fix what the first real users find, and keep shipping while the product finds its footing.
After that, most clients keep a lighter ongoing arrangement for improvements and support. Some take it fully in-house, and we help them do that well. Both are good outcomes. The shape is agreed before launch, not negotiated during an outage.
Before you book the call.
The things people ask before they book, answered straight.
Who do I actually talk to?+
The people building your product: one product lead, plus the engineers and designer on your work, in a shared channel. There is no account manager layer, so answers come from the person who knows, usually the same day.
How do you handle changes mid-build?+
Small changes fold into the weekly rhythm; that is what the rhythm is for. Bigger changes get re-scoped in the open: we tell you what they cost in time and money before any of it is spent, and you decide.
What if it is not working out?+
You can stop at any sprint boundary. Everything already lives in your accounts and is documented as we go, so you keep all the work done so far and owe nothing beyond it. No lock-in and no exit fee.
Do we own the code?+
Yes, from day one. The repositories, cloud accounts, and design files sit under your name while we work, not handed over at the end. If we parted ways tomorrow, you would lose nothing.
How do payments map to milestones?+
Payments follow the plan we agree in week one and are tied to phases of working software, not hours logged. You will have seen the previous phase running before the next payment is due, so you are never paying on faith.
How much of my time will this take?+
One decision-maker for a weekly demo and quick answers in the shared channel, a few hours a week in total. The most expensive thing you can give us is a slow decision, so we keep the asks small and specific.
This is how we work with you. For the method behind the builds, read our process →
Want this rhythm on your problem?
The first call is the Week 0 diagnosis described above: thirty minutes, under NDA if you like, and an honest read on size, risk, and fit.