Forward-deployed

We work inside your systems, not beside them: your repositories, your cloud accounts, and your site when the project needs it. We ship to production, and we leave behind something your team can run.

How a deployment goes, from arriving to leavingYour system, drawn as a box holding a server rack, a database, a queue and a spreadsheet. We arrive inside it, drawn dashed because we are temporary. We ship into the parts that were already there. We write down what we built into a repository. Then we leave: our outline fades, and the repository stays.Your systemUs, whilewe’re thereWhat we shipWhat stays
We leave

What it means

Three things. A project that is missing any one of them is something else.

  1. Inside, not beside

    The cluster, the warehouse, the vendor API and the spreadsheet somebody emails every morning are the job, not the obstacles to it. We work in your own repositories and cloud accounts, and on site when the project needs it.

  2. Shipped, not recommended

    We write the code and take it to production. Observability and evaluation go in from the first commit, so whether it works is something you can watch rather than something we tell you.

  3. Handed over, not held

    We are finished when your team can run it without us. What we learn goes into your repository as infrastructure as code, runbooks and tests, not into a reason to keep calling us.

Where the term comes from

The title began at software companies that embed engineers with their customers to deploy the company’s own platform. The AI labs and the large cloud providers have since built teams of their own. Ours differs on every reading below, and on purpose.

The product-company model and this practice, compared
Product companyThis practice
What gets deployedThe company’s own platformInto your systems, as they are
Where the lessons goBack into that platformInto your repository
How long they stayFor the long term, close to the accountUntil your team can run it without us
Who does the workA bench of engineersOne lead, with collaborators brought in project by project
On siteMost of the work happens in your repositories and cloud accounts. When a project needs it, it happens where the system is.

What it is not

The term gets used loosely. Here is what it isn’t, and what it is instead.

  1. Not: A deck of slidesIt is: A written assessment first, then working software.
  2. Not: A demo that only works while we are in the roomIt is: Software you can run yourself, in your own accounts.
  3. Not: A seat on your teamIt is: A project with a clear outcome and an owner on your side.
  4. Not: A dependency on usIt is: A handover your team can run without us.
How an engagement runs, step by step

If your system needs someone inside it rather than beside it, the next step is one call, about ninety minutes.

Start a conversationroot@saguaro.cloud