Process
A process is only useful if you can see it working. Every stage below ends with something concrete in your hands, and you always know what is being built and what it costs.
At a glance
The short version. Each phase has a clear end and a decision point, so you are never committed further than you have seen.
A paid discovery sprint. We map the problem, the users and the constraints, then hand you a scoped plan with fixed pricing, yours to keep whether or not you continue with us.
Flows, screens and architecture decided before anyone writes production code. You approve a clickable prototype and a technical plan, so there are no surprises in week six.
Two-week sprints with a working build at the end of every one. A shared board, a weekly call and direct access to the engineers writing the code, with no account manager in between.
Launch, monitoring and a handover that includes documentation and a walkthrough. Stay on a support retainer or take it fully in-house. Both are fine by us.
In detail
What actually happens inside those phases, who is involved and what you receive at the end of each.
We start by understanding the business, not the feature list: who the users are, what they do today, and what has to be different for the project to count as a success.
What happens
You get
A shared written brief everyone has signed off.
Requirements become a scoped plan. We check technical feasibility, name the risks, and decide what belongs in the first release and what can wait.
What happens
You get
A roadmap with a fixed price and a date.
Flows, screens and architecture are settled before production code is written. You click through a realistic prototype and approve it.
What happens
You get
An approved prototype and technical plan.
Two-week sprints, each ending with working software you can use. You have direct access to the engineers, a shared board and a weekly call.
What happens
You get
A working build at the end of every sprint.
Testing runs alongside development rather than after it. Automated tests guard the critical paths, and people test the things automation misses.
What happens
You get
A release candidate with a test report.
Launch is rehearsed, not improvised. Infrastructure is defined in code, the rollout is staged and there is a tested way back.
What happens
You get
Software in production, in your name.
After launch you choose: take it in-house with documentation and a handover session, or keep us on for monitoring, fixes and the next features.
What happens
You get
A product that keeps improving.
Week to week
The habits that hold whichever engagement you choose.
One standing call and a board you can open at any time. You never have to ask what is being worked on.
Working software, not slides. If a sprint did not produce something you can use, we explain why.
A shared channel with the people writing the code, and a reply within one business day.
New ideas are welcome. Each one gets an estimate and a decision before it enters a sprint.
If a date is at risk or an approach is not working, you hear it that week, along with the options.
Code, cloud, domains and credentials belong to you from day one. Leaving is a permissions change.
Engagements
Pick the one that matches where you are. Most clients start with discovery and continue into a build.
From $2,500
1–2 weeks
You have a problem and need a plan you can act on or take elsewhere.
Fixed-scope quote
6–16 weeks
You know what you need built and want it shipped by a senior team.
Monthly retainer
Rolling, 30 days' notice
You have an in-house team and need senior capacity beside it.
FAQ
Discovery usually starts within one to two weeks of a signed agreement. Build engagements start as soon as discovery finishes, since the plan and the team are already in place.
Yes, provided the scope is honest about it. We would rather ship a sharp first version that proves the idea than burn a seed round on a platform nobody has validated yet.
Discovery starts at $2,500. Build engagements are quoted as a fixed price after discovery. Most sit between $20k and $90k depending on scope, integrations and compliance requirements.
You do, from the first commit. Repositories and cloud accounts are created under your organisation and we work inside them as collaborators.
Often, yes. We start with a paid audit: what is salvageable, what is not, and what it costs to stabilise before adding features. Sometimes the honest answer is a rewrite, and we will say so.
Your choice. Take it fully in-house with documentation and a handover session, or keep us on a support retainer for monitoring, fixes and the next set of features.
Next step
Tell us the problem in a few sentences. We will reply within one business day with an honest read on scope, cost and whether we are the right team for it.
