Skip to content

Work with me

Solution architecture for problems that don't have an obvious answer yet

I work with companies and startups on the part of a project that happens before anything gets built: understanding the problem, designing the solution architecture, and making the technical decisions that are expensive to get wrong.

What I help with

These aren't separate services. They're different angles on the same job: understanding a problem well enough to design something that works.

  • Problem discovery

    Working out what is actually going on when the problem is vague, political, or described differently by everyone involved.

  • Solution design & architecture

    Designing how systems, data, and processes should fit together for a specific problem, with the options and trade-offs written down.

    What solution architecture involves →
  • Build vs buy decisions

    Deciding whether to build, buy, integrate, or change a process instead, before the budget is committed.

    How I approach build vs buy →
  • Data migrations

    Planning a move off a third-party or legacy system without carrying its limitations into the new one.

    Data migration checklist →
  • APIs & integrations

    Designing how internal systems, providers, and partners connect, including what happens when one of them fails or changes.

    API integration checklist →
  • AI & automation

    Figuring out which parts of a workflow are worth automating, and how much context an AI system needs to be reliable.

How it usually works

  1. 1

    Discovery

    Conversations with the people who have the problem, a look at the systems and data involved, and a clear statement of what we are actually solving.

  2. 2

    Options

    A small number of realistic approaches, compared on cost, risk, complexity, time, and what your team can maintain.

  3. 3

    Recommendation

    One recommended solution architecture, with diagrams and the reasoning behind each major decision.

  4. 4

    Support during delivery

    Staying close while it gets built, so the design adapts when real data and real users show up.

What you end up with

  • A clear problem statement everyone agrees on
  • The options considered, with trade-offs
  • A recommended solution architecture with diagrams
  • Decision records explaining why each major choice was made
  • A plan your team or delivery partner can build from

Probably not a fit if

  • You already know exactly what to build and need extra developers to build it.
  • You want a long-term outsourced development team.
  • The decision has already been made and you need someone to sign it off.

Questions

What is solution architecture consulting?

It is bringing in an experienced solution architect to understand a business or technical problem, compare the options, and design how systems, data, and processes should fit together before a team commits to building it.

Do you also build the solution?

My focus is the design and decision-making before and during the build. I have a software engineering background and stay involved during delivery, but I am not primarily a developer for hire.

When should a company hire a solution architect consultant?

When a problem spans several systems or teams, requirements are vague, a decision is expensive to reverse (a platform, a migration, a core data model), or a project has stalled and nobody can say exactly why.

How do we get started?

Send me a message describing the problem in a few sentences. I reply personally, and we start with a conversation about what is actually going on.

Have a complicated problem?

Let's put it on a whiteboard.