Half of the AI integration work we do at Accolades is retrofitting features into custom web applications that were never designed to host them. The hard part is rarely the AI. It is the four or five architectural assumptions baked into the app five years ago that the AI features now collide with.
What the retrofit tax actually looks like
A typical retrofit conversation starts with a two-week feature request: “add an assistant that can answer questions about a customer’s account and draft the follow-up email.” Then we open the codebase. The account logic lives inside controller methods, so there is no way to call it without faking an HTTP request. The knowledge base is in a hosted CMS with no usable API. There is no record of what the user did before asking, so the assistant has no context. And the only way for a background process to touch the API is a service token with admin rights. None of these are AI problems. All of them have to be fixed before the AI feature can exist, and that is how a two-week feature becomes a two-month project, with six of those eight weeks spent paying down decisions made years earlier.
The frustrating part, from the owner’s side, is that every one of those fixes would have been nearly free at design time. That is the argument for AI-ready architecture: not that you will ship AI features on day one, but that you will not have to excavate the foundation on the day you decide to.
Architecture decisions that compound
An AI-ready web application has a few non-negotiable properties from the first commit:
Clean separation between request handler and business logic. AI features almost always need to call your business logic from a new context: an agent loop, a background job, a webhook handler, a scheduled task. If “create an order” or “apply a credit” lives inside a controller method, you cannot reach it from anywhere else without rewriting it. Extracted into a service layer, the same operation is callable from a web request today and an agent tomorrow, with identical validation both ways. This is standard good practice that most codebases claim and few actually maintain; AI is simply the first consumer that punishes the shortcut.
Structured event log of user actions. Every AI feature you add later will want context about what just happened: what the user viewed, edited, or abandoned before asking for help. If your app only persists final state, the AI is blind to the path that led there. An append-only event log is cheap insurance: a table, a naming convention, and the discipline to write to it. It also happens to give you an audit trail and better debugging for free, which is why we build it into applications whether or not AI is on the roadmap.
Document and content storage in retrievable form. If your unstructured content (docs, support tickets, policies, knowledge base) lives in a system that exposes neither a clean API nor exportable structure, every AI feature starts with a data migration. You do not need a vector database on day one. You need content stored with real structure (owner, date, type, permissions) somewhere a future retrieval pipeline can read without a rescue operation. Choose boring, open storage over a convenient walled garden.
Auth and authorization that an agent can speak. When an AI agent calls your API on behalf of a user, it must do so with that user’s permissions, not a god-mode service token. This is a security requirement, but it is also a correctness requirement: an agent that can see everything will happily answer questions with data the asking user should never see, which is one of the quieter ways agent deployments go wrong in production. Scoped tokens or proper service-to-service auth from the start cost a design conversation. Retrofitting them costs a security audit.
What you do not need to do
Just as important is the list of things AI-ready does not mean, because over-preparing is its own failure mode. You do not need to pick a model. You do not need to commit to an AI provider. You do not need vector databases, embedding pipelines, or fine-tuning infrastructure in the MVP. Bolting those on early means maintaining speculative infrastructure that will be outdated by the time you use it. The model provider picture changes quarterly; your data model changes over years. Invest in the layer that lasts.
Notice that everything on the “do” list (separation of concerns, structured history, clean data storage, proper auth) makes the application healthier even if AI never arrives. That is the test worth applying to any AI-readiness advice: if the recommendation only pays off in an AI future, it is speculation; if it pays off either way, it is just good engineering wearing a timely label.
The cost is discipline, not dollars
When we build custom web applications, AI-ready is the default posture, not an upsell line on the proposal. On a new build, these four properties add close to nothing to the budget. They are choices about where code lives and how data is shaped, made at the moment those choices are free. What they buy is the difference between “the AI feature shipped in a sprint” and “the AI feature is blocked on a replatforming project.”
And when the day comes to actually add the feature, the production concerns shift from architecture to operations (evals, guardrails, observability), which we covered in what it takes to move AI from pilot to production. An AI-ready foundation does not make those free, but it makes them tractable.
If you are scoping a new application this year, it is worth a conversation before the architecture hardens. A free 30-minute call is usually enough to tell whether the design you are considering will welcome AI features later or fight them.