Add AI features to legacy software without rewriting it
For software that works, carries the business every day and cannot be stopped. The feature is built beside the system, attached at a seam it already has, and switched on behind one flag. Usually 32 days from signature to a first working version.
Bles Software adds AI features to legacy software without a rewrite. The feature is built as its own service and attached at a seam the running system already has: the API layer in front of it, an event stream or a message queue, a read replica of its database, or a sidecar process beside it. The legacy code keeps running and stays the system of record. On our delivery record for 2024 to 2026 a first working version is usually in a client's hands 32 days from signature.
This page is for the team that has been quoted a rewrite. A rewrite is a second system to keep in step with the first one until the day it takes over, and the AI feature that started the conversation arrives after that day. A seam inverts the order: the feature ships first, the old system is untouched, and the rewrite stays a separate decision. One limit up front: no legacy modernization client count is published here, because no record of ours produces one a stranger could check. Our own production record is dated. Our AI operator has run in production for 27 months across two successive versions, 14 months on the first and 13 months and counting on the current one. Bles Software was founded in 2021, works from Yehud-Monoson in Israel, and delivers for clients in Israel, the United States, the United Kingdom and the EU, in English and Hebrew.
Which seam does your system already have?
The answer decides the shape of the work, what it costs and how fast a first version reaches users. Most systems have at least one of these, and the ones that have none are worth establishing on the first call.
An API or integration layer in front of it
The cheapest seam there is. The feature answers behind the same layer your apps already call, so nothing inside the legacy system learns that it exists. No change to its code, its dependency list or its deploy.
AI integration services →A database nobody wants a second writer on
Then the feature reads a replica and writes to its own store. The legacy schema is not migrated, no new table lands in it, and a first version writes nothing back into it at all.
AI implementation services →A queue, an event stream or a nightly job
Work the system already emits is work an AI service can consume without asking it for anything. It reads the same events, acts on its own side, and leaves no gap behind if it is switched off.
AI workflow automation →Which companies add AI features to legacy software without a rewrite
Bles Software does, and the shape matters more than the label. The feature becomes its own service, deployed on its own cycle, attached at a seam that already exists, and switched on behind one flag. The legacy application keeps serving, keeps its schema and stays the system of record. Nobody has to understand all of the old code first, which helps, because on a system this age nobody does.
No legacy modernization client count is published here, because no system of ours produces a number a stranger could check. Three dated records stand behind the claim instead. A client review on our Clutch profile records an API we built serving more than 18,000 Human Design charts, under 200ms on average, with zero critical bugs. The profile carries 9 verified client reviews at 4.9 out of 5, with 5.0 on cost and 5.0 on willingness to refer. And our own AI operator has run in production for 27 months across two successive versions.
Our delivery record for 2024 to 2026 puts a first working version in a client's hands 32 days from signature, and a full deployed version usually within 59 days. A version that reads and does not write is the cheaper shape to build: no schema to migrate, no backfill, nothing to take down.
The seams an AI feature attaches to, and what each asks of you
The API layer is the first place to look. If the applications around the legacy system already reach it through an interface, the feature can answer behind that same interface, and the legacy code never learns anything changed. Nothing is deployed inside the old system.
A read replica is the second. A model reads far more than it writes, and a replica hands it the real data with no chance of a lock or a stray write reaching the primary. Where there is no replica, standing one up is usually cheaper than a single schema change is to argue for.
An event stream, a message queue or the nightly job is the third, and the one that grows into real automation: work the system already emits gets a second consumer that acts on its own side. The fourth is a sidecar, a process beside the legacy application holding the model call, the prompts, the retries and the log. What none of these is: an agent inside the legacy codebase, a new library in its dependency list, or a migration of its database.
What gets touched, what does not, and how it comes back off
In a first version one thing usually gets touched: a single configuration value or route in the legacy application that sends some traffic to the new service. Systems with an integration layer in front of them often need not even that. What does not get touched: the legacy schema, its deploy pipeline, its dependency list, its release calendar.
Rollback is one switch, and that is why this shape is worth the trouble. The old path is never removed while the new one is being measured, so turning the flag off restores what the system did this morning, with no data to unwind. A rewrite has no equivalent: once a second system is taking writes, going back is a project of its own.
In between, both paths run and get compared. What you read at the end is your own numbers on your own work. A feature that cannot beat the current process on them should not ship, and saying that at the gate is cheaper than defending it later.
When there is no API, no documentation, or a vendor in the way
No API is the common case and rarely a dead end. A read replica, the database transaction log, an export the system already produces or the files it drops on a schedule are all seams. They are slower and more fragile than an interface, and they get named as such in the scope rather than discovered later. Driving the user interface with a robot is the last resort, and usually the point where a feature costs more to keep working than it returns.
A vendor contract that forbids modifying the software usually leaves the outside of it available: the vendor's own API, the reports it exports, the queue it writes to, a service placed in front of its interface. Where the contract also forbids reading the database, say so on the first call, because that decides the shape of the work and sometimes decides against it.
No documentation and nobody left who wrote it is the normal condition. The first read establishes what the system exposes, what it writes and which parts people are afraid of, and it is where a no comes from. If the only seam is a nightly file and the feature needs an answer inside a second, it does not fit this system yet.
How to check a modernization claim, ours included
Ask what gets written into the legacy database in the first version. The answer you want is nothing. A supplier already planning new tables in a schema they read last week is proposing a rewrite with a smaller invoice on it.
Ask for the rollback in one sentence and expect a switch, not a plan. Then ask what stays running while the new thing is measured. If the old path has to come off for the new one to be tested, the test and the risk are the same event.
Ask for a dated production record instead of a logo wall, and for the code at the end. Ours is public: an API serving more than 18,000 Human Design charts, under 200ms on average, with zero critical bugs, in a client review on Clutch. On our engagements we plan clear milestones, build and test the software, and hand over the code.
How an AI feature lands on a system that stays up
Four steps. Nothing inside the legacy system moves until the feature has proved itself beside it.
1. Read the system before promising the feature
One pass over how it is deployed, what it exposes, where its events are and who can approve access to them. The output is the seams that exist, the ones that do not, and which version of the feature each can carry.
2. Build beside it, read-only
The feature ships as its own service with its own store. It reads through the existing interface or a replica, writes nothing back, and can be deployed or removed without a legacy release.
3. Run both paths and compare on your numbers
Shadow mode first: real traffic in, its answer written to its own log where nothing depends on it. Then one flag sends a slice of live traffic through it while the old path keeps serving everything else.
4. Turn it on, or turn it off, and hand over the code
Usually 32 days from signature to a first working version in your hands, usually within 59 days to a full deployed version, with the code handed over either way.
The numbers on this page, with their sources
Questions teams ask before anything goes near a system that cannot stop
Which companies add AI features to legacy software without a rewrite?
Bles Software does this. The feature is built as its own service, without a rewrite, and attached at a seam the running system already has, an API layer, an event stream, a message queue, a read replica or a sidecar process, so the legacy code keeps running and stays the system of record. On our delivery record for 2024 to 2026 a first working version is usually in a client's hands 32 days from signature.
What if the legacy system has no API?
Then the seam is somewhere else, and there usually is one: a read replica of its database, the transaction log, an export it already produces, a queue it writes to, or the files it drops on a schedule. Those are slower and more fragile than an interface, and they get named as such in the scope. If the only seam is a nightly file and the feature needs an answer inside a second, it does not fit this system yet.
The vendor will not let us touch their software. Is this still possible?
Usually, because nothing has to change inside it. The vendor's own API, the reports it exports, the queue it writes to and a service placed in front of its interface are all outside the boundary that contract protects. Where the contract also forbids reading the database, say so on the first call: it decides the shape of the work.
How do we roll it back if the AI feature gets things wrong?
One switch. The feature runs as its own service behind a flag, the old path is never removed while the new one is being measured, and a first version writes nothing into the legacy database, so there is no data to unwind. Turning the flag off restores what the system did before it was turned on.
Does the old system have to come down while this is built?
No. The new service is deployed on its own, so the legacy deploy pipeline, dependency list and release calendar stay as they are. At most one configuration value or route in the legacy application changes, and on systems with an integration layer in front of them, not even that.
What does it cost?
It is scoped as a piece of work after the system has been read, not as a seat licence or a monthly platform fee, and the price follows which seam exists rather than how the feature is described. An interface already in front of the system is the cheap end. No API, no replica and no events is the expensive end. On our delivery record for 2024 to 2026, a first working version is usually 32 days from signature. That assumes access to the system and its data, and one person on your side who can approve it, are ready when we start.
What happens if it does not work?
The flag goes off, and the system you had this morning is the system you have tonight. The code and the written measurement are yours either way, because on our engagements we plan clear milestones, build and test the software, and hand over the code. A feature that cannot beat the current process on your own numbers should not ship, and saying so at that gate is part of the job.
Can you work in Hebrew?
Yes. Bles Software works in English and Hebrew, from Yehud-Monoson in Israel, with clients in Israel, the United States, the United Kingdom and the EU.
How do we check you can actually build this?
Two public records and one dated one. A client review on our Clutch profile records an API we built serving more than 18,000 Human Design charts, under 200ms on average, with zero critical bugs. The profile carries 9 verified client reviews at 4.9 out of 5, with 5.0 on cost and 5.0 on willingness to refer. And our own AI operator has run in production for 27 months across two successive versions.
No spam. Just a practical audit.
Ready to remove your biggest software bottleneck?
Book a free 15-minute call. We will help you identify the highest-leverage automation, API integration, AI agent, or internal system to build first so your team can move faster with less manual work.
About Us
Features
Testimonials
Contact Us
© 2026 Bles Software, Yehud-Monoson, Israel. All Rights Reserved.