Retrofitting AI Into a Product You Didn't Build: The Six-Point Codebase Readiness Score We Run Before Quoting

Why the quote depends on the codebase, not the AI feature

Because the model call is almost never the expensive part. In a retrofit, the AI feature itself is usually a few days of work. The weeks come from what the surrounding codebase does not have: a clean read path to the data, an idempotent write path, latency room in the request cycle, a PII boundary, request tracing, and a deploy pipeline that lets you ship a fix the same day.

We learned this the way most agencies do, by quoting an AI feature on the strength of a demo and then discovering that the interesting work was everywhere except the prompt. A summarization feature is trivial until you find that the source records live in three tables with no join key and a nightly export nobody owns. A support triage classifier is trivial until you find that retrying the classifier double-posts to the ticketing system, because the write path was never made idempotent.

So before we quote anything on a codebase we did not write, we run a fixed six-axis assessment and produce a numeric score. It takes two to four days depending on repository size and access, and it produces two outputs: a per-axis score with the evidence behind it, and a remediation list with hours attached. If two specific axes score low, we do not quote AI work at all until a preparation phase is done. Those two are covered below.

The six axes and the scoring rubric

Each axis is scored 0 to 3. A 3 means the AI work can proceed against it with no preparation. A 2 means minor adaptation folded into the feature estimate. A 1 means a named remediation task with its own hours. A 0 means the axis is a blocker or near-blocker and gets scoped as a separate phase. Total is out of 18.

The axes are deliberately narrow. They are all things you can verify by reading code, running the app, and looking at a dashboard, not things you learn from an interview. We do not score "data quality" or "AI strategy" because those are opinions. We score whether there is a single query that returns the record an LLM would need to see, and whether calling it twice is safe.

Here is what each score means in practice.

• • Data access path: 3 = one query or one service method returns the full record the feature needs. 2 = a join across two owned services. 1 = data spans systems with no shared key, needs a new read model. 0 = the data lives only in a third-party system or an unowned export.
• • Write-path idempotency: 3 = every mutation the feature touches accepts an idempotency key or is naturally idempotent. 2 = idempotent at the database level but not at the side-effect level (emails, webhooks). 1 = retries produce duplicates in at least one visible place. 0 = no request IDs anywhere, retries are unsafe by default.
• • Latency headroom in the existing request cycle: 3 = the target endpoint has more than 800ms of headroom against its current p95 budget, or the feature can run async. 2 = 300 to 800ms. 1 = under 300ms, needs a queue or a background job introduced. 0 = the endpoint is already at budget and there is no job runner in the stack.
• • PII boundary: 3 = a named layer already strips or pseudonymizes personal data before anything leaves the perimeter. 2 = a redaction utility exists but is applied inconsistently. 1 = personal fields are identifiable but nothing enforces a boundary. 0 = personal, health, or payment data is intermixed with free text with no schema-level distinction.
• • Observability and logging depth: 3 = request tracing with correlation IDs, structured logs, and per-endpoint latency dashboards. 2 = structured logs, no tracing. 1 = unstructured logs, errors only. 0 = no retained logs beyond the platform default.
• • Deploy frequency: 3 = deploys on merge, multiple times per week, with rollback. 2 = weekly, automated. 1 = manual release, every few weeks. 0 = deploys require coordination with a party outside the team.

What four real products scored

We have run this on products at very different maturity levels. The scores below are the ones that determined the shape of the quote: GlycanAge's consent-bound health data platform, Plodovi's marketplace copy pipeline, MOVE & MEET's support and operations surface, and one inherited codebase roughly six years old that we did not build.

GlycanAge scored highest overall, and the reason is not that the codebase is newer. It is that six years of regulated health-tech work forced the PII boundary and the audit logging to exist long before AI was on the table. Consent state was already a first-class field, results release already passed through a gate, and every sensitive read was already logged. The axis that cost us there was latency headroom, because the surfaces we wanted to attach to were synchronous clinician-facing views with tight budgets. The answer was to move the work off the request cycle entirely rather than try to buy back milliseconds.

The inherited six-year-old codebase is the instructive one. It scored well on data access, because the schema was actually coherent, and badly on everything to do with operating the system: no correlation IDs, error-only logging, and a manual release process. None of that is an AI problem. All of it made AI work slower, because you cannot tune a prompt whose effect you cannot measure, and you cannot iterate on a feature you can only ship every third Thursday.

• • GlycanAge (consent-bound health data): data access 3, idempotency 3, latency headroom 1, PII boundary 3, observability 3, deploy frequency 3. Total 16/18.
• • Plodovi (marketplace product copy at scale): data access 3, idempotency 2, latency headroom 3 (batch, fully async), PII boundary 2, observability 2, deploy frequency 3. Total 15/18.
• • MOVE & MEET (support and ops surface): data access 2, idempotency 1, latency headroom 2, PII boundary 2, observability 1, deploy frequency 3. Total 11/18.
• • Inherited codebase, ~6 years old, not built by us: data access 2, idempotency 0, latency headroom 1, PII boundary 1, observability 0, deploy frequency 1. Total 5/18.

