What happens in the first two weeks of a project

Two weeks is roughly how long it takes to find out whether a project is real. Here is what happens in ours, so you can see whether it suits you, and so you can hold any supplier to something similar.

Before week one: one call

Half an hour, usually. We ask what happens now, who does it, how long it takes them, and what has to keep running while anything gets built. We ask what you have already tried, because that is often the shortest route to understanding the problem.

We also ask for a budget range, and we will tell you why: without one, we spend a fortnight designing something the wrong size. With one, we can tell you what fits inside it or that nothing does. The second answer is more useful than it sounds.

If it is obviously not a fit, we say so on that call rather than sending a proposal. Most first conversations end with a clear yes or a clear no about proceeding.

Week one: watching the work happen

Two or three sessions with the people who actually do the job, not only the person paying for the project. Wherever possible we want to see the real thing on a screen share: the spreadsheet with the highlighting only one person understands, the system everyone complains about, the paper form with handwriting in the margin.

We ask for the messy version of everything. A cleaned-up copy hides the exceptions, and the exceptions are where projects overrun.

What we are listening for:

• The step everybody dreads
• The workaround that exists because a tool cannot do something
• Anything typed in twice
• Questions nobody can answer without exporting something first
• The rule that exists because of one incident years ago, which may or may not still make sense

The output of week one is a written description of how your work happens now, in plain sentences, sent to you to correct. This document does more good than anything else we produce. If we have misunderstood the process, it costs an hour to fix here and three weeks to fix later.

Turn of the week: scope, price and the not-building list

Before any code, you get one document with:

What we are building, in the order we will build it.

What we are deliberately not building. This half matters more. It is the list that prevents the disagreement in week eight, and writing it forces both sides to be specific about what "and reporting" actually meant.

The assumptions. Stated plainly, because they move the price. If we are assuming your booking system will give us access, that assumption is written down, along with what changes if it turns out to be false.

Phases. The first phase is the smallest thing that would genuinely be useful on its own, so you can stop after it and still own something that works.

A price for the first phase, with payments tied to things being delivered rather than to dates in a calendar.

What we need from you, and when. Named, with hours attached, so nobody is surprised.

You can take that document to another supplier. Some people do. It is yours either way.

Week two: something you can click

Not screenshots, not a slide deck. A clickable version with your own words, your own field names and a sample of your own data in it. It does not save anything yet. You can walk through the flow that matters most to you.

We do this early because people cannot review a document but everyone can review a screen. Almost every serious misunderstanding on a project surfaces in this session, usually as a sentence like "wait, that is not what a job number means here".

You will want changes. That is the point, and this is the cheapest week of the project in which to have them.

What we need from you

Roughly, in these two weeks: a few hours from the person who actually does the work, access to or exports from the systems involved, real sample data, and one named person who can make a decision without convening a meeting.

If those hours are not available, we would rather say at the start that the timeline will slip than pretend otherwise and blame it later.

When we say no

We turn work down, and it is better for everyone when that happens in week one rather than month three.

An existing product already does this. We will name it and tell you to go and try it properly for a fortnight.

The arithmetic does not work. If the hours saved will not clear the build cost in a reasonable time and there is no growth argument, spending the money here is worse for you than spending it elsewhere.

Nobody inside your business will own it. Not sponsor it, own it. Without that person a project stalls a long way in, whoever is building it.

Your process is about to change. A merger, a new site, a system being replaced, a regulation arriving. Software built around a process that is about to be rewritten gets rewritten too, at your cost.

The real problem is not software. A team that will not use anything, or a genuine internal disagreement about how the work should be done. Software applied to an unsettled argument makes it permanent and expensive.

It requires something we will not build. Automating a decision that should have a person in it. Hiding that an AI agent is an AI. Anything whose main purpose is to make it hard for a customer to leave or to cancel.

We are the wrong size or the wrong specialism. Some systems need a team with a specific regulatory background, or a support desk staffed around the clock. Saying so early is cheaper for you than finding out in month four.

What we do not do in these two weeks

We do not ask you to sign a long agreement before a scope exists. We do not send a price with no assumptions attached. And we do not put an account manager between you and the people writing the code -- the person who scoped it is the person who builds it, which is only possible because we keep projects small enough for that to be true.

If you say no at the end

You keep the written description of your own process, and you keep the scope document. Both are yours regardless of what you decide. What happens after this point, if you carry on, is set out on our process page, and the shape of the work itself on custom software.

Two weeks exists so that both sides can find out cheaply. The alternative -- discovering in month three that the fit was wrong -- costs considerably more than a fortnight, and it usually costs it in your time rather than ours.