How we work
Everything as code,
including the operations.
The life cycle is four stages. The managed side runs on six mechanisms. Both come down to one idea: if the only record of how something works is in somebody's head, it's not a system. It's a habit.
The life cycle
Four stages. We stay for all of them.
- 01
Plan
Before anyone writes code, we work out what the thing is for and what it must not do. Cheap to change now. Expensive to change in month seven.
- Start with the constraint. The budget, the deadline, the regulator, the one integration that cannot break. Design around the hard edges first, and the soft middle takes care of itself.
- Write down what success is. In a sentence you could read to a stranger. If we cannot agree on that sentence, the project has a problem that no amount of building will fix.
- Decide what happens after. Who maintains it, on what, for how long. Planned at the start, because a product with no plan for year two is a product with a shelf life.
- 02
Create
Working software in your hands early and often, in your repository, under your account, with your name on it.
- Your environment, not ours. Your cloud account, your repository, your domain. Nothing we build lives somewhere you would need our permission to reach.
- Boring on purpose. Proven tools over interesting ones. Novelty is a cost, and it comes due on the night you least want to pay it.
- Everything as code. Infrastructure, configuration, pipelines, runbooks. If the only record of how something was set up is in somebody’s head, that is not a configuration. That is a dependency on a memory.
- 03
Launch
A launch is a rehearsed procedure, not an event. We have done the rollback before we do the release.
- Rehearsed, then repeated. The deployment that puts it live is the same one that has already run dozens of times into staging. Launch day should be boring.
- Reversible. Every release can go backwards. A change you cannot undo is not a release, it is a bet.
- Watched from minute one. Monitoring and alerting go in before the traffic does, so the first sign of trouble is a page rather than a phone call from a customer.
- 04
Maintain
The stage everyone skips in the pitch and nobody escapes in reality. It is most of the life of a product, and it is where we stay.
- Patched without a ticket. Dependencies, operating systems, base images. The update arrives as a pull request that has already passed the tests.
- Drift shows as a diff. Because the environment is defined in code, anything that wandered off the baseline is visible as a change, not as a mystery.
- Still yours to leave with. Repository, runbooks, credentials, diagrams — handed over as we go rather than reconstructed on the way out.
The six mechanisms
None of these is exotic. What's unusual is building the routine half of every managed service out of them first, so the response to a known problem never waits on whoever happens to be awake.
AI
Triage, classification and remediation that used to need a person reading a screen.
Automation
The response to a known condition is written down once and then it just happens.
Containers and orchestration
Workloads that reschedule themselves rather than waiting for somebody to notice.
CI/CD
Every change tested and shipped the same way, whether it is a feature or a patch.
Infrastructure as code
The environment is a file. It can be reviewed, reverted and rebuilt from nothing.
Monitoring and observability
The system reports its own condition, so nothing depends on a human being awake.
In practice
Three things that follow from it
These are consequences of working this way rather than promises bolted on afterwards.
- Ownership
Your account, your repository
We work inside what you own from the first commit. There's no portal you'd lose access to, and nothing that needs our permission to reach.
- Records
Decisions with dates on them
Every choice that matters gets written down with the alternatives and the trade-off, including the ones that turned out badly. Skip that and a decision becomes folklore within a year.
- Exit
Leaving should be dull
Runbooks, diagrams and credentials handed over as the work happens. If ending the arrangement needs a project, the arrangement was a trap.
How working with us starts
No discovery theatre. The first conversation is about whether this is work we should be doing at all.
A conversation, not a demo
What the thing has to do, what it runs on now, and what you're on the hook for. Twenty minutes of that beats an hour of slides.
One-off or ongoing
A single project with an end date, or a recurring contract where we run something for you month after month. Plenty of clients start with the first and end up on the second.
Remote, on site, or both
Most of the work happens remotely, wherever you are in the world. When it needs hands in the building we come to you: routinely from Denver Metro to Colorado Springs, and anywhere else by arrangement, with the travel in the quote.
A quote written for you
No packages and no price list. You get a written shape of the work, where the risk sits, and what it costs, billed per project or monthly or annually. It's useful even if you take it elsewhere.
Tell us what you're trying to build
Or what you're trying to get off. Either way, the first conversation is about what the thing has to do.
Write to us and a person reads it. You'll get a straight answer about whether this is work we should be doing, and a quote written for you if it is.
- What we arePlan, create, launch, maintain
- What we areSentrello Premier Partner
- What we areEvery quote written for you