Technology consulting

For decisions that are expensive to reverse

The problem

Some decisions are cheap to change and some are not. Choosing a framework is usually recoverable. Choosing a data model, a payment architecture or a tenancy strategy is not, and by the time the problem is visible you have built a year of software on top of it.

The other common case is inheriting something: a system you now own, that works, that nobody wants to touch, and that you cannot honestly assess from the inside.

How we approach it

  1. 01

    We read the code and talk to the people who run it. An architecture review that only looks at diagrams tells you what was intended, not what exists.

  2. 02

    We give you the recommendation and the reasoning, including what we are uncertain about. Advice with the caveats stripped out is easier to read and worse to act on.

  3. 03

    If the answer is that you do not need us, we say so. That is worth more to both of us than a project that should not have started.

What you get

  • A written assessment with findings ranked by cost of inaction
  • An architecture recommendation with the trade-offs stated
  • A scoped plan of work you could hand to any competent team
  • Direct access to the engineers who did the review, not an account manager

Engagement

Shape
A focused review, or ongoing advisory alongside your team
Duration
Typically 1 to 4 weeks for a review

Every engagement is scoped and priced after we understand what you need. We will tell you if the work is smaller than you think.

Where we have done this

Advice grounded in operating our own systems

We run payment and retail platforms in production and answer for them when they break. That is the difference between advice drawn from experience and advice drawn from reading. When we tell you a design will hurt at scale, it is usually because a version of it hurt us.

Tell us what you are trying to build

If we are the wrong people for it, we will say so and point you somewhere better.