Enterprise scale. Indie execution. Fully shipped.
I designed and built the deployment system behind a fleet of thousands of production Kubernetes clusters at a Fortune 50 company, and took deployments to that fleet from weeks down to seconds. I still own it. Around it I have written the controllers that keep the fleet honest, the authentication path teams use to reach clusters at all, the secrets tooling, and the post-deploy verification that catches a release which reconciled cleanly and is quietly unhealthy.
That is the scale the work below is priced against: unattended, across thousands of clusters, where one bad assumption is wrong in a thousand places at once.
On my own time I build and ship finished products, and that is most of what I can show you.
The person who scopes your work is the person who writes it. And I have spent years inside the stack you would be handing me, so the first week goes to your problem instead of my onboarding.
I write software you can check instead of software you have to trust. A single binary where a binary will do, defaults that work with the network unplugged, and output you can verify on your own machine.
Start here
Builds land between $30,000 and $95,000 and are priced after scoping. Most people start smaller than that, one of two ways. Both are fixed-price, both come off a build if one follows, and both tell you your number before you commit to anything.
| Platform Teardown | $12,000 · three days | A written, ranked teardown of your tenancy, secrets, RBAC, and blast radius. Start here when you suspect the platform has soft spots but cannot say where. |
| Advisory Day | $3,500 · per day | One decision or design taken end to end, with a written recommendation after. Start here when you know the problem and want someone who has solved it before. |
Narrower than either? A second opinion is $950 for independent judgment on one decision, in writing, within three business days.
What I have built
I would rather show you working software than a list of technologies.
Most of my professional work is internal and stays that way, so I will describe it without naming it. I work on a platform team of systems engineers that owns how software reaches a fleet of thousands of production clusters, and who is allowed to do what once it is there. The core is a deployment service I designed, built, and still own: the system that ships software to every one of those clusters, built on my own concepts over Vault, Kubernetes, Flux, and Kustomize. It took deployments to that fleet from weeks or months down to seconds, and it is the work I am proudest of, for what it has done for the teams that lean on it. Around it I have written controllers that replicate resources fleet-wide and alert when reality drifts from intent, the authentication path teams use to reach clusters at all, secrets tooling against our managed key stores and Vault, command-line tools, post-deploy verification that catches a release which reconciled cleanly but is quietly unhealthy, and the metrics and alerts that watch it.
The most creative, and maybe the most impactful, is a black-box recorder for Kubernetes: it captures cluster activity, replays it visually after an incident, and drafts the postmortem from what actually happened rather than from what anybody remembers.
Alongside those sit a body of smaller internal tools my teams reach for daily and that I am quietly just as proud of: secrets and access utilities, and a reconciler that reads the work you actually did against the tickets that said you would, in both directions, then files the missing tickets itself.
All of it runs unattended across that fleet, where one bad assumption is wrong in a thousand places at once. At that scale you stop trusting anything you cannot verify, and you write for the day it fails rather than the day it ships.
What I build on my own time I can show you, and it covers most of what a backend or platform team ends up needing. A sample, by category:
| Secrets | A library and CLI over SOPS spanning AWS KMS, GCP KMS, Azure Key Vault, Vault Transit, age, and PGP: editor workflow, rotation on demand or by age, parallel tree walks, recipient auditing and drift, Shamir threshold-of-N, and a pre-commit hook that blocks plaintext. Every release runs end to end against real backends, not mocks. |
| Identity | A JWT service with a daemon, a Kubernetes controller, an admission webhook, and HTTP and gRPC middleware. Asymmetric only by design, multi-key rotation, JWKS with cache-aware fetching, revocation, and benchmarks beside the code for every supported algorithm. |
| Fleets | Kubernetes drift detection across twenty-four dimensions that uses the fleet itself as the statistical baseline, so there are no rules to author. Ships a CRD and controller, an admission webhook that denies deviating pods, a Helm chart, leader election, scoped RBAC, an audit log, and cosign-signed images. A separate project does the equivalent job for mixed self-hosted fleets that are not running Kubernetes. |
| Developer tools | A deterministic text engine shipped to thirteen surfaces: CLI, web, VS Code, JetBrains, an LSP server, browser extensions, Obsidian, npm, a Go library, an HTTP API, Slack, MCP, and a GitHub Action. A commit-history rewriter that verifies it conserved every byte of your work. A tool that executes the install steps in your README and reports where they break. |
| Applications | A calendar workflow engine driving Microsoft Graph, Google, iCloud, and CalDAV behind one interface, where the approval rides the invite itself. A weather client. An encrypted notes application with its own published file format. |
Roughly half of it is application work rather than infrastructure, built for people to use directly instead of services running behind other services.
These ship like products rather than experiments: Homebrew taps, signed releases with provenance, Helm charts, fuzz tests, benchmarks beside the code, and documentation somebody could actually follow. Software nobody can install is not finished, and that is the standard I bring to client work.
Nearly all of it is public, at github.com/dcadolph, and every claim above that carries a link goes straight to the code behind it. A small subset of the applications are closed source, which is why a few lines up there name a thing without offering you the repository. The projects page walks through the ones worth starting with. Read the source before you talk to me.
How AI fits in
Yes. Heavily. It is 2026 and an engineer claiming otherwise is either lying or slower than they need to be.
What it changes is throughput, and the projects page is the argument. A secrets library across six backends, a fleet drift detector, a JWT service with a controller and a webhook, and the rest of it, from one person. That is the part that would not exist otherwise. What it does not change is the standard. I set what has to be tested and what counts as good enough, against standards I worked out years before any of this existed. I read the code instead of accepting it, and I own it when it breaks at three in the morning. The model drafts. I decide.
I do not ship systems I cannot explain, could not rebuild, or cannot maintain. How much of this ends up inside your software is a design decision: some of what I build has no model in it at all, some treats a model as an optional upgrade you can switch off, and some is meant for agents to drive. Nothing I hand you breaks because a vendor changed a model.
If that matters to you before you sign anything, here is the longer answer.
What I get called for
These are the situations people email me about. The specifics differ every time, but the shape rarely does. Something became business-critical and nobody owns the hard parts of it.
| A service nobody owns | The Go service in the middle of your platform was written by someone who has since left, and every change to it now costs a week of archaeology first. |
| Tooling stuck in the backlog | Your team knows exactly which internal tool would give them back a day a week, and it has lost the quarterly cut four times running because shipping the product always wins. |
| A controller that breaks at scale | Reconciliation that behaved fine at fifty clusters does not behave now, and the failure only reproduces under real load. |
| Load-bearing systems with no owner | Secrets, identity, or deploy tooling that works, that everything depends on, and that nobody left understands well enough to change safely. |
Engagements
I work with platform, infrastructure, and backend teams that know what needs to be built but do not have the engineering capacity to build it. I take on narrowly defined systems work and deliver it as a fixed-scope engagement.
Work is scoped up front and delivered async, to a date we agree on. You get a finished outcome on time, not presence in your standups. That discipline is why the scope and the price hold. To keep it, I take on a maximum of one active build engagement at a time. Reviews and advisory work are scheduled separately.
Fixed scope, defined acceptance criteria, and staged delivery. We agree what finished means before I start, and you know your number before you commit to anything.
Second opinion
$950 · written, within three business days
Independent technical judgment on one decision, before you build on it.
Send me one thing: a design document, a pull request, a single service or module, or a plain description of the decision you are arguing about. One of those, not all four, and small enough that one person can read it properly in an afternoon. I read it and send back a written response covering what I would do, what I would not, what I think breaks first, and what I would need to know before committing either way. No call, no scheduling, no discovery process.
What this looks like
Situations people send me:
| A design you have not committed to yet | An architecture document, an RFC, or a plan your team is about to start building. You want to know what breaks before you build it rather than after. |
| A pull request nobody senior can review | Code that works, that matters, and that nobody left is confident enough to approve. |
| One service you inherited | Something load-bearing you did not write and cannot safely change. |
| A decision two people disagree about | Both positions are defensible, both people are reasonable, and somebody has to pick. |
What comes back:
| What I would do, and what I would not | With the reasoning, so you can argue with it rather than take it on faith. |
| What breaks first | The failure I would expect, and roughly what triggers it. |
| What I would need to know | The questions I would ask before committing either way, so you can see what is still unresolved instead of mistaking my answer for certainty. |
| Within three business days | Written. No call, no scheduling. |
Spend $950 on an independent review before you commit five or six figures to execution. If the answer is that you should not build it, or that I am not the right person to build it, you get that in writing too. If it turns into a larger engagement, the fee comes off it.
Anything wider than one of those is the Advisory Day below.
When a review is not enough
Two engagements for the point where you need somebody inside the problem rather than reading about it. Both credit toward a build if one follows.
Advisory Day
$3,500 · per day
The lightest way to start, and often all a team needs.
Bring me a decision you are stuck on, an architecture that needs a second set of eyes, an API or a Kubernetes controller that should be written properly, or a problem your team wants to work through with someone who has seen it before. An advisory day takes one decision or problem end to end: a focused block of my full attention and a written recommendation after. Not a metered hourly clock, and not open ended.
What this looks like
Situations people bring:
| A decision you are stuck on | Two defensible paths, real consequences either way, and nobody in the room has done it before. |
| An API or controller worth designing before writing | The interface everything else will depend on, where getting it wrong is expensive to undo. |
| An architecture that needs a second set of eyes | Someone outside the politics who has run something like it at scale. |
| Scoping a build | If you want something built, this is where we work out exactly what it is and what it costs. The fee comes off the build. |
What comes back:
| A focused block of my full attention | One decision or problem taken end to end. |
| A written recommendation after | A recommendation with reasoning, not a page of notes from the call. |
| A scope and a number, if you want one | So a build is priced against something I have looked at rather than something I imagined. |
Anything running longer than a couple of weeks costs you less as one of the fixed-price engagements below, and I will tell you when that is the case.
Platform Teardown
$12,000 · three days, and the written report
Before you spend real money, find out whether you need to.
I go through your platform and tell you what I find: how your tenancy is put together, where quotas and namespaces are loose enough to matter, how secrets get to the workloads that need them, and what happens to everyone else when one thing breaks.
What this looks like
What I go through:
| Tenancy and isolation | How your tenants are separated, and what one of them can do to the others on a bad day. |
| Quotas and namespaces | Where limits are loose enough that one workload can starve the rest. |
| Secrets delivery | How secrets reach the workloads that need them, and who else can read them on the way. |
| Access and RBAC | Who can do what, and who no longer should. |
| Blast radius | What happens to everyone else when one thing breaks. |
What comes back:
| A written list, ordered by how much it will hurt | Not a findings dump. Ranked, so you know what to do first. |
| A scoped engagement, if one makes sense | And these three days come off the price if you book within sixty days. |
| An honest nothing serious here | If that is the answer, you get it in writing instead of a proposal. |
If nothing serious turns up, I will tell you that instead of selling you something.
When you know what needs building
Fixed-scope implementation. Priced after scoping, delivered to a date we agree on.
Backend systems and tooling
Most land between $30,000 and $65,000
Go services and the APIs in front of them. Kubernetes controllers and operators whose reconciliation and admission hold up under load. Command-line tools your team will use instead of the shell script they are replacing. Instrumentation that produces dashboards somebody actually opens. Code that talks to Vault, to the Kubernetes API, and to the rest of what your platform runs on, written by someone who has done it against a fleet in the thousands.
I scope it, build it, test it, document it, and hand it over running, with your team able to maintain it after I go. We agree in writing on what finished means before I start, which is what keeps a fixed price fixed for both of us.
A fixed price means the estimate is my problem, not yours. If the work runs longer than I judged, that is my cost to absorb and your number does not move. That is what you are buying above a daily rate, and it is why these are not priced as days.
What this looks like
Shapes this usually takes:
| A controller and the webhook beside it | Reconciliation for something your platform does by hand today, plus an admission webhook that rejects bad configuration before it lands instead of paging somebody after. |
| A command-line tool that retires the shell scripts | The five scripts everyone copies between machines, replaced by one binary with real flags, real errors, and a tap your team installs from. |
| A service in front of something fragile | A Go service between your teams and Vault, the Kubernetes API, or whatever else has grown a folklore of workarounds. Auth handled, failure modes handled, behavior you can read. |
| Instrumentation for a system nobody can see into | Metrics, traces, and dashboards for the thing that only tells you it is broken by breaking. |
| Secrets tooling | Discovery across repos and clusters so you know what you have, rotation that runs on a schedule instead of when somebody remembers, drift and recipient auditing so access reviews stop being a spreadsheet, and a pre-commit hook that makes committing plaintext impossible rather than discouraged. |
What lands in your repo, every time:
| The code and its tests | Tests you can read and run yourself, not a coverage number. |
| CI that builds and releases it | It ships the same way after I leave as it did while I was here. |
| Documentation you can follow | Verified by running it, not by reading it. |
| Whatever the artifact needs | Helm chart, signed release, container image, Homebrew formula. |
| A handoff session | Plus me reachable afterward when your team hits something surprising. |
Price moves with how many systems it has to talk to and how much of the behavior is still undecided when we start. Smaller, well-defined pieces of work come in under that range and are worth asking about. Tell me what you need and I will scope it and give you the number before you owe anything. The number we agree on is the number you pay, and the delivery window is set during scoping rather than guessed at here.
This is the work I have the most evidence for and the easiest to check before you hire me. Everything under “What I have built” above came out of the same process.
Secrets at scale
Most land between $35,000 and $80,000
Vault is running. Nobody is quite sure what is in it anymore.
I have run secrets at a scale where the tree cannot be walked by hand, written the tooling that made bulk operations safe to run, and set the policies underneath it. The work below is that, done for you.
What this looks like
Situations this fits:
| Paths nobody can inventory | Hundreds of thousands of them, many added by people who have since left, and no safe way to walk the tree and find out what is there. |
| Policies that accreted | Access rules shaped by a long series of tickets rather than by how your organization is organized. |
| Bulk operations everyone is afraid to run | Rotation, re-keying, or restructuring across the whole tree, where doing it by hand is impossible and doing it wrong is unrecoverable. |
| Access reviews done in a spreadsheet | Recipient auditing and drift detection that currently depends on somebody remembering to look. |
What you get:
| Tooling built for your paths and your quirks | In Go, concurrent, with a dry run, so the operation your team cannot do by hand becomes one command they can trust. |
| Policy and path structure that matches your org | Shaped by how your teams work rather than by how the tutorial laid it out. |
| The standard handover | Code, tests, CI, documentation, runbooks, and a session where your team takes ownership. |
Usually HashiCorp Vault, though the tooling work is the same wherever your secrets live. Price moves with how many secrets you hold and how many systems consume them. The teardown above prices it to the dollar before you commit to the build.
Replace the subscription
Roughly a year of what you pay now, and most land between $40,000 and $95,000
You are renting software you could own.
The invoice arrives every month. It goes up when the vendor reprices, it goes up again when you add people, and five years in you have paid for the product several times over and own none of it. Meanwhile your team uses four of its forty features and works around two of those.
I build the replacement once. You own the source, you run it where you want, and the seat count stops being a budget conversation.
What this looks like
Where this works:
| Per-seat pricing you outgrew | Cheap at twelve people, a real line item at eighty, and nothing about the product got better in between. |
| Four features out of forty | You are buying a platform and using a corner of it. The corner is a few weeks of work. |
| A price that jumped after an acquisition | The vendor got bought, your plan disappeared, and its replacement costs triple for the same thing. |
| A form, a database, and a report | Under the marketing site, that is the entire product. Those are cheap to build and expensive to rent. |
| Data you would rather keep | When the honest reason you are unhappy is that your records live on hardware you do not control. |
What you get:
| The whole thing, source and all | Yours on final payment. No license, no seats, no tiers, nothing to renew. |
| Running where you put it | Your cloud, your cluster, or one machine in a closet. Your software, your call. |
| Your data out of theirs | Migration off the incumbent, verified against real records rather than assumed. |
| The standard handover | Code, tests, CI, documentation, and a session where your team takes ownership. |
When this is a bad idea, and I will say so before you pay me. Plenty of subscriptions earn their keep. If what you are really buying is a certification, an integration ecosystem, or a network of other people already using it, that is not a rebuild. It is a rewrite of twenty years of somebody else’s edge cases, and you will lose. Salesforce is not a weekend. Neither is your payroll provider, and you would not want it to be. The arithmetic also fails at the bottom: under about three thousand a month, keep paying the bill.
Where it does work, the case makes itself. Send me the invoice and an honest account of what your team does with the product, and I will tell you whether replacing it is worth doing before you have spent anything.
Where I am not the right fit
| Ongoing headcount | If you need another engineer on the team indefinitely, that is a hire, not a consulting engagement. Everything I take on has a defined scope, a start, and an end. |
| Approved vendor lists | You contract with a Texas LLC and are invoiced like any other vendor. But if procurement requires a name already on an approved list, or a firm large enough to carry the risk itself, that is a legitimate requirement and not one I can meet. |
| Concept to company | I build services and tools that plug into systems which already exist and already have users, because that is where the constraints are real. Turning a raw idea into a product with no users yet is a different job. |
The boring parts, answered up front
You are hiring one person rather than a firm. That is the point, and it also means you can read every term you would be signing before you send a word.
| Who you contract with | KordLoom LLC, a Texas limited liability company. You are invoiced like any other vendor, on your terms, in your system. |
| What we agree before I start | Scope, price, and the delivery date, in writing. Changes to any of the three are a conversation, not an invoice you find out about later. |
| Who owns the work | You do. Everything I write for you transfers to you on final payment, source and all. I keep no rights over it and reuse nothing from your codebase anywhere else. |
| Confidentiality | I will sign your NDA. Client work, client code, and client names stay private by default, including from this website. |
| If a date is going to slip | You hear it from me the week it becomes likely, not on the due date. A fixed date is worth nothing if the first sign of trouble is silence. |
| If I cannot finish | You get everything built to that point, the documentation for it, and a refund of the balance not yet earned. One person means one point of failure, and the answer to that is money back and working code, not an apology. |
If your procurement process needs something not listed here, ask before we go further rather than after. I would rather find out early that I cannot meet a requirement.
Send me the problem
Tell me what you are trying to build, where you are stuck, and what you have already tried. I will tell you whether I can help and which engagement fits, including when the answer is that you do not need one.
Email consulting@douglasadolph.com. A short note beats a long form, and you will hear back from me, not from a scheduling link.
Work spanning many teams and tenants, or a fleet much larger than most, gets a custom scope instead of the prices above.