Our work

Every project we can publish, anonymised: when it ran, what was built and the technology it ran on. 7 are written up at length, and they come first.

40 projects. 17 years.

7 in full

The problem, what was built and the evidence for it, written up so you can check it.

  1. Media and high-trafficOct 2026No. 01An AI match-intelligence control room for live sports broadcast, on AzurePuts AI-written match insight on air for many broadcast partners at once, in English, Spanish and German, each under its own editorial policy. Models on Microsoft Foundry write the words; code computes every number and checks every claim; corrections reach everything already published; every item on air carries a signature from Azure Key Vault. Built for the Microsoft × Premier League developer hackathon.Microsoft Foundry · Azure OpenAI · Microsoft Agent Framework · Azure Container Apps · BicepRead the write-up
  2. Enterprise SaaSMay 2026 to Jul 2026No. 03A multi-agent SRE assistant platform and its agent-delivery frameworkA framework and lifecycle tooling for building, deploying and routing multi-agent assistants for site-reliability work, with a deployed fleet whose flagship investigates, triages and, with human approval, mitigates production incidents.Python · Vertex AI · Claude · Gemini · Google ADKRead the write-up
  3. E-commerce and DTCJan 2026 to Jul 2026No. 06A subscription content platform with headless commerceA Spanish-language, mobile-first platform selling time-boxed cohort programs and physical goods through a headless storefront, then unlocking the purchased content to the right account while keeping every purchase off in-app payment rails.Go · TypeScript · Shopify · Pulumi · SendGridRead the write-up
  4. Enterprise SaaSSep 2025 to Jul 2026No. 11A fleet-wide SRE service-maturity scorecard platformScores every microservice in a large fleet against an SRE maturity rubric by mining Git, CI and observability data, then serves the results and an advisor through a web dashboard backed by BigQuery history.Go · BigQuery · GKE · ArgoCD · TerraformRead the write-up
  5. Non-profit and educationSep 2025 to Oct 2025No. 12A participation dashboard over a rolling-window CRM exportTurns daily spreadsheet exports from a donor CRM into per-cohort participation metrics, serving both an access-controlled staff dashboard and a public bilingual campaign page.TypeScript · Next.js · Cloud RunRead the write-up
  6. Enterprise SaaSAug 2025 to Nov 2025No. 14A self-service Kubernetes network-connectivity diagnostic toolA web tool that lets engineers run on-demand network reachability tests from inside any of the company's Kubernetes clusters to an arbitrary target, reporting timing, diagnostics and certificate details.Go · Gin · Kubernetes · Workload IdentityRead the write-up
  7. Non-profit and educationNov 2024 to Feb 2025No. 16An email-triggered donation attribution pipelinePicks up a donor-CRM report that only ever arrives as an emailed spreadsheet, joins it against a student roster, and writes back a per-student donation breakdown.Go · Apps Script · Cloud Functions · GCSRead the write-up

The catalog

The other 33, across 5 sectors. Each card’s grid is the whole technology index, 80 squares, most used first; the inked squares are the ones that project ran on.

2024 onward9 projects

  1. 02Jun 2026 to Aug 2026How an agent gets authority, and one contract for its secretsPython · Workload Identity · Secret ManagerEnterprise SaaS
  2. 04May 2026 to Aug 2026An agent platform on a managed agent runtimePython · Google ADK · Gemini · uvEnterprise SaaS
  3. 05Feb 2026 to Aug 2026Pull-request automation for infrastructure changePulumi · GitHub Actions · Workload IdentityEnterprise SaaS
  4. 07Jan 2026 to Aug 2026Self-service tenancy and onboarding for platform teamsPulumi · TypeScript · GitHub ActionsEnterprise SaaS
  5. 08Jan 2026 to Jul 2026Infrastructure as code across a multi-subscription Azure estatePulumi · Go · AzureEnterprise SaaS
  6. 09Nov 2025 to Jun 2026DNS delegation, resource naming and labelling conventionsGoogle Cloud · Pulumi · Cloud DNSEnterprise SaaS
  7. 10Oct 2025 to Aug 2026Multi-tenant infrastructure-as-code platform with automated address allocationPulumi · TypeScript · Google Cloud · Shared VPCEnterprise SaaS
  8. 13Sep 2025 to Aug 2026A monorepo and release line for platform toolingMoon · TypeScript · release-pleaseEnterprise SaaS
  9. 15Mar 2025 to Aug 2026Service mesh and GitOps configuration management rolloutAnthos · GKE · Anthos Config ManagementEnterprise SaaS

