Brownfield vs greenfield: retrofit AI or start fresh?

01What advantages does a mature platform already have?

Boards comparing their company with AI-native competitors often frame the question as speed. That framing misses what the incumbent already owns. The brownfield vs greenfield AI SaaS debate is really about which side holds the hard-to-copy parts of a useful AI feature.

A mature vertical SaaS product already has five things an AI startup has to earn:

• Data in context. Years of records, documents and transactions sit inside real workflows, labeled by how customers actually use them. A startup has a model; you have the context the model needs.
• Business logic and tools. Pricing rules, approval chains, integrations and edge cases are encoded in your code. These are exactly the actions an agent needs to call, and an AI-native newcomer cannot fake them.
• Permissions and tenancy. You already know who can see what, per customer and per role. That is the hardest part of a safe AI feature to build from scratch.
• Distribution. A feature you ship reaches every paying account through the screens they already use. A startup has to win each account, one sales cycle at a time.
• Trust. Your customers have already passed you through security review, procurement and renewal. A new vendor starts that process at zero.

02Where does legacy architecture slow AI work down?

Most mature products were built for people clicking through screens and for application code calling known functions. They were not built for a model that decides at run time which action to take. In our experience, AI work slows down in a handful of predictable places:

• Logic trapped in the interface. When a rule lives in a form or a controller instead of a service, an agent has nothing clean to call.
• Implicit permissions. If access is enforced by which page a user can reach, rather than by a check on each data request, an AI feature can read past those boundaries.
• Tenant boundaries that were never tested against retrieval. Search and retrieval for AI must respect the same tenant separation as the rest of the product, and that has to be proven, not assumed.
• Uptime and release discipline. A live product with paying customers cannot absorb a risky migration to make room for AI.
• A team already at capacity. The engineers who understand the system of record are usually busy keeping it running.

None of these is a reason to rewrite. Research on machine learning systems has made the same point for years: the model is a small part of the system. The NeurIPS paper on hidden technical debt in machine learning shows that only a small fraction of a real-world system is the model code, while the surrounding infrastructure is vast. A mature product already has much of that infrastructure. The job is to expose it safely, not to replace it.

03Why do greenfield AI prototypes struggle to reach production?

Greenfield teams can pick any architecture, any model and any stack, and they can reach a convincing demo in weeks. The trouble starts when the demo meets real customers.

Industry data points the same way. Gartner predicted in 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs or unclear business value. In 2025 it predicted that over 40% of agentic AI projects would be canceled by the end of 2027, citing escalating costs, unclear business value or inadequate risk controls. Those causes are not model quality. They are the work around the model.

Greenfield prototypes tend to share the same gaps:

• No real data path. The demo runs on samples or static files, not a live connection to the data the product will depend on.
• No safe way to change things. There is no test environment, no rollback and no regression coverage, so every release is a gamble.
• No proof of isolation. Nobody can show that one customer's data, credits or documents can never reach another.
• No measurement. Without an evaluation set, nobody can say whether a change made answers better or worse.
• Code that was generated faster than it was reviewed. An academic study of GitHub Copilot found that about 40% of the programs it produced in security-relevant scenarios contained vulnerabilities, and a Stanford user study found that people with an AI assistant wrote less secure code while being more confident that it was secure.

04Brownfield vs greenfield: cost, speed and risk compared

The comparison below uses eight dimensions that decide whether an AI feature reaches production. The evidence column draws on retrofits we have delivered and startup prototypes we have hardened.

The pattern is consistent. Greenfield wins on early speed and freedom. Retrofit wins on data, customers, permissions and the amount of hardening already done. The risk on the retrofit side is concentrated in one place: letting AI change live records before the controls exist. That risk is manageable with sequencing.

05How can a mature SaaS company move as fast as an AI startup?

An incumbent does not need to copy the startup's architecture to match its pace. It needs to copy its focus. This is the sequence we use:

1. 01

   Pick one narrow workflow with a measurable outcome.

   Choose a task where success can be counted, such as time to prepare a document or questions answered without a ticket.

2. 02

   Keep the system of record.

   Build AI as separate services that call the existing product through defined interfaces, so the core application does not have to change.

3. 03

   Change only what the capability requires.

   If one API or one data path blocks the feature, fix that one, and leave the rest alone.

4. 04

   Reuse existing permissions on every request.

   The AI should see exactly what the signed-in user can already see, checked at each tool call, inside each tenant boundary.

5. 05

   Climb the capability ladder slowly.

   Start with read and recommend, then prepare drafts, and only later modify or execute. Each step up needs more policy, approval and audit.

6. 06

   Put a person in the approval step.

   Anything sent to a customer or written to a record is reviewed first.

7. 07

   Build the evaluation set before launch.

   Test on real cases from your own domain and rerun the set on every release.

8. 08

   Track cost per successful task.

   Model spend only matters relative to work actually completed.

Shipped behind a feature flag and delivered in small pull requests, this approach lets a mature product put a working AI capability in front of customers while competitors are still finding theirs.

Speed alone is not the answer either: see why vibe coding is not enough for a mature SaaS product.

06What we see in production

We work on both sides of this question: retrofitting AI into established products and taking startup prototypes to production. The details below are anonymized.

An established investment platform in a regulated market. Issuers were copying deal information by hand from documents such as decks, memos and financial statements into long forms, and much of the review and analysis around each deal was manual. The goal was AI that reads the documents, assembles the deal record and supports market and risk analysis while staying audit ready. We kept the existing application as the system of record and built AI as services around it. Each step of the deal workflow got its own agent with a narrow job. The regulated core was never replaced; the workflows around it changed.

A claim verification product at an early-stage AI company. The founder wanted to break claims into small units, classify them against a fixed scheme, score them and keep a provable record. The prototype proved the idea but could not be measured, scaled, audited or integrated. We began with a gap analysis before writing code. We kept rule-based pattern matching as a fast, explainable anchor, added semantic embeddings, and limited the language model to suggestions with a confidence score, merged through calibrated weights. We also designed a ledger that signs each claim's record. The lesson for boards: the model became one input among several, not the decision maker.

A patient-intake prototype that became a multi-clinic product. An adaptive intake prototype had to grow clinic isolation, role-based access, onboarding, provider configuration and billing before it could serve more than one clinic.

Retrofits where the core stayed put. On a cloud file-management product, we added reliability and regression coverage before any AI ingestion or retrieval. On a multi-tenant fulfillment platform, only the legacy storefront layer that blocked progress was replaced. On an investor CRM, data synchronization was added with no replacement of the core.

On a food and nutrition app, we worked from the client's existing exports and its 200,000 labeled menu items rather than collecting new data, and linked each dish to its recipe before building any recommender on top of those links.

Across this work, the deciding factor was never the model. It was data paths, isolation, evaluation, approval and audit.

Frequently asked questions