Infrastructure you can rebuild from a git clone.
We design, build and operate AWS environments for small and mid-sized products: every resource in code, dev/staging/prod separated from day one, deploys that take minutes, and monitoring that tells the truth.
You do not need Kubernetes. You need environments that match, a deploy you trust, backups you have actually restored, and an AWS bill without surprises. We have written a 29-article series on exactly this because it is what we do every week for our own products and our clients.
Our standard is AWS CDK in TypeScript, containers on ECS/Fargate or App Runner, RDS or Aurora, three accounts under one organisation, GitHub Actions with OIDC (no long-lived keys), and observability that does not lock you into one vendor. When your platform is different, we adapt; the principles do not change.
Designed, deployed and operated.
Architecture and account structure
Landing zone, dev/staging/prod accounts, networking, IAM boundaries and a cost model, sized for what you run today and what you will run next year.
Infrastructure as code with CDK
Every resource in TypeScript, reviewed in pull requests, deployed the same way to every environment. No console clicking, no drift.
Containers without the cluster tax
ECS/Fargate or App Runner for web services and workers, distroless images, health checks that mean something, zero-downtime deploys.
CI/CD and preview environments
GitHub Actions with OIDC roles per account, build-only-what-changed monorepos, a preview environment per pull request, one-command rollbacks.
Observability and incident readiness
Logs, traces and alerts that do not depend on one vendor, dashboards people look at, and a runbook for a team without on-call.
Cost and security hygiene
NAT gateways, savings plans, secrets management, WAF, rotation without downtime, backups tested by restoring them.
What you get
- A CDK codebase that recreates your whole environment from an empty account
- Separate dev, staging and production with a documented promotion path
- CI/CD pipelines with OIDC, preview environments and rollback
- Monitoring, alerting and an incident runbook written for your team
- A cost review with concrete savings and the reasoning behind each one
This is for you if
- Your infrastructure was set up by hand and nobody dares to touch it
- Deploys are scary, slow or done by one person who cannot go on holiday
- Your AWS bill grew faster than your traffic and you want to know why
How an engagement runs
You get a senior engineer who delivers like a small team — with a transparent hourly rate, weekly reporting, and no agency overhead. Scale hours up or down as the project needs.
- 01Assessment — a week of reading your accounts, pipelines and bills; you get a written report with priorities.
- 02Foundation — accounts, networking, CDK skeleton, CI/CD with OIDC, and the first service deployed the new way.
- 03Migration — services and data moved environment by environment, with rollback at every step and no big-bang weekend.
- 04Operate — monitoring, cost reviews and on-demand support, or a clean handover to your team with training.
Questions we hear before every engagement
Why not Kubernetes?
For most products under a few hundred requests per second, ECS/Fargate or App Runner deliver the same reliability with a fraction of the operational load. We use Kubernetes when there is a real reason (existing platform team, specific workloads), not by default.
CDK or Terraform?
On AWS we prefer CDK in TypeScript: your infrastructure and application share a language, a reviewer and a test runner. We are comfortable with Terraform when you already have it or run multi-cloud. Infrastructure as code is the requirement; the tool is a choice.
Can you migrate us without downtime?
Usually yes. We move environment by environment, keep the old path live until the new one is verified, and treat schema migrations as a discipline rather than an event. You will know the risk of each step before we take it.
Do you provide on-call?
We provide monitoring, alerting and a runbook designed for a team that does not have on-call, plus on-demand support during business hours. We do not sell 24/7 pager coverage; we build so that you rarely need it.
How much can we save on AWS?
It depends on what is wrong. Typical findings are idle NAT gateways, unattached volumes, oversized databases, missing savings plans and logs kept forever. We show each saving with the reasoning so you can decide.
How we think about it
How we build cloud and DevOps: three accounts, one CDK codebase, and no cluster
We operate AWS for our own products and for a client platform with real users and real money flowing through it. Between...
September 2026
Dev, staging and prod from day one: why a team of three shouldn't wait
"We'll separate environments later, when we have users." We've heard that sentence from every small team we've...
September 2026
You don't need Kubernetes. You need a good Dockerfile and a place to run it.
Every few months a team of three to five engineers asks us whether they should move to Kubernetes. The application is a...
September 2026Want infrastructure you can trust?
Flexible hourly / time-and-materials engagements, fully remote, B2B. Direct communication with the engineer doing the work — no hand-offs, no sales pitch.