Get In Touch

Discovery moves quickly when one person can answer scope, budget and timeline questions in the room. If the decision lives in a committee, the project will move at the speed of the committee. Tell us who that person is and how they prefer to work.

Strong projects start with a specific operational pain that someone can describe in two sentences without using a technology word. Vague pains produce vague scopes. If the pain is hard to put in writing it is worth a short conversation before any engagement.

A measurable definition of success protects both sides. It might be a launch date, a defect rate, a response time or a piece of headcount that can be redirected. The clearer the definition, the easier it is to design the right phase of work.

Integrations are usually the largest single source of unexpected effort. Bring a short list of the systems we will need to read from or write to, the names of the people who own each one and a note on whether the documentation is current.

Honest budget bands save time on both sides. We publish indicative bands on the pricing page so the conversation can start from a real number. If the number is sensitive, we can sign a mutual non disclosure before discovery starts.

United Kingdom hosting is the default. Where a regulator or buyer requires a specific region, we want to know that up front so the architectural choices can be made cleanly. If the position is not yet decided, that is also useful information.

Some clients run the system themselves after launch. Others stay on a retainer with us. Both are fine. We need to know which it is so the documentation, training and access patterns can be shaped for the right operator.

There are often two deadlines: the one written in the brief and the one that really matters. The second is usually a board update, a regulatory date, a procurement window or a launch event. The second is the one we plan around.