What a $2,000 production hardening project actually buys you

Agencies are usually vague about what a number buys, which is how a $2,000 project turns into an argument in week three. So here is the arithmetic in public.

Two thousand dollars is roughly twenty to twenty-five hours of senior engineering time. That is not a rewrite, it is not a redesign, and it is not a security certification. It is enough to close the findings that would actually hurt you, put the operational basics in place, and hand the result back with documentation. For an AI-built app of typical size - somewhere between five and fifteen tables, one or two integrations, a single tenant model - that is usually the right amount of work.

Where the hours go

This is the shape of a typical project after a Production Check. The exact split moves with the findings, but the total does not, because the scope is fixed before we start.

Notice what is not in the table: meetings. Fixed scope means we do not bill you for coordinating, and it means we have every incentive to be efficient rather than thorough in the expensive sense of the word.

What is in scope at this number

• Every critical and high-severity finding from the audit, closed and verified.
• A security posture where an anonymous visitor and a hostile authenticated user both get exactly what they are entitled to and nothing more.
• Deployment that runs from a branch, with preview environments and a rollback anyone on your team can execute.
• Monitoring that reaches a phone, so you learn about outages before your customers write in.
• Documentation good enough that a new engineer can deploy on their first day.
• Thirty days of post-launch support for anything the real world surfaces.

What is explicitly not in scope

Being clear about this up front is the difference between a good project and a bad one.

• A rewrite. If your app genuinely needs one, we say so before you pay and we decline the hardening project rather than take your money to polish something that has to be replaced.
• New features or design changes. We touch product code only where it is required to close a finding.
• SOC 2, ISO 27001, or HIPAA compliance. We can put you in a much better starting position, but certification is an audit process with its own budget and its own calendar.
• Multi-region architecture, sharding, or anything sized for traffic you do not have yet.
• Mobile applications, native builds, or app store submissions.
• Penetration testing by an independent third party. Our security work is a review and remediation, not an adversarial engagement.
• Ongoing maintenance. That is the Managed App retainer, and it is priced separately for a reason: an outage should never be competing with a roadmap item for the same hours.

A worked example

A B2B scheduling tool built in Lovable on top of Supabase. Nine tables, around 400 registered users, two paying teams, and a founder who had just been asked to complete a security questionnaire by a prospect ten times larger than their current biggest customer.

What the audit found

• Three tables with row-level security disabled entirely, including the one holding customer contact details.
• Four policies using USING (true), and two more that only checked the user was authenticated.
• The service-role key present in the deployed JavaScript bundle, and also in git history from month one.
• A role column on a user-writable profiles table, used for admin checks.
• No indexes on any foreign key. The main dashboard query ran a sequential scan over 180,000 rows.
• Backups enabled, never restored. Nobody knew how long a restore would take.
• Deploys performed by clicking Publish. No staging, no rollback, no test suite.
• No error tracking. Bugs were discovered by customers and reported by email.

What the project changed

Twenty-three hours of work. The security questionnaire was answered the following week, and the prospect became a customer - which is worth noting mainly because the trigger for this kind of project is very rarely an outage. It is almost always someone else asking a question the founder could not answer.

Why fixed scope instead of hourly

Hourly billing makes you pay for our learning curve on your codebase, and it puts our incentives and yours on opposite sides of every estimate. Fixed scope after a free audit means the number is agreed before any work starts, and if we were wrong about how long something takes, that is our problem. It also forces us to be honest during scoping, because a badly scoped project is one we lose money on.

The trade is that the scope is genuinely fixed. Work that appears mid-project gets written down, estimated, and either added by agreement or scheduled for later. Nothing is quietly absorbed, and nothing is quietly dropped.

When $2,000 is the wrong number

It is the floor, not the price. Two directions to be honest about:

Too much

A single-table prototype with thirty users and no payments does not need a $2,000 project. It usually needs four hours: turn on RLS, rotate a key, add error tracking, set up deploys from git. We will tell you that, quote accordingly, and the audit is free either way.

Too little

An app with payments, personal data, a real multi-tenant model, forty tables, and three integrations is an $8,000 to $15,000 project. Scoping it at $2,000 would mean either doing a fraction of the work and calling it done, or absorbing a loss and rushing. Both produce a bad outcome for you, and the second one produces a worse one, because rushed security work looks finished.

How to get the most out of it

1. 1Give repository and staging access on day one. Every day of access delay is a day of calendar, and the fixed price does not buy more calendar.
2. 2Name one decision-maker. Two people with different opinions about the data model costs more hours than any technical problem on the list.
3. 3Freeze feature work on the surfaces we are touching, or expect merge conflicts to eat hours that would otherwise go into the work.
4. 4Have the production credentials ready - hosting, database, DNS, email provider. Hunting for a registrar login is a genuinely common source of delay.
5. 5Take the walkthrough call seriously and bring whoever will maintain the app. The handover is where the value compounds; a runbook nobody has read is a document, not a capability.

If you want to know what your own number looks like, the Production Check is free and produces a written report with an estimate against every finding, which becomes the fixed scope of a production hardening project. You are free to take that report and do the work yourself, or hand it to your own team. Plenty of people do, and that is a perfectly good outcome.