2020 to 202410 projects

  1. 17Sep 2023 to Jun 2024A standard monorepo for second-generation cloud functionsTypeScript · Nx · Cloud FunctionsFintech and regulated
  2. 18Aug 2022 to May 2024Schema checks and subgraph publication in the delivery pipelineTekton · GraphQL · NodeFintech and regulated
  3. 19Jun 2022 to May 2024Self-hosted continuous-integration runners on the clusterGitHub Actions · Kubernetes · HelmFintech and regulated
  4. 20Mar 2022 to May 2024Per-pull-request preview environmentsTekton · Kubernetes · HelmFintech and regulated
  5. 21Feb 2022 to May 2024A continuous-integration platform on Kubernetes-native pipelinesTekton · Knative · KubernetesFintech and regulated
  6. 22Jan 2021 to May 2024Observability and alerting standardized across the fleetPrometheus · Sumo Logic · HoneycombFintech and regulated
  7. 23Jul 2020 to Dec 2023Provisioning for managed databases, streaming and the warehouseSpanner · Cloud SQL · Pub/Sub · BigQueryFintech and regulated
  8. 24Jun 2020 to May 2024GitOps delivery for a fleet of production servicesArgoCD · Helm · KubernetesFintech and regulated
  9. 25Apr 2020 to May 2024Infrastructure as code across a cloud organizationTerraform · Atlantis · Google CloudFintech and regulated
  10. 26Apr 2020 to Dec 2023A managed Kubernetes platform for product engineeringGKE · Helm · TerraformFintech and regulated

2016 to 20202 projects

  1. 27Jan 2017 to Feb 2019Container adoption and production orchestrationDocker · Kubernetes · PackerMedia and high-traffic
  2. 28May 2016 to Aug 2018An on-premises private cloud with self-service core servicesOpenStack · Ansible · TerraformMedia and high-traffic

2012 to 20167 projects

  1. 29Mar 2015 to Apr 2016An HPC compute cluster for an internal development cloudKVM · xCAT · OpenHPC · SlurmMedia and high-traffic
  2. 30Jan 2015 to Dec 2016CDN configuration captured and audited under version controlAkamai · Python · SubversionMedia and high-traffic
  3. 31Sep 2014 to Jun 2017Operational wrappers over load-balancer, firewall and storage APIsPerl · Python · NetAppMedia and high-traffic
  4. 32Jun 2014 to Dec 2016Version-controlled DNS zone management for public and internal resolutionBIND · Perl · SubversionMedia and high-traffic
  5. 33Jun 2014 to Jul 2015LDAPS directory refactored for multi-master replication across datacentersOpenLDAP · Perl · LinuxMedia and high-traffic
  6. 34Mar 2012 to Mar 2014Continuous integration across development, staging and productionJenkins · PHPUnit · SeleniumMedia and high-traffic
  7. 35Jan 2012 to Mar 2014Provisioning automation for physical and virtual hostsPuppet · PXE · Kickstart · BashMedia and high-traffic

Before 20125 projects

  1. 36Aug 2011 to Mar 2014A configuration-management baseline across core servicesPuppet · PostgreSQL · Apache · MySQL · MemcachedMedia and high-traffic
  2. 37Jun 2011 to Sep 2013Heterogeneous virtualization consolidated onto one hypervisorKVM · CentOS · libvirtMedia and high-traffic
  3. 38Mar 2010 to Dec 2010Migration of newly acquired sites into the hosting estateLinux · Apache · MySQLMedia and high-traffic
  4. 39Jan 2010 to Dec 2010Configuration modules and versioned deployment for core web servicesPuppet · Apache · MySQL · PostgreSQLMedia and high-traffic
  5. 40Nov 2009 to Dec 2010Filer and load-balancer operations for a high-traffic estateNetApp · Big-IP · LinuxMedia and high-traffic
The loomSpecified properly, combed properly, and undocumented. Most of the record above began as a question about one unit and turned out to be a question about this.

Problems people call us about

