# Why We Insist on Hardening Before We Operate

> Every prospect asks if we'll just take over the system as-is. The answer is almost always no. Here's why — and how we price the work that comes before.

Source: https://keepstone.tech/blog/why-we-insist-on-hardening
Published: 2026-03-30
Modified: 2026-06-07

---

Every prospect, eventually, asks the same question. They've got a system that works. They've heard about what we do. They want us to take it over and start running it as it sits today. The answer is almost always no, and I want to explain why — and how we price the work that comes before, because we're transparent about that too.

The thesis is straightforward: you can't operate what isn't operable.

Most custom systems we look at — built by founders in Lovable, by partners in Bolt, by an internal employee in Claude Code, by a contractor over the course of three years — were not built with operations in mind. That isn't a criticism of how they were built. The tools that produced them weren't designed to ship operationally mature platforms. They were designed to ship working ones, fast. Those are different problems.

A working system has features. It does the thing the business needs.

An operable system has features and the operational scaffolding around them — source control with real history, separate environments for testing and production, credentials stored in a vault rather than in the code, monitoring that catches problems before users do, backups that have been restored from in a real drill, documentation that reflects what the code is actually doing, changes that can be rolled back when something goes wrong. Without that scaffolding, "operating" the system means babysitting it. That's not what you're paying us for, and frankly it's not work we'd take on at any price, because we wouldn't be able to do it well.

## What hardening actually does

Hardening takes a working system and brings it up to operable standard. Every hardening engagement covers the same set of disciplines. We get the source code into a repository we can both access. We separate the testing environment from production so changes can be tried before they go live. We pull credentials out of code and into a proper vault. We instrument monitoring across the layers that matter for your specific system. We wire in error tracking. We make releases reversible — there's a path to staging, a path to rollback, no more direct-to-production. We configure backups and verify them through an actual restore drill. We review authentication and access; we close the obvious gaps. We produce documentation — runbooks, architecture, data map, on-call playbook. And we lay the framework in across all eight layers, so we can run the system from day one of operations.

What we are *not* doing during hardening: rebuilding the system, changing what it does, or refactoring for elegance. The point is to make it operable, not perfect. If we think it should be rebuilt rather than hardened, we'll tell you that during the assessment, and you'll get a different quote.

## How long it takes

Most hardening engagements complete in 30 days. We've never needed more than 45.

We can move that fast because the framework is already built. Hardening is the work of bringing your system into compatibility with it — fitting your specific stack into the operational seams that already exist on our side. That's a very different job than figuring it out from scratch.

## How we price it

Hardening is fixed-price, scoped from the assessment, and generally lands around $8,000–$21,000 depending on complexity. Productionalization of platform-built apps (Lovable, Bolt, Replit) is typically $8,000–$10,000 fixed.

Two things worth saying clearly about how we price.

The first is that this is a profitable engagement for us. We don't run hardening as a loss leader, and I want to be honest about that. A lot of firms in adjacent categories use the entry engagement as bait — they take it at break-even or below, planning to make their margin on the back end through scope creep, lock-in, or "you should really upgrade to this tier" conversations later. We don't do that. It distorts incentives in ways that show up six months into the relationship, and frankly we don't trust ourselves to do good work on engagements we're losing money on. Nobody does.

The second is that the price is the price. No surprises, no scope creep, no "well that turned out to be more complicated than we thought." If the assessment scopes it wrong, that's our problem, not yours.

## How we think about this

Most of our clients are small business owners. They don't loss-lead either. They charge for their work, they expect to make a profit on it, and they have very little patience for vendors who pretend otherwise. We share that mindset, and we bond with our clients on it. We aren't looking to take advantage of anyone, and we aren't going to be taken advantage of either. Both halves of that sentence matter. The first half builds trust. The second half is what makes us still around in five years to keep delivering.

If you want a vendor who'll do your hardening for $2,000 and make it back on you later, we're not it. If you want a vendor who'll quote you a fair price, deliver it on time, make a fair margin on it, and then operate your system reliably for years — that's the deal we're offering. That's why we insist on hardening, and why we price it the way we do.