Bring us the problem, not the specification.

Seven kinds of problem we take on

1. Do two thousand people need to work inside the same system at the same time?

   When many people work in one system, the hard part is not the screens — it is what happens when they all press save at once. We build the part that has to hold.

   How we work on this

2. Do you have an idea that has to exist before you can find out whether it works?

   An idea only becomes testable once someone can use it. We build the smallest real version, put it in front of people, and change it based on what they do.

   How we work on this

3. Should your data be leaving your building at all?

   For many organisations the honest answer is no — the data should stay where they can see it. We build and run the platforms that make that practical.

   How we work on this

4. Does part of your work still depend on someone moving data between two systems by hand?

   Automation pays when the work is repetitive, the rules are knowable, and mistakes are expensive. We check all three before writing a line of code.

   How we work on this

5. Is the answer you need not published anywhere yet?

   Sometimes the question has never been asked in quite your form, and the only way to answer it is to build the experiment. We design it so the result means something.

   How we work on this

6. Do you need to know whether the system you were quoted is the right one?

   Before a large commitment, a second opinion from someone with no stake in the sale is cheap. We read the proposal the way the vendor hopes nobody will.

   How we work on this

7. Does your problem start with a physical process rather than a user?

   Some systems are governed by physics before they are governed by code. We model the process first, then build the software that respects it.

   How we work on this