Moving from Excel to a custom system makes sense when several people need to update the same data, formulas no longer represent the process and errors affect customers or deliveries. You do not always need to develop an application: first distinguish what is wrong with the spreadsheet from what is wrong with the way people work.
How can you tell that Excel is no longer enough?
One person opens “tracking_final_v7”, another corrects “tracking_final_correct” and a third confirms a delivery from a screenshot. This is a recognisable pattern in a growing business. The difficulty is the absence of a shared, reliable version of events. Changing the file name cannot resolve that.
Imagine a workshop making bespoke furniture. One spreadsheet records dimensions, another holds deposits and a third lists installation dates. With few orders, the team remembers exceptions. With simultaneous jobs, a changed measurement never reaches production and the customer receives a date nobody has approved. This is a hypothetical example, not a meiika client project.
A spreadsheet remains useful for analysis, calculations and reporting. Warning signs appear when it also becomes the database, permissions manager, operational calendar and notification system. Each of those roles needs its own rules. A sheet may display information clearly while leaving the underlying operation uncontrolled.
Look for five recurring symptoms: duplicate data; files emailed around to approve changes; formulas understood by one person; no way to reconstruct who changed a status; and reminders that depend on somebody remembering to inspect a cell. One symptom does not require custom development. Several recurring ones justify investigating alternatives.
Before requesting an application, record three actual incidents from recent weeks. Which value was wrong? Who noticed? How long did correction take? What would have prevented it? Evidence of an observable failure is more useful than a wish list of features. It gives the design a concrete purpose and a way to check whether it works.
What should an internal system do that a spreadsheet cannot handle well?
A custom internal system represents a company's particular work: its records, states, authorisations, tasks and connections. It need not be a large ERP. It can be a straightforward interface backed by a properly structured database, built around a limited operational need.
The first useful difference is validation when information is entered or an action is taken. If an order cannot enter production before dimensions are confirmed, the system should prevent that transition. If a quotation needs approval, it should remain pending until an authorised person decides. A formula colouring a cell red does not prevent an operation.
The second is traceability. A current status of “delivered” tells you little about how it got there. You may need to know when it changed, which user changed it and which reference supported the decision. Logging everything indiscriminately also has costs and risks. Define the events you actually need to investigate incidents.
The third is access by role. Someone preparing an order may need manufacturing instructions but no bank details. Customer service needs the status without necessarily being able to alter internal costs. Permissions should reflect the work, rather than the convenience of sharing one file with everyone.
The fourth is integration. Confirming an order could create a task, reserve materials or notify an owner. Each connection still needs conditions and error handling. Automating the wrong action spreads the error faster. Define the business rules before choosing connectors or deciding which notifications to send.
Should you choose no-code tools or custom development?
No-code and low-code platforms can build applications and workflows without writing every component from scratch. Microsoft documents ways to start a Power Apps application from Excel data, including importing it to Dataverse or connecting an existing table. These are architectural options, not a universal recommendation. Source: Microsoft Learn, creating applications from Excel, accessed 13 October 2026.
A no-code solution may fit a process with few exceptions, manageable permissions and platform terms the team can accept. It can also support an initial trial. Review licences, data export, connector limits, availability and dependence on the platform before choosing it. No-code still requires maintenance and a clear owner when something stops working.
Custom development becomes more relevant when a business needs unusual logic, integrations with less common systems or a particular experience for different roles. It also brings responsibilities: testing, documentation, hosting, security, updates and continuity when a supplier changes. Owning source code has limited value if nobody can deploy it.
Compare options using observable criteria: functional fit, exportability, permissions, integrations, maintenance effort, reversibility and ease of use. Avoid invented scores. Test a complete journey, such as creating, approving and closing an order, in each candidate solution. Include exceptions as well as the straightforward path.
Base the choice on evidence from your process. If a tool covers only part of the journey, check where information is stored and who can correct a mistaken operation. Being able to configure a workflow does not prove it can replace the business application you need.
How do you migrate without losing control of the data?
Migration starts by clarifying fields, rather than copying cells. “Date” might mean the order date, payment date or installation date, depending on who completes the sheet. “Customer” might identify a company, a person or a delivery address. If these ambiguities reach the new system, the interface changes while the underlying problem remains.
Inventory files, owners and uses first. Then create a data dictionary: field name, meaning, whether it is mandatory, permitted format and who can change it. Separate stable identifiers from names that can change. A customer may change its displayed business name; its internal identifier should not depend on that text.
Work from a copy and document records that are corrected or excluded. Microsoft warns that changing column types in some Power Apps import flows can remove incompatible values. Test conversions on a subset and retain the original intact. Source: Microsoft Learn, importing and connecting Excel data, accessed 13 October 2026.
Build a pilot covering the whole journey. Opening a record is not enough: simulate a correction, a change of owner, a cancellation, a search and an export. Involve both a frequent spreadsheet user and someone less familiar with the process. They are likely to reveal different usability problems.
During the transition, specify the source of truth. Letting people freely edit both the old sheet and the new application recreates disagreement. Parallel recording may help compare results for a limited period, but it needs clear rules and an end date. Avoid an irreversible change on your busiest day.
Before retiring the old method, prepare a recoverable backup, access permissions, an incident procedure and a named support owner. A simple application with a way back is more useful than an impressive interface without recovery. Treat continuity as part of delivery rather than a later addition.
What should you ask before requesting a quotation?
Start with the operational result. “I need an application with AI” does not describe the problem. “Approved orders should reach the workshop without anyone copying the details” allows someone to draw the journey and discuss where automation ends. The second statement also makes a pilot easier to assess.
Ask for scope covering users, actions, data, rules, integrations and exceptions. Who creates a record? Who can delete it? What happens when an external service does not respond? How is a wrong action corrected? Who receives an alert? These answers belong in the design rather than appearing later as surprises.
Clarify what the business retains: database access, documentation, credentials managed by the owner, export capability, handover procedures and maintenance responsibilities. The arrangement should remain understandable when the original developer is unavailable or a different supplier takes over.
Separate an essential first version from later improvements. If the goal is fewer order-handling errors, the first version may need states, permissions and history rather than demand predictions. A useful initial phase demonstrates that the process works without making every future idea a dependency.
How do we approach this at meiika?
At meiika, we approach custom systems through the work journey and its limits: which data is created, who decides, what can be automated and how an incident is recovered. Understanding the operation comes before recommending a tool.
When connecting that system to tasks currently performed by hand, the design must distinguish human decisions from automatic steps. The team needs to be able to use the system and retain control of it.