DevOps consulting for teams without a platform team
My DevOps consulting is for product teams of roughly three to thirty engineers who need deploys to be fast and boring, production to be visible, and on-call to be survivable – but who don’t need, and can’t afford, a platform team of ten. I set up the pipeline, the infrastructure code and the observability with your engineers, then hand it over.
I’ve shipped production systems for two decades, including platforms with millions of users. What follows is the short list of things I’ve found actually help.
What I set up
- CI that’s fast enough to trust. Under ten minutes from push to green for the common case: dependency caching, parallel test shards, and flaky tests quarantined and fixed rather than retried forever.
- Continuous deployment from main. Every merge deploys automatically, with health checks and automatic rollback. Database changes use expand–contract so code and schema can deploy independently. More in zero-downtime deployment.
- Feature flags so releasing a feature is separate from deploying code.
- Infrastructure as code with Terraform or OpenTofu, reviewed in pull requests like everything else, with remote state and locking.
- Preview environments per pull request where they’re worth the cost.
- Secrets in a manager (AWS Secrets Manager, GCP Secret Manager, Doppler or similar), not in .env files passed around on Slack.
Observability before more dashboards
Plenty of teams have dashboards everywhere and still can’t answer “why is checkout slow right now?”. The fix is a small set of things done properly:
- Structured logs with a request ID that follows a request through every service and background job.
- Traces via OpenTelemetry, sent to whichever backend you already pay for.
- RED metrics per endpoint – rate, errors, duration – plus queue latency for background jobs.
- A handful of SLOs on the user journeys that matter (sign-in, checkout, the core workflow), with alerts on error budget burn rather than on CPU percentages.
- Alerts that are actionable. Every page needs a runbook link and a reason a human must act now. Everything else is a ticket.
Site reliability engineering for a small team
Full SRE practice was designed for companies with dedicated reliability teams. The parts that transfer well to a team of ten are simple: a written on-call rotation with fair load and real handovers (on-call rotation), blameless postmortems with tracked follow-ups (postmortem template), and a weekly look at the alerts that fired, so noisy ones get fixed or deleted.
I track progress with the DORA metrics: deployment frequency, change lead time, change fail rate, failed deployment recovery time and, more recently, deployment rework rate. They’re a reasonable proxy for whether the work is helping.
What I’ll usually talk you out of
- Kubernetes for a handful of services. Managed containers – ECS on Fargate, Cloud Run, or a PaaS – carry far less operational load. Kubernetes earns its keep with many services, many teams, or specific scheduling needs.
- A service mesh before you have the problems it solves.
- An internal developer platform for twelve engineers. Good CI templates, a clear README and one deploy command are your platform at that size.
- Multi-cloud for resilience. Multi-region on one provider is simpler and covers most realistic failures.
Platform engineering consulting makes sense later, when several teams are rebuilding the same pipeline. Before that, standard tooling configured well beats custom tooling.
Is this you?
Good fit: deploys are manual, slow or scary; incidents are found by customers; one person holds all the infrastructure knowledge; or you’re moving platforms (cloud migration) and want to get the foundations right on the way. Not a fit: you need 24/7 managed operations from a provider. That’s a managed service company, and they’re good at it.
Questions
What does a DevOps consultant do?
A DevOps consultant improves how software gets from a developer’s laptop to production and how it’s run once there: CI/CD pipelines, infrastructure as code, monitoring, alerting and incident response. A hands-on one builds these with your team rather than writing recommendations.
Do we need a dedicated DevOps engineer?
Not always. Many small teams do well with product engineers owning their own deploys, provided the pipeline and infrastructure are simple and well documented. A dedicated hire makes sense once infrastructure work takes a meaningful share of someone’s week, every week.
What does CI/CD consulting cover?
Speeding up and stabilizing the build, test and deploy pipeline: caching, parallelism, flaky test cleanup, automated deploys with health checks and rollback, safe database migrations, and feature flags. The aim is small, frequent, low-risk releases.
Should we use Kubernetes?
For most small teams, not yet. Managed container platforms give you autoscaling, rolling deploys and health checks with much less to operate. Kubernetes pays off with many services and teams, or when you need control those platforms don’t offer.
Deploys slow, scary or manual?
Tell me how code gets to production today. In a two-week sprint I’ll fix the worst bottleneck in the pipeline and get the first real alerts in place.
GMT+2 · Full EU overlap · US East mornings