How we work

Five clauses

1. 01

   Enquiry and conversation

   You describe the problem in your own words, with no specification needed. We ask questions and tell you whether we will take it on: if the job is not ours, you find out in the first conversation rather than a month into negotiations.

   We write down:

   1. What needs solving, and why
   2. Whether we take it on
   3. The order of the budget

   You hold:

   • A conversation that commits you to nothing
   • A straight answer if the job is not ours
2. 02

   Scope and estimate

   We break the problem down into a body of work and price it. On large projects this is a separate discovery phase with analysis; on smaller ones a conversation and some email is enough.

   We write down:

   1. The body of work and its boundaries
   2. The price and the payment schedule
   3. The development rhythm

   The price comes after the scope

   A price for an undefined scope is either a figure padded against every surprise, or an honest figure that slips in the second month. So the body of work comes first, then the price. Anything new along the way is priced separately, and whether to take it is your call.

   You hold:

   • A cost breakdown showing how the figure was reached
   • A contract with the scope written into it
3. 03

   Development

   You see the work in a browser rather than in a report: a working version is available from the first weeks. You hear about a problem when it appears, not when a deadline is missed.

   We write down:

   1. A weekly status without asking
   2. Repository access from day one

   We write down the rhythm too:

   Short project

   Single pass

   The scope is clear up front: a site, a bot, an integration, an MVP. Work runs start to finish with a single sign-off.

   or

   Long project

   Sprint cycle

   Systems that live for months. At the end of each stretch you see a working part and can change the priorities for the next.

   You hold:

   • A working version you can open
   • A weekly status on the work
   • Access to the code as it is written
4. 04

   Handover

   Handover is not an archive of code sent by email. The system is deployed where it will run, the credentials are put in your name, and your team gets not just the product but the ability to work with it.

   We write down:

   1. The system runs on your infrastructure
   2. Every credential is in your name
   3. Rights to the code have passed to you

   You hold:

   • The source code and the rights to it
   • Access to servers and services
   • Documentation and deployment instructions
   • Training for your team
5. 05

   After handover

   This is where most contractors stop and where the client's real fear begins. The warranty on fixing defects is written into the contract and holds even if we do not keep working together. After that it is your call: develop the system with us, hand it to your own team or to another contractor.

   We write down:

   1. The warranty period
   2. Support is your choice, not a condition

   Our longest support contract has run continuously for two years

   You hold:

   • Defects fixed during the warranty period
   • Support and development if you continue
   • Full autonomy if you do not