A process where you can see what was built at every stage
We don't disappear for three months and come back with a finished system.
After every two-week cycle there is a version you can click through — even when it doesn't do much yet.
The stages of working together
- 01
The call
An answer on whether we are the right vendor
- 02
Discovery workshop
Scope, timeline and a quote with its assumptions stated
- 03
Design and prototype
A clickable prototype of the key screens
- 04
Build in iterations
A working version on staging every two weeks
- 05
Launch and support
Data migration, team training and monitoring
What happens at each stage
- The call
- We ask about the process you want to fix: who does it today, how many hours it eats, and where it breaks most often. We don't talk about a solution until we understand the problem. Sometimes this ends with us saying an off-the-shelf tool and two integrations would do — and we say it, even though in the short term that costs us the work.
- Discovery workshop
- A paid stage, and the only one that leaves you with material you can put in front of other vendors. We map the process, agree what belongs in the first version and write down what is deliberately deferred. The quote gives not just a number but the assumptions it rests on and what would change it — so a change order is never a surprise.
- Design and prototype
- Before any code exists, there is a prototype you can walk through as if it were the finished application. This is the cheapest moment to change your mind: a fix in the prototype costs hours, the same fix after launch costs weeks.
- Build in iterations
- Two-week cycles. At the end of each there is a version on staging that you have had access to since day one. There is no stage where you have to take our word for it — progress is something you can see, not something described in a report.
- Launch and support
- Moving data off the old system, training, switching monitoring on. The project doesn't end on launch day — it ends when the team is working in the new system and nobody goes back to the spreadsheet.
Why iterations rather than one fixed plan
Why iterations rather than a single delivery date
The most expensive mistake in a software project is a misunderstanding that surfaces after three months. It costs not what the fix costs, but what everything built on top of it costs.
Two weeks is the shortest period in which something working can be delivered, and the longest worth waiting to have an assumption checked. A version on staging isn't a progress report — it's evidence you can click, and say "that isn't what I meant", before three more features are built on top of it.
What we need from you
One person who can make decisions and has two hours a month. Not to supervise the code — to settle the questions we can't answer, because they are about how your company works, not about how software works.
Access to the people who do the process by hand today. They are the ones who know the exceptions that appear in no procedure and still have to exist in the system.
What we don't do
We don't start building without a workshop. We don't quote a project off a one-hour conversation — that number is guesswork in a PDF and falls apart on contact with reality. We don't promise deadlines we don't believe in ourselves.
Questions about the process
Can I walk away after the discovery workshop?
Yes, and people regularly do. The scope, timeline and quote are yours — take them to another vendor or to your board for budget. The workshop is paid precisely so that decision stays free.
What happens if the scope changes mid-build?
Scope changing is normal; pretending it won't is not. On fixed price a change goes through a written amendment with its own quote; on time and material it simply enters the next iteration. That is why the quote states its assumptions — so it is clear which one has just stopped holding.
Who writes the code — the person I'm talking to?
Yes. We are a small team and stay that way deliberately, so the person in the first meeting is the one who later writes the code. There is no account manager who hands the project on.
What if we stop working together halfway?
You keep what has been built. The repository, the rights and the infrastructure are on your accounts from the start, and documentation and tests are written so another team can take over without us. That is a condition of fair collaboration, not a favour.
Got an idea? Let's talk.
The first call is free. We reply within one business day.