Ways of working and payment

The contract type is chosen by how clearly the task is specified. Trying to fix a price for an undefined scope is a way to fall out halfway through the project.

The source code and the rights are transferred to you. This is fixed in the contract: once the work is complete you can develop the product yourselves or with another contractor. We hand over the repository, the documentation and the deployment instructions.

How we run the project

We show working parts every two weeks. That way a mismatch with expectations surfaces in week two, not at handover.

01

Analysis

We analyse the process and document the scenarios and constraints. The output is a specification and an estimate. This stage is paid for separately and does not oblige you to continue with us.

02

Prototype

We build a minimum working version covering the key scenario. Often at this stage some requirements fall away as unnecessary.

03

Iterative development

Two-week cycles with a demo and acceptance. Priorities can change between iterations without rewriting the contract.

04

Handover and support

Documentation, deployment instructions and administrator training. After that come the warranty and further development as needed.

Frequently asked questions

Often yes, and we say so plainly. An off-the-shelf product with configuration is almost always cheaper and faster to launch. Custom development is justified when the process really is unique, or when ready-made solutions require rebuilding the company around them, which costs more than it seems.

We do not quote precisely for an unspecified task: such estimates are off by multiples. Instead we propose a short one to two week analysis stage, paid for separately, after which you have a specification and an estimate you can take to any contractor.

At least two people work on the project, the code lives in your repository or a shared one, and decisions are recorded in documentation. Replacing a team member affects the pace for a couple of weeks but does not stop the project or require rewriting what is done.

Yes, after a technical audit. We review the state of the code, the tests and the documentation. Sometimes the honest answer is that rewriting the system is cheaper than maintaining it, and we put that conclusion in writing too.

Describe the task in your own words

No specification needed: tell us which process hurts and what should change. We will propose a way of working and estimate the analysis effort.