Process
How we work, stage by stage
Software projects most often fail on things that have nothing to do with code: nobody knows what is being built, nothing is visible for months, and no one says in time that the deadline has slipped. Below is how we try not to end up there.
Four rules that apply at every stage
The process below is split into six stages, but these four rules do not depend on the stage. They are things you can check yourself, on any day of the project, without asking us — which is why we write them here rather than in a sales deck.
You see the work, not reports about it
You have permanent access to a test version and to the code in the repository. You do not have to take our word that work happened this week — you log in and look.
The code is yours from the first commit
The repository, the server and the external service accounts are in your company's name. You can take the project to another team at any point, without asking permission and without waiting for a handover.
Short stages, frequent decisions
We split the work into one- or two-week pieces. The shorter the piece, the less a change of direction costs you — and the sooner you find out if something is not working.
No dependence on us
We document what we built and train the person left with the application. Maintenance gets contracted because it is convenient, not because nobody else can find their way around our code.
The stages
From the first conversation to life after launch
Not every stage is compulsory. If you already have a written analysis, we skip the second; if you only want an audit, we stop after it. What we never skip is the order.
-
01
The opening conversation
1-3 working days
A conversation in which we find out what needs solving. We do not present technologies and we do not send quotes blind.
What we do
- You tell us how you work today: which programs you use, where time gets lost, and who does by hand the work you want automated.
- We ask the uncomfortable questions — who uses the application daily, what concretely happens if you do not build it, and what you have already tried.
- We tell you plainly if your problem is solved more simply by an existing product on the market. It happens, and it is better to hear it at the start.
What stays with you
- A written summary of the conversation, so you can check we understood correctly.
- A clear answer: this is something we do well, or it is not.
What we need from you
An hour from someone who actually does the day-to-day work, not only from the person who approves the budget.
-
02
Analysis and estimate
3-7 working days
We turn the conversation into a document: what gets built, in what order, in how long, and what is left for later.
What we do
- We split the application into features and order them by how much they matter to you, not by how interesting they are to us.
- We separate the first version from the rest. Version one has to be usable, not complete — otherwise you pay for months of development before seeing whether the direction is right.
- We estimate each piece separately and as a range, not as a single figure. An estimate accurate to the day, given before a line of code exists, is a promise that breaks itself.
- We check the integrations early: which systems have to talk to each other, what documentation exists and what limits they impose. This is where most surprises come from.
What stays with you
- A document with the scope of the work, the stages and the deadlines.
- A quote split by stage, so you can see what you pay for each.
- A list of the risks we identified, with what we do if they materialise.
What we need from you
Access to the documentation of the systems the application has to talk to, and a person who can answer questions about your business rules.
-
03
Flows and screens
1-2 weeks
We draw the application before writing any code. It is the last moment at which a change costs no more than a conversation.
What we do
- We settle the main screens and the user's path through them, from opening the application to finishing a piece of work.
- We define the roles and what each one sees. An operator, a team leader and an accountant do not need the same buttons, and a screen showing all of them is useful to nobody.
- We mark the points where a person can get stuck: a mandatory field they have no way of filling in, an approval that depends on a colleague who is away, an import that fails halfway.
- We settle the data structure. What links to what, what can be deleted, and what has to be kept for audit or for the law.
What stays with you
- Sketches of the main screens, which you can show your team before the application exists.
- The list of roles and permissions, in writing.
What we need from you
A few hours discussing the sketches. Changes made now cost nothing; the same changes after two months of development cost exactly as much as a rewrite.
-
04
Development, in iterations
most of the project
We build in one- or two-week pieces. At the end of each one you log into the application and use it, rather than reading about it.
What we do
- We work on a test version you have permanent access to, with sample data. You do not wait until the end to see how it looks.
- At the end of each iteration you get a short list of what was finished, what was postponed and what comes next.
- Code goes into the repository from day one, with a complete history. You can see at any time who changed what and when.
- We write automated tests for the parts where a mistake hurts: calculations, access rights, integrations with external systems. Not for everything — tests that never catch anything are cost, not safety.
- If a new requirement appears midway, we estimate it separately and you decide whether it goes in now or after launch.
What stays with you
- A test address where the application runs, updated at every iteration.
- Code in your repository, with history and with tests.
- A short report at every delivery, without jargon.
What we need from you
Feedback within a few days of each delivery. An answer that takes two weeks delays the project by two weeks — it is the only part we cannot make up for.
-
05
Testing and launch
3-7 working days
We put the application on the real server and check what happens when real people use it, with their own data.
What we do
- We test the flows end to end on real data, including the ugly cases: an order cancelled halfway, a user without permissions, a malformed import file.
- We configure the server, the certificate and the automatic backups, and we verify that a restore actually works. An untested backup is not a backup.
- We migrate the existing data and check, figure by figure, that nothing was lost along the way.
- We set up measurement: what gets tracked, what counts as a conversion and where visitors come from — so the decisions after launch have something to stand on.
- We train the team who will use the application and stay available in the first days, when the real questions appear.
What stays with you
- The application in production, on your own domain.
- Administration documentation, written for the person left with it.
- Access to every account — server, domain, external services — in your company's name.
What we need from you
A few hours from the people who will use the application daily, so they can test it before launch. They are the only ones who find the real problems.
-
06
After launch
ongoing, for as long as it makes sense
Launch is not the end of the project, it is the first day you find out how the application behaves in reality.
What we do
- A warranty period after launch: we fix at no cost anything that does not work as agreed.
- We watch the errors coming out of production and usually see them before anyone writes to us about them.
- We update dependencies and security versions, if you stay on maintenance. An application left untouched for two years becomes expensive to restart.
- We discuss what comes next starting from what real usage showed, not from the wish list of six months ago. Usually half of it no longer makes sense.
What stays with you
- A warranty on what we delivered.
- A maintenance contract, if you want one — optional, not required.
- Everything to do with the project handed over, in a form that lets you continue without us.
What we need from you
For you to tell us what is not working. A user who gets used to a problem and invents a workaround costs more than a problem reported on the day it appeared.
Commitments
What we guarantee and what we will not promise
Any software company can write the first list. The second can only be written if you are not planning to win the work at any cost.
What we guarantee
- A deadline per stage, not a single one at the end. If it slips, you find out when it slips, not on delivery day.
- The complete source code, in your repository, from the first commit.
- Every account — server, domain, external services — opened in your company's name.
- One person on our team who answers you directly, with no journey through support forms.
- A warranty period after launch, during which we fix at no cost anything that does not work as agreed.
What we will not promise
- A fixed price for a requirement that has not been written down yet. We estimate once we know what we are building, not before.
- A deadline chosen in order to win the work. We would rather lose a project than delay it by three months.
- That version one contains everything you wanted. It contains what is useful from day one; the rest goes in once you have seen the application at work.
- That we work with any technology. If it is not something we know well, we say so and point you to someone better suited.
- That no problems will appear. They appear on every project — the difference is how quickly you hear about them and who fixes them.
The process, applied
How these stages looked on real projects
A process described on a page is a promise. The case studies are the same stages, with the decisions that came out of them — including the ones we changed along the way.
A CRM salespeople actually log into
The company already had a subscription CRM. The problem was not a missing tool, it was that nobody filled it in — because it gave nothing back to the person entering the data.
Read the case study → Financial servicesA credit file with every step reconstructable
In a lending file, the question is not only what was decided, but who saw what and on what basis. A flow held in email cannot answer the second one.
Read the case study → TransportA fleet that no longer depends on a file and one person
The fleet was run from a file of expiry dates someone intended to check every week. It worked until the week that person was on holiday.
Read the case study →Frequently asked questions
What people ask about the way we work
These are the questions that come up in the first conversation, almost every time. If yours is not here, write to us — we answer just as directly.
Ask us a questionHow long from the first conversation to launch?
It depends how many flows the application has and how many external systems it has to touch. For an internal management application of ordinary size, between two and four months. For a solution already designed for your industry, less. What we can promise is that you get a staged estimate after the analysis, not a deadline thrown out in the first conversation.
Can I stop between stages?
Yes, and it is designed that way deliberately. Every stage ends with something that stays with you: the analysis document, the sketches, the code delivered so far. There is no point at which you have paid and have nothing in hand.
Who owns the code at the end?
You do, from the first commit rather than the last. The repository belongs to your company and we work inside it. We keep no proprietary components you would have to license for the application to run.
What if I want a change halfway through the project?
We estimate it separately and you decide whether it goes in now or after launch. We do not refuse it and we do not quietly slip it past the agreed deadline either. That is exactly why we work in short iterations: a change asked for two weeks after a delivery is cheap, while the same change at the end of a six-month project is not.
Do you work with companies that already have a technical team?
Yes. Sometimes we come in as an external team on part of the product; other times we run a code audit and hand over a document the internal team carries forward on its own. In that case we agree from the start where our responsibility ends and theirs begins, so no area is left unowned.
How does payment work?
By stage, on delivery of each one — not all up front and not all at the end. The analysis is paid separately from development, because it is useful even if you stop there: the resulting document can be taken to any other team.
Why can I not get a quote straight away, without the analysis?
We can give an indicative range after the first conversation, and we do. What we cannot give is a firm price for a list of requirements that has not been written yet — that would be either far too high, to cover the unknowns, or far too low, with the unpleasant conversation moved to the middle of the project.
What happens if you disappear halfway through the project?
The code is already with you, in your repository, with a complete history and the analysis document alongside it. That does not make us irreplaceable, and that is precisely the point: you can continue with someone else without rebuilding from scratch.
The first stage is a conversation, not a contract
Tell us what you need built, or where what you already have gets stuck. If it is something we do well, we will tell you how we would start. If it is not, we will tell you that too.