Skip to content

Product engineering

Talk to us Discuss a Project

Production Readiness Assessment

It works. That’s not the same as ready.

Shipping fast was the right call. But the build that got you live was made to prove the idea, not to survive the open internet. The gap between those two things is where the 3am calls, the surprise invoices and the awkward customer emails come from.

A Production Readiness Assessment is a short, fixed scope review of your live system. You get a ranked list of what will break, what it would cost you, and what to fix first.

What you get

  • Findings ranked as fix today, fix this month, or accept the risk.
  • The blast radius and likely cost of each one, in plain language.
  • A fix plan your own team can run, with our help if you want it.

Common findings

What we usually find

An endpoint with no lock on it

An API route, an AI proxy or a webhook that never got authentication. Usually found in the first hour.

A bill with no ceiling

Metered services with no rate limit, no budget alert and no hard cap. One bad day becomes a five figure invoice.

Secrets in the repository

Keys committed months ago, still valid, still sitting in the history long after someone deleted the line.

An admin surface facing the world

Login pages, database tools and internal dashboards reachable by anyone who tries the obvious path.

Backups nobody has tested

A backup you have never restored is not a backup, it is a hope. We check by restoring one.

Nothing watching

No error alerting, no uptime check, no log retention. You find out there was a problem when a customer tells you.

What the assessment covers

One pass over the system as it actually runs, not as the architecture diagram says it does.

  • Access: who can reach what, from where, and with which credentials.
  • Authentication and authorisation on every public route.
  • Secrets: where they live, who can read them, and which ones are still valid.
  • Rate limits, quotas and spend caps on anything metered.
  • Data: what you store, where it sits, and what it would mean if it leaked.
  • Backups, proven with a real restore rather than a job that reports success.
  • Dependencies, and the versions you are pinned to.
  • Infrastructure: open ports, firewall rules, server access, who holds the keys.
  • Monitoring, alerting and log retention.
  • Cost and behaviour under a traffic spike you did not plan for.

How it runs

About two weeks from the first call to the fix plan, and most of that is us working, not you.

1.

A 30 minute call

You walk us through what you built and what worries you. We tell you on that call whether an assessment is worth your money.

2.

Read only access

We work from your repository, your cloud console and your dashboards, under an NDA. Nothing is deployed, changed or touched.

3.

The review

Three to five working days. We go through the system the way an attacker and a traffic spike would, not the way a checklist would.

4.

Report and walkthrough

A ranked findings report, plus an hour on a call going through it with whoever is going to do the work.

Next step

Start with the 30 minute call

No preparation needed and no obligation to go further. If your setup is in good shape, we will tell you that and you can get on with your day.

What we cover

  • What you have built and what is live
  • Where your traffic and your spend come from
  • What is already worrying you
  • Whether an assessment is worth doing

What you leave with

  • Two or three things to check this week
  • A clear scope if you go ahead
  • A short written summary after the call
  • No pressure to book anything
30 minutes, straight to an engineer.
The TheCodeWork team in a working session
TheCodeWork engineers reviewing a system together

Frequently Asked Questions

Read access is enough and it is all we ask for: the repository, the cloud console, the monitoring. We do not deploy, we do not change configuration and we do not touch your data. If you would rather share a screen than grant access, that works too, it just takes longer.
A kickoff call and a few questions along the way, usually two to three hours of their time across the whole review. The rest is on us. We write the report so that a developer who was not on any of the calls can still act on it.
Not without asking first. The default assessment is a review, not a penetration test. If you want active testing, we scope it separately and in writing, against a system and a time window you agree to.
It depends on how much system there is to look at, so we price it after the first call rather than before. The call itself is free, and it ends with a fixed scope and a fixed number. Nothing is metered while we look.
Either. Plenty of teams take the report and do the work themselves, which is exactly what it is written for. If you would rather hand it over, we can scope the fixes as a separate piece of work, and you are free to give the report to somebody else entirely.
That is the cheapest time to do this. Changing an architecture decision before it has users is an afternoon of work. Changing it after it has users is a migration, with a maintenance window and an apology email.
No. This is an engineering assessment, not a certification. If you are heading towards SOC 2 or ISO 27001, it will show you how far you are from being able to pass one, but it does not replace the audit itself.

Find out what breaks before your users do.

Thirty minutes, a real engineer, and a straight answer about where you stand.

Book a readiness call