Your deploy pipeline broke twice this month. The one engineer on your team who thinks in infrastructure is the only person who can fix it, which means both incidents pulled them off the roadmap work you actually hired them for. You have a DevOps req half-written in a Google Doc, and at some point this quarter you are going to have to defend it to your CEO.
Before you post that req, it is worth being precise about what you are buying. A senior DevOps hire is one of the largest recurring commitments on your headcount plan: a senior fully loaded salary in your market, plus recruiting time, plus three to six months of ramp before they are shipping independently. If most of that first year goes toward building deploy pipelines, TLS automation, and rollback machinery that already exists as a product, you have spent a scarce senior salary rebuilding a commodity. If, on the other hand, your real gap is architectural judgment, no product will close it, and you should hire.
This post gives you a framework for telling those two situations apart, and then shows the evidence for why the first one is more common than the job req suggests.
Write down the actual first-year backlog for a first DevOps hire at a 15 to 30 engineer company. It is remarkably consistent across companies: stand up a deploy pipeline so developers stop asking one person to ship for them, automate TLS certificates and domain routing, set up scaling policies so the app survives traffic spikes, build cron infrastructure for scheduled jobs, make rollbacks safe and fast, and get environment variables and secrets out of Slack messages and into something managed. That is the list. It is what "own our AWS infrastructure" means in practice in the job posting.
Notice what all six of those workstreams have in common: they are the same at every company. Your deploy pipeline is not a competitive differentiator. Neither is your certificate renewal automation. This is what we mean by platform-shaped work: repeatable, well-understood, and automatable, because thousands of teams have needed exactly the same thing. An internal developer platform is precisely the productization of that column.
Contrast that with judgment-shaped work: deciding whether your data model should split into services, negotiating your cloud commit, setting a security posture your customers' security questionnaires will accept, evaluating vendors. That work is specific to your company, changes as the business changes, and cannot be bought as a product. The framework in the next section is really just a disciplined way of asking, for each item on your infrastructure backlog, which column it belongs to.
1. Is the work repeatable or novel? Go through your half-written req line by line. For each responsibility, ask whether a hundred other companies at your stage need exactly the same thing. Deploy automation, health checks, autoscaling, cron: repeatable. "Design our multi-region strategy for the EU expansion": novel. If the majority of the req is repeatable, you are writing a job description for devops automation that already exists as software.
2. Does the work need to exist on day one, or does it evolve with the business? Platform-shaped work is table stakes; you needed it yesterday, and waiting four months for a hire to ramp before the pipeline stabilizes is four more months of your current pain. Judgment-shaped work matures alongside the company, which is a reason to have a person who accumulates context over years. Urgent and repeatable points to a platform. Slow-burning and contextual points to a hire.
3. What happens when the person who built it leaves? A hand-built platform has a bus factor of one. Every custom Terraform module, every bespoke deploy script, every undocumented runbook walks out the door with its author. A product platform is documented, versioned, and supported by a vendor whose entire business is keeping it working. If your current fear is "our one ops-minded engineer is a single point of failure," note that hiring a second person who builds more custom machinery does not fix that fear. It doubles the surface area of it.
4. Would the hire spend their first two quarters building what you could adopt in a sprint? This is the question your CEO will ask in different words. If the honest answer is yes, the hire is not wrong, but the sequencing is: adopt the platform first, then hire against the judgment-shaped backlog that remains, if one remains at all.
This framework is a subset of a larger argument about platform engineering at companies too small for a platform team. We wrote about that in more depth in how to run platform engineering without a platform team, and if your infrastructure backlog is longer than the six workstreams above, that post is the deeper dive.
Here is where the argument has to stop being abstract, because "just adopt a platform" is only credible if the platform-shaped column genuinely disappears. Convox Rack is an internal developer platform that installs into your own AWS account (GCP, Azure, and DigitalOcean are also supported) and gives your developers a git-push-adjacent workflow on Kubernetes infrastructure your team owns. The table below maps each item from that first-year DevOps backlog to the Convox primitive that absorbs it.
| Workstream on the req | What a hire builds by hand | Convox primitive |
|---|---|---|
| Deploy pipeline | CI scripts, image registry auth, rollout orchestration | convox deploy |
| TLS and domains | Cert issuance, renewal automation, load balancer config | domain: with automatic certificates |
| Scaling | Autoscaler config, resource requests, capacity policies | convox scale and autoscale triggers |
| Cron jobs | Scheduler infrastructure, job monitoring, retry logic | timers: in convox.yml |
| Rollbacks | Release tracking, revert scripts, incident runbooks | convox releases rollback |
| Environment management | Secrets tooling, per-env config, release coupling | convox env set |
The configuration surface that remains is a single manifest. Here is a complete, deployable convox.yml for a web service with a build, a port, and explicit scale settings:
services:
web:
build: .
port: 3000
scale:
count: 2
cpu: 250
memory: 512That is the whole thing. Behind those eight lines, the Rack provisions load balancing, HTTPS termination, health checking, and rolling deployments that automatically revert if the new release fails its health checks. When you outgrow a static count, you change the scale block to a range with CPU or memory targets and the platform handles the rest; the scaling documentation covers the options. Scheduled work is a Timer: a cron expression, a command, and a service name, with no scheduler to build or babysit.
Two properties matter enormously for the reader who already has one ops-minded engineer. First, this is not outsourcing your infrastructure. A self-hosted Rack installs into your own AWS account: your VPC, your IAM, your billing relationship. Your ops person keeps every control they have today, and because you pay AWS directly, Convox adds no markup on your infrastructure spend. Second, this is leverage for that person, not a replacement of them. Their AWS knowledge still matters; what disappears is the undifferentiated machinery they were going to build and then maintain alone at 2am. The engineer who was your single point of failure becomes the person who governs a documented, supported platform instead of a bespoke one.
Name the cost honestly: adopting the platform is not zero work. Each app needs a Dockerfile and a convox.yml, and if your services are not containerized today, that conversion is real effort measured in days, not hours. Convox offers hands-on onboarding help for exactly this step, but do not budget it at zero when you run the comparison below.
A platform removes toil. It does not remove accountability, and it does not make decisions. There is a category of work that Convox will never do for you, and pretending otherwise would be the kind of overpromise that gets a post like this dismissed.
Nobody but your team can decide your cloud architecture: how services should be factored, where data should live, what your disaster recovery posture is. Nobody but your team owns cost strategy, including reserved instance and savings plan commitments, which, incidentally, remain fully available to you precisely because a self-hosted Rack runs in your own AWS account. Nobody but your team sets security posture, answers the enterprise security questionnaire, or evaluates the next vendor. And someone on your team still owns the AWS account itself: IAM hygiene, billing alerts, the root credentials in a safe place.
If your backlog is dominated by that list, hire. A 25-engineer company handling regulated data, running a genuinely unusual architecture, or carrying a cloud bill large enough that commit negotiation is a six-figure decision has judgment-shaped work worth a senior salary. The point of the framework is not that the hire is always wrong. It is that the hire should be scoped against the judgment column, not spent re-implementing the platform column.
The arithmetic here is structural, and you should run it with your own inputs rather than trust anyone's headline figure. On the hire side: a senior fully loaded salary in your market, plus recruiting cost and the calendar time to fill the role, plus three to six months of ramp during which the pipeline problems you have today continue. On the platform side: the Convox plan cost, which you can read directly on the pricing page, plus your AWS bill, which does not change because you were already paying it and a self-hosted Rack adds no markup to it, plus the days of onboarding effort named above. Put both columns in a spreadsheet with your numbers. For most teams at this stage, the gap between a platform subscription and a senior salary is not close, which is exactly why the question deserves the framework rather than a reflexive req.
Here is the decision matrix in compressed form:
| Decision | When it is the right call |
|---|---|
| Hire | Your backlog is dominated by judgment-shaped work: architecture decisions, security posture, cost strategy, compliance. The deploy machinery is a minority of the req. |
| Adopt a platform | Your backlog is dominated by platform-shaped work: deploys, TLS, scaling, cron, rollbacks, environments. The req exists because developers are blocked on one person to ship. |
| Do both | Both columns are full. Adopt the platform first so the eventual hire spends their ramp on judgment work instead of rebuilding commodity pipelines. |
And here is the cheapest way to validate any of it: run a pilot this sprint. Stand up a Rack in a sandbox AWS account, pick one staging app, write the Dockerfile and the eight-line convox.yml, and time how long it takes from convox apps create to a working HTTPS endpoint. Then have a developer who is not your ops person ship a change to it with convox deploy and revert it with convox releases rollback. If the pilot holds up, you have your answer, and you also have a working staging environment. If it does not, you have spent a sprint, not a salary, finding out.
Hire when your infrastructure backlog is dominated by judgment-shaped work: architecture decisions, security posture, cost strategy, and compliance. If the backlog is mostly deploy pipelines, TLS, scaling, and cron, that is platform-shaped work an internal developer platform absorbs, and the hire should wait until judgment work justifies the salary.
No, and any vendor claiming otherwise is overselling. A platform replaces the repeatable machinery of deploys, scaling, rollbacks, and environment management. It does not make architecture decisions, set security posture, or own your cloud account. It removes toil so the person or people you have spend their time on judgment instead.
Compare a platform subscription plus your unchanged cloud bill against a senior fully loaded salary in your market, plus recruiting cost, plus three to six months of ramp. Convox publishes plan pricing at convox.com/pricing, and a self-hosted Rack adds no markup on the AWS infrastructure you already pay for directly.
No. A self-hosted Convox Rack installs into your own AWS account, so your team keeps IAM, VPC, networking, and billing control, and can use AWS cost levers like reserved instances and savings plans. The platform runs on standard Kubernetes in your account rather than on infrastructure you cannot see or leave.
Ready to run the pilot? The Getting Started Guide walks through installing a Rack into a sandbox AWS account and deploying your first app, and the example apps give you a working convox.yml and Dockerfile to start from.
Create a free account and deploy one staging app this sprint. If you want a second opinion on the hire-versus-platform call for your specific backlog, talk to our team; we will tell you honestly if your situation is the one where you should hire.
