Skip to content

Capabilities

Infrastructure and integrations: what has to hold underneath

Your customer sees a booking confirmed. Underneath, a lot had to go right: the right person signed in, the rule checked in one place, the photo stored privately, the text sent even though the texting service was slow, and a record kept of how long it all took. These are the parts nobody notices until they fail. We build them in from the start.
Talk through your systemsSee all ten capabilities ↓
J.H. · book a furnace checkbooking…Booked · Tue 8–10 · text sentwhat the customer seesunderneathedge function…service area checked near J.H. · Riversideidentity and access…signed in as J.H. · own account onlybackend…booking saved · rules checked in one placefile storage…furnace photo stored · privatequeue · integration…confirmation text queued, then sentmonitoring…trace recorded · 412 msEvery layer runs oncloud deploymentrelease v42 · productionci/cdbuilt, tested, reviewedsecurityleast access · inputs checked

Ten capabilities, in layers

Three layers of one system, and two capabilities that run through all of them.

01

Does the work

Where rules, records, files and slow jobs live.

02

Connects

Who may come in, and how other systems talk to it.

03

Runs and ships

Where it runs, and how a change reaches it.

04

Across every layer

Not a layer of their own: part of every one.

Five questions every system has to answer

If nobody can answer one of these, it's answered the first time something goes wrong.

  1. 01

    Who is this, and what may they do?

    Checked on the server, every time

    Each person and each connected system has its own sign-in and only the access its job needs.

  2. 02

    Where does each rule and record live?

    One place, one owner

    A rule checked in three apps drifts. A record kept in two places disagrees.

  3. 03

    What happens when something fails?

    Retried, or handed to a person

    The texting service will be down one day. The text should still go, once, or someone should know it didn't.

  4. 04

    What's running, and how did it get there?

    A release you can name and undo

    Every change takes the same path to production, and the last good release is kept ready.

  5. 05

    How would we know?

    From the system, not a customer

    Errors, slow requests and costs are recorded, and the ones that matter reach a person.

Added after the first outage, or built in

Added later

  1. 01One shared login for the office
  2. 02Rules copied into each app
  3. 03Slow work done while the customer waits
  4. 04Released by hand, late at night
  5. 05Problems reported by customers

Each fix is a project, and it starts after something broke.

Built in from the start

  1. 01A sign-in per person, access per role
  2. 02Each rule in one place
  3. 03Slow work queued, retried and visible
  4. 04Every change through the same checks, with a way back
  5. 05Alerts that reach a person first

The foundations cost less when they're part of the first build.

Built in doesn't mean built big. Every extra piece of infrastructure has to be run, secured and watched, so we add it when the system needs it, not because a diagram looks better with more boxes.

Start with what breaks

  1. API Integration

    “Our tools don't talk to each other”

    Connect them through contracts, with retries and a record of every call.

    See how it works →

  2. Observability & Monitoring

    “We hear about problems from customers”

    Watch what customers feel, and tell the right person first.

    See how it works →

  3. Identity & Access Management

    “Everyone shares one login”

    Give each person their own sign-in and only the access their role needs.

    See how it works →

Related pages

Where they come together

Related