The two structural blockers that get a preparation phase before any AI work

Two axes at 0 stop the AI quote entirely: no idempotency on the write path, and no PII boundary in the data layer. Every other low score adds hours. These two change what we are willing to sign, because building on either one produces a feature that is unsafe to retry and unsafe to send outward.

The idempotency blocker is about the nature of LLM calls. They time out, they rate-limit, they return malformed output, and they get retried, by your queue, by your client, or by a user hitting the button again. If the AI action writes anything, a status change, a message, a ticket, a generated description, then a retry without an idempotency key is a duplicate in production. On the inherited codebase, there were no request IDs at all, so there was no way to make a retry safe without first introducing them at the service boundary. That is not AI work. It is a prerequisite, and it belongs in its own phase with its own acceptance criteria.

The PII boundary blocker is about what leaves the perimeter. If personal, health, or payment data is intermixed with free-text fields and nothing in the schema distinguishes them, then any prompt you assemble is a data-protection incident waiting for a bad row. You cannot fix this with a regex in the prompt builder. It needs a classified schema, a redaction layer applied at one chokepoint, and a test that fails when an unclassified field reaches the model client. We scope that separately, before the feature, because doing it after means auditing every call site you already wrote.

What each low score actually costs, in remediation hours

A low score is not a verdict, it is a line item. Each one maps to a specific piece of preparation work with an hours range we have actually spent. The ranges below are what we use when converting a readiness score into a quote, and they assume a mid-sized codebase with repository access and one available engineer on the client side.

The observability number is the one that surprises clients most. On the inherited codebase, the absence of request tracing added roughly nine working days before we could measure the effect of a single AI call. Not build it, measure it. We had to introduce correlation IDs through the request path, get structured logs into a searchable store, and add per-call latency and token counters, because without them every question about the feature ("is it slow?", "is it wrong more often on long inputs?", "what is this costing per day?") is unanswerable. Every prompt iteration after that was faster, which is the argument for doing it first rather than promising it later.

Deploy frequency scores low more often than people expect, and it compounds with everything else. AI features are tuned in production against real inputs. If the release cadence is three weeks, then five rounds of prompt and threshold tuning is a quarter. We would rather spend a week on the pipeline than bill four months of waiting.

• • Data access at 1: build a read model or view that assembles the record the feature needs, 16 to 32 hours, plus backfill if history matters.
• • Idempotency at 1: add idempotency keys and a dedupe table to the specific mutations the feature touches, 12 to 24 hours. At 0: introduce request IDs at the service boundary first, 40 to 60 hours, scoped as its own phase.
• • Latency headroom at 1: introduce or adopt a job runner and move the AI call off the request path, with status polling on the client, 24 to 40 hours.
• • PII boundary at 1: classify fields in the schema, add a single redaction chokepoint before the model client, add a failing test for unclassified fields, 24 to 40 hours. At 0: add a data-mapping pass first, 20 to 30 hours on top.
• • Observability at 1 or 0: correlation IDs, structured logging, per-call latency and token metrics, 40 to 70 hours. On one inherited codebase this was about nine working days before any AI effect could be measured.
• • Deploy frequency at 1: automate build, test, and deploy with rollback for the affected services, 24 to 40 hours.

How to run this assessment on your own codebase

You do not need an agency to score your own product. Take the six axes, spend a day with the code and your dashboards, and answer each one with evidence rather than intuition. The output is useful whoever does the AI work, because it tells you which conversations to have before you ask anyone for a number.

Run it in this order, because each step narrows the next. Start from the feature you actually want, not from the codebase in general. Readiness is relative to a specific insertion point: a product that scores 5 out of 18 for a write-heavy triage feature might score 14 for a read-only summarization panel on the same data.

When we do this for a client, the deliverable is a short document: score per axis, the file paths and dashboard screenshots that justify each score, the remediation list with hours, and a clear statement of whether a preparation phase is required. If the answer is that the product is ready, that document also becomes the baseline we measure the retrofit against. If the answer is that it is not, at least nobody has paid for an AI feature that cannot be measured, retried, or safely fed real data.

• • Name the exact insertion point: which endpoint, job, or screen the AI call attaches to.
• • Trace the read path: write down the single query or sequence that returns everything the model needs to see. If you cannot write it in one paragraph, data access is not a 3.
• • Trace the write path: list every mutation and side effect the feature triggers, then ask what happens if it runs twice.
• • Pull the current p95 latency for the target endpoint and subtract it from your budget. That number is your headroom.
• • Open the payload you would send to a model and mark every field that identifies a person. Then find the code that would strip them. If it does not exist, the PII boundary is 1 or 0.
• • Pick a request from yesterday and try to follow it end to end in your logs. How long that takes is your observability score.
• • Look at your deploy history for the last 90 days and count releases.

For what happens after a codebase passes this assessment, see our AI retrofit log, a feature-by-feature account of six AI features added to products already in production, including the two we turned off.