Every situation we see often, taken from real projects and anonymised. Some name an industry, some name a problem, because a platform problem arrives the same way in every sector.

  1. 01
    E-commerce & Direct-to-Consumer

    You've outgrown a WordPress/WooCommerce store and want a fast headless storefront, but you don't want to build and secure your own checkout, and guest purchases (including ones made before an account exists) still have to unlock the right account, with refunds reversing access.

    How we would approach it

    Rebuild the front end as a headless React/TypeScript storefront with checkout kept on a hosted commerce platform, served by a single Go service on Cloud Run. Purchases arrive as HMAC-verified webhooks that pass through an idempotency ledger and then three-way identity resolution, a signed token bridge, then an email match, then a pending-access queue claimed on next login, so even a guest checkout binds to an account, and refunds revoke entitlement by reason code.

    • Go
    • TypeScript
    • MySQL
    • Cloud Run
    • Secret Manager
    • Google Cloud
  2. 02
    Enterprise SaaS & platform teams

    As the fleet grows to hundreds of services across several regions, the platform team becomes the bottleneck: reliability and operational maturity are uneven and invisible, and engineers open tickets for basic questions like 'can this cluster reach that host on that port?'

    How we would approach it

    Automate the maturity audit; score every service against a fixed rubric by mining Git, CI, and observability data, keeping the history in BigQuery so trends are queryable and served through a dashboard. Give engineers self-service network diagnostics that run from inside the target cluster as ephemeral Kubernetes Jobs (correct network position, torn down after each run), so the common answers no longer need a human in the loop.

    • Go
    • BigQuery
    • Kubernetes
    • GKE
    • Terraform
    • Google Cloud
  3. 03
    Non-profit & education

    Your system of record is a SaaS you can't modify, and it only emits a daily spreadsheet that's a 31-day rolling window rather than a running total, so summing snapshots double-counts and naively diffing them reports 'lost' donors who did nothing. The same data has to drive both a sensitive internal view and a public page that must not leak names or dollar figures.

    How we would approach it

    Reconstruct the missing daily event stream by diffing consecutive snapshots, modeling window roll-off as its own category so gifts aging out aren't reported as churn, and refuse to compute the misleading cumulative total, naming every field for what's actually true of windowed data. Enforce the public/private split at the API boundary with a separate DTO that has no sensitive fields by construction, served as a stateless Next.js app on Cloud Run reading object storage through a bound service account, with computed results cached behind a short-TTL freshness check.

    • TypeScript
    • Cloud Run
    • Google Cloud
  4. 04
    Fintech & regulated

    Money moves through a third-party processor's webhooks, which retry and arrive out of order, so you risk double-provisioning and failing to reverse on refund, and auditors need every discrepancy visible. The data is regulated: it can't leave an approved region and secrets can't sit in the build artifact.

    How we would approach it

    Claim an idempotency ledger keyed on (order, event) atomically before any side effect so a grant can never double-run, revoke on refund by reason code, and when a paid amount doesn't match the expected price still provision but record the discrepancy for reconciliation instead of silently failing a paying customer, plus alert on the silent-failure class where you correctly return 200 to the processor but a downstream step failed and no 5xx exists to catch it. For the data itself: verified TLS with a pinned CA and a startup check that reads the actually-negotiated cipher rather than trusting config, secrets fetched at runtime from a secret manager, and any automated state change gated behind human approval.

    • Go
    • PostgreSQL
    • Cloud Run
    • Secret Manager
    • Google Cloud
  5. 05
    Media & high-traffic

    Public read traffic is spiky and the read path recomputes expensive aggregates or hits a slow upstream on every request; meanwhile large file downloads on poor mobile networks get severed by default request timeouts and full-response buffering, and the public surface must never expose internal fields.

    How we would approach it

    Cache computed results at TTLs tuned per surface, using a cheap short-TTL listing/version check as the freshness signal so you're never blind to new content for more than a few seconds, and run stateless containers on Cloud Run behind a global HTTPS load balancer with CDN-fronted object storage for assets. Enforce the public boundary with a dedicated DTO whose sensitive fields don't exist, and for large downloads raise the request timeout and remove any middleware that buffers the whole response, since serverless response-size limits will otherwise sever the stream.

    • Go
    • TypeScript
    • Cloud Run
    • Google Cloud
  6. 06
    Teams adopting agentic AI / LLM assistants

    You want to add an LLM assistant to an existing product or ops workflow, grounded in your own data rather than hallucinating, without runaway model cost, without the model taking a destructive action, and without prompt injection riding in through the data it reads.

    How we would approach it

    Build tool-calling agents whose tools are read-only and grounded in your real datastore, so the model explains and recommends from tool output instead of memory, and route per role to the cheapest adequate model across vendors, cheap models for lookups, stronger ones for judgment, with the cost table written down. Keep every mutating action behind a human-approval gate and block destructive tools by default; harden the endpoint by treating tool output as data not instructions, whitelist-validating any user input that flows into a query, isolating sessions, fetching secrets at runtime, and pinning inference to an approved region.

    • Python
    • Go
    • Google ADK
    • Vertex AI
    • Google Cloud
    • Secret Manager
  7. 07
    Teams whose infrastructure is changed by hand

    Your estate was built through a console and the only record of who changed what is a chat message, so nobody can say with confidence what is running, and no environment can be rebuilt from scratch without the one person who remembers.

    How we would approach it

    Put the estate under infrastructure as code and make the repository the system of record: modules for the shapes you repeat, a pull request as the unit of change with its plan attached for review, and reconciliation from version control so drift shows up rather than gets discovered. Tenancy and address allocation become things the code hands out instead of a spreadsheet somebody owns.

    • Terraform
    • Pulumi
    • Atlantis
    • ArgoCD
    • GitHub Actions
  8. 08
    Teams where CI has become the constraint

    Builds take long enough that people batch their changes, the pipeline is flaky often enough that a red run gets re-run instead of read, and there is no way to try a change against anything resembling production before it merges.

    How we would approach it

    Move the pipeline onto Kubernetes-native tasks with runners on your own cluster, so capacity is a decision rather than a queue. Give every pull request a preview environment torn down with it, and move the checks that actually catch things, schema compatibility and contract tests, into the path to merge instead of after it.

    • Tekton
    • Knative
    • GitHub Actions
    • Kubernetes
    • Helm
  9. 09
    Fleets nobody can see into

    Metrics, logs and traces live in three different places, the alerts page on causes nobody recognises at three in the morning, and there is no consistent answer to which services are healthy or who owns them.

    How we would approach it

    Standardise the telemetry: one set of conventions across metrics, logs and traces, and service level objectives written as symptoms a user would notice, so the page a person gets is one they can act on. Then score every service against a maturity rubric mined from Git, CI and the telemetry itself, so the gaps are a list with owners rather than an impression.

    • Prometheus
    • Grafana
    • Datadog
    • OpenTelemetry
    • BigQuery
  10. 10
    Estates moving off on-premises or another cloud

    You are carrying a datacentre or a second cloud you no longer want, the workloads on it were never written down, and the migration keeps stalling because nobody can say what will break.

    How we would approach it

    Inventory what is actually running before anything moves, then land the target as code so the new estate is reproducible from its first day rather than its second year. Consolidate hypervisors, lift what lifts cleanly, rebuild what does not, and keep both sides serving until traffic has moved rather than until a date has passed.

    • Terraform
    • Pulumi
    • Azure
    • Google Cloud
    • KVM
    • OpenStack
  11. 11
    Estates where every host is slightly different

    The servers were built at different times by different people, the differences between them were never documented, and a change that works on one box fails on the next for reasons nobody can reconstruct afterwards.

    How we would approach it

    Write the baseline as code and bring hosts to it in waves rather than all at once, with provisioning automated from bare metal upward so a rebuild is routine instead of an event. What is deployed and what is in version control stay the same thing, and the difference between two hosts becomes a diff somebody can read.

    • Ansible
    • Puppet
    • Packer
    • PXE
    • Linux
  12. 12
    Networks that have outgrown their address plan

    Ranges were handed out as they were asked for, two of them now overlap, DNS is edited by hand in a console, and connecting one more environment means an afternoon of working out what is still safe to use.

    How we would approach it

    Rebuild the address plan with allocation automated rather than requested, and put public and internal zones under version control so every record has an author and a history. Delegation, naming and labelling become conventions the tooling applies instead of documents people are asked to remember, and egress, NAT and the edge rules get the same treatment.

    • Cloud DNS
    • BIND
    • IPAM
    • Shared VPC
    • Terraform

If one of these sounds like your situation, the next step is one call, about ninety minutes.

Start a conversationroot@saguaro.cloud