A new model needs to go on sale. Until recently that meant logging in, creating the product, typing the description, uploading six photos and matching the right sizes to the right images, setting the category, entering the delivery date, correcting the stock level. Five screens, a few dozen clicks, and all of that for every single bike. Today the same person writes one sentence: “Add the new trekking bike from this supplier, take the description from the catalog, sizes 51 to 59, delivery in April.” An AI assistant handles the rest.
This is not a future scenario. It is everyday work in one of our own products. The interesting part is not the technology but the starting point: the software already existed, it worked, and people still found it tedious. We see that exact combination in a lot of companies. Using this example, we explain what artificial intelligence actually changed, what we deliberately kept the same, and how to tell whether the same step would pay off for your software.
The short answer: when this step pays off
Adding AI to an existing application is worth it when people spend part of every day entering, correcting, or moving the same kind of data by hand. The AI does not replace your screens. It replaces the busywork in front of them. Your software stays as it is and gains a controlled route through which an AI assistant is allowed to perform specific tasks inside it. That is a manageable extension, not a rebuild. It pays off far less where data is only maintained occasionally, or where every single case calls for its own professional judgment.
What a classic input screen does well, and where it eats time
A well-built interface is not the problem. It guides you through a task, prevents bad entries, marks required fields, and shows what is actually stored in the system. For a single, careful transaction it remains the best tool available, which is why we do not get rid of it.
It only becomes exhausting at volume and through repetition. A screen is designed for one transaction. When thirty bikes need a new category, a sensible process turns into the same process thirty times over. There is a second effect that is easy to miss: anyone who uses the screen rarely has to hunt for which field sits behind which tab, every time. That does not cost hours in one block. It costs many minutes spread across the day, and it is exactly the kind of work everybody puts off.
The third point hits development. In a classic application, every special case needs its own answer on screen: an extra field, a new filter, a bulk-edit view. All of that is doable, but it takes time and money, which is why plenty of small requests sit on the list for years.
How an internal tool turned into an AI application
In 2024 we built a reservation app for bicycles, initially for internal use. It lets bike dealers and sales staff show bikes on a tablet, reserve one for a specific customer, and sell it even while it is still nowhere near the showroom. That tool has since grown into a product of its own, RadVoraus (the product site is in German).
The benefit was obvious from the start. So was the price of it: before anything presentable can appear on the tablet during a sales conversation, somebody has to maintain the lists. Every bike with images, product descriptions, categories, reorders, and stock status. That took real effort, and it cost more than time. Anyone who has done this work knows the feeling that it is never quite finished.
So we built a connector for the AI assistant Claude, technically an MCP server. Behind that unwieldy term sits something simple: a standardized, controlled connection through which an AI assistant may use clearly defined functions and data inside your software. Not everything, only what you release to it.
Since then Claude handles the maintenance work on its own: revising bikes, recording reorders, creating and assigning categories, correcting availability per frame size. Retail staff used to type every one of those changes into the shop interface. Today one sentence with the necessary details is enough, naming the model, size, supplier, or delivery date. A simple internal online shop has become an AI application.
The old interface has not disappeared, though. It is now used for checking the result and for small manual corrections, while the bulk of the repetitive work runs through the AI. That is deliberate rather than a transitional stage. Glancing over a finished list is faster than asking a question, and it gives people confidence.
What changes in day-to-day operations
The most noticeable difference is not a new feature. It is that work gets described instead of executed. Three effects show up particularly clearly in practice:
- Productivity: Recurring maintenance work gets triggered instead of clicked through step by step. With bulk changes across many products in particular, the purely repetitive part of the job disappears.
- Ease of use: Someone who can describe a task in their own words does not need to know which field sits behind which tab. That noticeably shortens onboarding for new or seasonal staff and takes the fear out of the software.
- Flexibility: A special case no longer needs its own screen right away. As long as the released functions cover it, an unusual requirement can simply be phrased differently instead of being scheduled as a change request.
We deliberately quote no percentage for the time saved. We never measured the effort beforehand, and an invented figure would not help you decide. What we can say is this: the share of maintenance work that runs through the interface has dropped from “almost all of it” to “checking and small details”.
Why older software often cannot keep up here
Many of the applications running in companies today were designed before AI assistants were practically usable. They assume a human sits in front of a screen and fills in fields. That is not a design flaw, it is a point in time. It does mean, however, that such software only offers the outside world what is visible on screen, and an assistant can do very little with that.
That is why we plan for AI as a standard part of our software projects. This is not a claim that our applications are better than anyone else’s. It simply means the connection point for an AI assistant is designed in from the beginning instead of being retrofitted later. For you as a client, that is mainly a question of sequence and cost: what is considered from the start does not require a second round of construction later.
The good news for everyone with existing software is that retrofitting is possible, and it is considerably cheaper than it sounds. RadVoraus is exactly that case. The application was finished, it was running, and it still got a second wind without us rebuilding it. What keeps software competitive today is less a matter of new features than of how much manual work it takes off the people who use it every day.
You stay in control
An AI assistant that is allowed to change data raises fair questions, and those questions belong before the implementation. We settle three of them first in every project: which functions may the assistant carry out, and which explicitly may it not? Who is allowed to use it, and with what permissions? And how does the business see afterwards what was changed?
Scope is the most important tool here. A connector releases precisely the functions that are meant to be released, not the entire database. Reading, changing, and deleting can be handled separately, and sensitive operations deliberately stay in the interface where a person confirms them.
It belongs to an honest account that an AI assistant occasionally reads an instruction differently than it was meant. That is precisely why the familiar interface remains as a check. For anything where a misunderstanding would be expensive, such as accounting entries or binding prices, we recommend explicit human approval. Which processes need it is not decided by the technology but by your risk.
Which data needs particular protection, and which use cases are worth doing at all, is something we work out with you beforehand. Our approach to that is described in more detail in our article on AI consulting for businesses.
How to tell whether this is worth it for you
You do not need a technical analysis for this assessment, just an honest look at your week. The more of the following points apply, the more likely the step is worth taking:
- Someone regularly maintains master data, products, prices, dates, or stock levels by hand.
- The same change often affects many records at once.
- Information gets retyped from another source, such as a supplier catalog or a spreadsheet.
- New employees take a long time before they can use the software confidently.
- Small change requests never get built because the effort is hard to justify.
- Maintenance work gets postponed, and data quality visibly suffers for it.
If few of them apply, we will tell you that too. When your application is filled only occasionally, or when every case requires its own professional judgment, AI access adds little and your money is better invested elsewhere.
Conclusion: your software does not have to be new to feel modern
For the people who use it, the value of an application is not decided by how new it is but by how much manual work it takes off their hands. Extending existing, working software with controlled AI access is therefore often the faster route than a rebuild. The interface stays for checking and special cases, and the daily busywork shrinks into a sentence. That is exactly what happened with RadVoraus.
Do you also run software that swallows a lot of time in data maintenance? Then talk to us about whether and how it could be upgraded with AI. We will look at which processes are suited to it and which are better left in the hands of your staff. Preparing a quote is free and comes with no obligation. If you would first like to know how we build applications in general, our article on mobile app development from one build is a good starting point.
Frequently asked questions
Do we have to have our software rebuilt for this?
As a rule, no. What gets added is a controlled connection through which the AI assistant may use specific functions. The application itself stays in place. The requirement is that the functions you want can be addressed technically. Whether that is the case with your software takes only a short look at the system, and we will say so if the answer is no.
Does the AI get access to all of our data?
No, and that is the decisive part of the implementation. Only what is meant to be released gets released. Access is cut to individual functions and data areas, reading and writing can be separated, and particularly sensitive operations are deliberately left out. Which data that means in your case is something we define together before anything is built.
Does every employee then need their own AI account?
That depends on the setup. With RadVoraus, staff work directly in the AI assistant and need access there. Alternatively, the AI function can be built into the existing application so your people still open only one tool. Which option makes more sense depends on how many people use it and how often, and it affects the running costs.
What happens when the AI misunderstands something?
You have to expect it, which is why the existing interface remains as a check. A product description created the wrong way stands out during review and is fixed in a minute. For operations where a misunderstanding would be expensive, we build in explicit human confirmation before the change takes effect.