Expertise / DevOps, cloud infrastructure & AI operations

Infrastructure in the repository.
Releases you can repeat.

We build AWS infrastructure as code alongside the product. Environments, deployments and the way back from a bad release live where your team can review them, rerun them and take them over.

delivery-record3 client projects
  1. Better BreastfeedingAWS CDK · Lambda · ECSClient, API and infrastructure in one TypeScript Nx workspace
  2. Avant AssessmentData centerAWS · CloudFormation · DockerServices migrated to AWS with automated builds
  3. Blue Note Therapeutics / attuneAWS CDK · CloudFormation · multiple environmentsAutomated builds within a documented quality-management process

From our client work

Three starting points.
The same habit: write it down.

A new platform, a data-center migration and a rebuild under an evolving product. In each, the environment ended up described in code: reviewable, repeatable and transferable to the people who run it.

Better Breastfeeding self-assessment and Virtual Breastfeeding Specialist recommendations on a laptop
Better Breastfeeding · the product the infrastructure serves.

Illustrative · simplified from the published technology summary

Nx workspace · TypeScript
  • client React
  • api Nest.js · Prisma · PostgreSQL
  • infra AWS CDK
deploys to
AWS
  • Lambda
  • ECS

01 / New platform · Better Breastfeeding

One codebase for the product and the cloud it runs on.

Dr. Linda Dahl’s team brought the clinical guidance and video library. We designed and built the assessments, recommendation logic and check-ins, along with the AWS deployment beneath them.

Client, API and infrastructure shared one TypeScript Nx workspace. AWS CDK, Lambda and ECS formed part of the deployment architecture.

Why it matters for your team

When the interface, the API and the infrastructure share a language and a repository, an infrastructure change can go through the same review as a feature.

Read the Better Breastfeeding case
Avant Assessment administrator list of test instances and scores on a laptop
Avant Assessment · administration on the shared platform.

Illustrative · simplified from the published technology summary

Before
  • Data center
  • Portals evolved separately
migrated to
AWS · shared platform
  • defined in CloudFormation
  • packaged as Docker images
  • delivered by automated builds
  • services Kotlin / Java · Spring Boot · PostgreSQL

02 / Cloud migration · Avant Assessment

From a data center to AWS, with a live service to protect.

Avant’s family of language-testing products had grown in different directions. Alongside the testing experience and reporting, we moved services from a data center to AWS and brought the product family onto a shared cloud-based platform.

CloudFormation, Docker and automated builds made that platform something the team could build again, not only something that had been moved.

Why it matters for your team

A migration is a chance to capture the environment as templates and images. The next environment then becomes a repeatable build rather than a reconstruction.

Read the Avant Assessment case
attune mobile app screens with a participant welcome view and program library
Blue Note Therapeutics / attune · the evolving mobile product.

Illustrative · simplified from the published technology summary

One definition
  • written in AWS CDK
  • synthesized to CloudFormation
  • run by automated builds
creates
Multiple environments
  • Environment
  • Environment
  • Environment

Inside a third-party quality-management system’s documented development process

03 / Product evolution · Blue Note Therapeutics / attune

Rebuild the foundation while the product keeps moving.

Blue Note was extending attune, a mobile program for people living with cancer, with group communication. We restructured the earlier application in TypeScript across front and back end, introduced automated builds and described the infrastructure in AWS CDK and CloudFormation, with multiple environments.

The work ran within a third-party quality-management system’s formally documented development environment.

Why it matters for your team

When every environment comes from the same definition, differences are deliberate configuration. The history of a change is in version control, where a reviewer can follow it.

Read the Blue Note Therapeutics case

The release path we build

A change should reach production the same way every time.

Whatever the stack, we aim for one path from a pull request to a running system, with a rehearsed path back.

  1. 01 / Change

    Code and infrastructure in one pull request.

    An application change and the infrastructure it needs are reviewed together, not coordinated by message.

  2. 02 / Build

    The same artifact, every time.

    Automated builds produce the container image or function bundle that every environment receives.

  3. 03 / Preview

    See the infrastructure diff first.

    CDK and CloudFormation show what will be created, changed or replaced before anything happens.

  4. 04 / Promote

    One definition, several environments.

    Environments differ by configuration, not by hand edits someone has to remember.

  5. 05 / Operate

    Signals, and a way back.

    Logs, alarms and a rollback or restore that has been exercised, with an agreed owner for each.

A useful test

Could someone else on your team rebuild production from the repository? If the honest answer is “not without a particular person,” that is usually where we start.

AWS building blocks

Match the AWS service
to the workload.

We work across AWS compute, traffic and definition tools. The right combination depends on how the work arrives, how long it runs and who will operate it.

The workloadOften a fitWhat we weigh
Event-driven or uneven workWebhooks, scheduled jobs, bursts of requestsAWS Lambda · serverlessOn-demand execution without managing servers; execution limits, cold starts, concurrency and capacity pricing need a design.
Long-running servicesAPIs, workers, anything with steady loadContainers on Amazon ECSThe image tested is the image deployed; capacity, scaling and health checks are yours to define.
Traffic into servicesRouting, TLS and healthElastic Load Balancing (ALB)Route by path or host, terminate TLS and use target health checks to guide traffic. Define deployment and failure behavior explicitly.
Describing all of itSo it can be reviewed and rebuiltAWS CDK · CloudFormationCDK when the team wants infrastructure in the same language as the application; CloudFormation templates when a declarative file suits better.

General engineering scope. The project panels above list what each published case used; this table is not a record of client deployments.

AI operations

A model change is a release, too.

AI features add moving parts that ordinary pipelines miss: a model version, a prompt, a configuration, an evaluation set. We put them under the same review and release discipline as code.

  • Versioned model, prompt and configuration changes, tied to the release that ships them
  • Evaluated against representative examples before release, not only after complaints
  • Reviewed by a person who can approve, hold or roll back the change
  • Observed in use, so a behavior shift is noticed and traced to its cause

Model serving · LearningWrite

Writing-response auto-scoring used a fine-tuned language model built with PyTorch and Hugging Face and deployed through TorchServe, inside a product for students and educators. LearningWrite was an affiliated partner company owned by Mike Biglan.

Read the LearningWrite case

Our own practice · DevSwarm

We build DevSwarm for sibling company 21st Idea Inc. Developers direct parallel AI coding work in it; review and release remain decisions people make.

Explore DevSwarm
Designing the AI feature itself? See AI products & systems

What an engagement leaves behind

Yours to run,
not ours to remember.

Scope follows the work: a first environment, a migration, a release path for an existing product or a handover.

01

Infrastructure as code

CDK or CloudFormation in your repository, with each environment created from it.

02

An automated release path

Builds, checks and deployment connected to review, including infrastructure previews.

03

Signals and recovery

Agreed alarms and logs, plus rollback and restore paths exercised within scope.

04

An operating handover

Runbooks, access responsibilities and a walkthrough with the people who will run it.

Where it stops. Managed operations, on-call coverage and incident response are agreed separately; a delivery engagement does not include round-the-clock service. Security, privacy and compliance responsibilities are set out with the rest of how we work.

A useful first conversation

Could your team rebuild
production tomorrow?

Bring the current deploy steps, the environments you run and the release that worries you most. We will talk through where we would start.

Talk about your infrastructure