Poradnik
An app built with AI instead of a spreadsheet: when can a prototype go to IT?
A prototype application built with AI can sensibly be handed to IT when it shows the working process needed, sample data and the conditions for completing the task correctly. Launching it in the company still requires decisions on access, integrations, error handling and responsibility after go-live.
For an operations manager a prototype is a way of showing the need. For IT it can be material for assessing scope. Both sides gain if it is clear from the start which parts run on real data, which are a demonstration and what needs further work.
When does a spreadsheet start needing too much handling
The signal is a situation where employees spend more and more time obtaining information and correcting its consistency. Different versions of the file appear, entries are repeated and updates have to be chased by hand. The spreadsheet itself may still calculate correctly while the process around it becomes a burden.
Describe the flow of data: who creates it, who completes it and who takes decisions based on it. Sometimes changing how information is collected is enough. In other cases separate views, entry validation and notifications are justified.
AI can help build an application that then runs fixed rules and uses no AI agent in daily operation. Costs and maintenance depend on that distinction.
What the person who knows the process should show in a prototype
The most useful thing is one complete run, from entering data to the result. Include a case of an incomplete entry, corrections and a situation in which a person must decide.
Someone from the business side should be able to explain what each field means and which piece of information is the source of truth. A “save” button does not settle whether a record can be overwritten, who sees the change and how to recover the previous version.
Model scenario, fictional figures: the application is to handle 48 vehicles across four locations. Views are needed for 72 users and an administrator. Even at prototype level, show a booking, a mileage update and a clash between two bookings. The numbers describe an example for a conversation about requirements, not a real deployment.
A shared basis for the handover
- A working run
- Test cases
- Data
- Known limitations
What information makes it easier for IT to take over
Prepare a description of roles and permissions, data sources, connections used and the expected update frequency. Also record the cases the prototype does not handle. That lets IT assess the work needed for launch without guessing the author’s intent.
You need decisions on what happens when a source is unavailable, an entry is wrong or the run is interrupted. Say who should be told about a problem and how work should continue until it is fixed.
Handing over a prototype also covers the code, configuration and dependencies needed to run it. The vendor should be able to reproduce the solution in the agreed environment. That is a practical thing to check at acceptance.
How to judge whether the application improved the work
Measure the load on the whole process. If the administrator saves time but every employee has to do more, count both effects. Only the sum shows the change from the organisation’s point of view.
In a model comparison, 12 hours of work by everyone involved per week before the change and four hours after would mean eight hours recovered. Those are fictional values. In a real project such a result needs a measurement of the same activities at comparable volume.
Check data quality and application usage separately. The number of accounts does not say how many people actually book vehicles or update entries. A log of activity shows where the team still falls back on the old way of working.
Who is responsible for the application after launch
The process owner should know how the result is judged and how to report changes. IT or the agreed vendor needs a defined scope of maintenance. Decisions about further features are best based on real usage, reported problems and the cost of further work.
At dyrektor.ai we help connect employees’ knowledge with technical skills and take the agreements through to the next stage. If the scope is not yet clear, the criteria for choosing a pilot project will help.