Admin panel instead of a spreadsheet: when your business has outgrown Excel

Someone sorts a single selected column in a spreadsheet instead of the whole table, and from that moment the phone numbers no longer match the names. Nobody notices for a week, because the file still looks tidy. That is usually how a business finds out it has outgrown Excel, and how the period in which the spreadsheet was the best tool in the company comes to an end.

The short answer to the question in the title: a business is ready for its own admin panel when the spreadsheet stops being a place where information is recorded and becomes something that has to be guarded so nobody breaks it. The number of rows matters less here than the number of people editing the file and the number of places the same data then has to be copied to.

Signs you have outgrown the spreadsheet and it is working against the team

A single problem with a spreadsheet is not yet a reason to build a system. Every file has its quirks, and every team has someone who overwrites something in it once a quarter. The signal is repetition: when the same problems come back every week and the team starts building rituals around the file to protect it.

These are the situations that most often show the line has been crossed:

• Asking which version is current. The folder holds files labelled "final", "final2" and "corrected", and before every decision someone has to check which one is the real one.
• Hiding columns instead of setting permissions. Margins, rates or contact details are hidden so that part of the team cannot see them. A hidden column is still in the file.
• The same data in several places. An order goes into the spreadsheet, then into the invoicing software, then into an email to the warehouse. Every time it is retyped is a chance for a typo.
• Formulas only one person understands. When that person is on holiday, the monthly report waits, or it comes out with an error nobody can find.
• Row colour as status. Green means "paid", yellow means "waiting for the customer", and a new team member learns this by word of mouth.
• Reports assembled by hand. At the end of the month someone spends several hours filtering, copying and stitching data together into a summary for management or the accountants.

One of these can usually be fixed by tidying up the file. Two or three at once mean the problem is not how the spreadsheet is organised but what it is being used for. A spreadsheet was designed for calculation and analysis, and the business is using it as a database with many users, permissions and a process.

People's behaviour is a signal too, not just the state of the file. If employees keep private copies because "someone always changes something in the main one", or post "don't touch the orders tab right now" in the team chat before editing, the team has already built itself a primitive locking system. A panel does the same job without relying on human memory.

What a spreadsheet cannot do, even when it is well organised

Many problems with spreadsheets can be eased with discipline: one row per record, no merged cells, drop-down lists in the status columns. But there are things no amount of tidiness will fix, because they come from the nature of the file itself, not from the way it is kept.

The first is permissions. In a spreadsheet you can lock a range against editing, but you cannot set it up so that a salesperson sees only their own customers and the warehouse sees only the delivery address without the amounts. Whoever has access to the file has access to all the data in it, and a hidden column is present in every copy and every downloaded file. In a panel, permissions are a rule enforced on the server: data a user should not see never reaches their browser at all.

The second is validation across fields. A spreadsheet will check that a cell contains a date, but a rule such as "status shipped requires a tracking number" or "the shipping date cannot be earlier than the order date" already calls for formulas or scripts. On top of that, pasting data into cells with validation can simply bypass the validation. A form in a panel will not save a record that breaks the rules, whether the data was typed in by hand or imported.

The third is relationships. A customer has many orders, an order has many line items, a line item refers to a product. In a spreadsheet this ends with the customer's details copied into every order row. When the customer changes address, it has to be corrected everywhere, and a single missed place means a parcel sent to the old address. The database behind a panel keeps the address in one place, and the orders simply refer to it.

The fourth is history and accountability. A file's version history will show that something changed, but quickly answering "who changed the order status, and when?" means digging through the history of the entire document. A panel can record every important operation separately, with the time, the user and the previous value.

The last row of the table matters: for ad hoc analysis a spreadsheet beats a panel, and that will not change. That is why a well-built panel exports to CSV or XLSX. The data lives in the system, and anyone who wants to slice it in a pivot table downloads the file and does it on their own machine, with no risk of breaking the source.

When the spreadsheet stays, and that is the right decision

Not every business with a spreadsheet needs a panel, and that has to be said honestly before we get to costs. If one or two people work on the file, sit next to each other and the data changes a few times a week, a system of your own will cost more to maintain than the problems it would solve.

A spreadsheet also wins when the process is still taking shape. A panel locks in a way of working: statuses, fields and permissions are written into code, and changing them takes a developer's time. If every month you add new columns, change what the statuses mean and try out a different split of responsibilities, a spreadsheet is the right tool for the experiment. Building a system on a process that will look different in three months ends in a rebuild.

The third situation is data used mainly for calculation: financial models, price simulations, forecasts. This is exactly what spreadsheets were invented for. A panel can display that data, but it will not replace the freedom with which an analyst rearranges formulas.

Nor will a panel fix a process that is chaotic for other reasons. If the team does not know who is responsible for an order once it has been accepted, the system will only move that argument from the chat to a "responsible person" field that nobody fills in. First agree how the work should flow, and only then write it into code.

The in-between stage: a tidy spreadsheet, forms and no-code tools

Between a chaotic file and a system of your own there is a stage many businesses skip, and it pays off whatever you decide later. The idea is to make the spreadsheet look like a database before it becomes one.

In practice that means a few rules you can introduce in a single afternoon:

• One source file. Working copies are allowed only for analysis, never for entering new data.
• One row is one record. No subtotal rows in the middle of the table, no merged cells, no headers repeated every fifty rows.
• A separate tab for lookup lists. Statuses, categories and salespeople's names picked from a list, not typed in by hand in seven different spellings.
• A column with a unique ID. A number that does not change when you sort and that lets you find the record in other documents.
• A form for data entry. Instead of adding rows by hand, the team fills in a form that saves the answers to the spreadsheet in a fixed format.

The next step can be no-code tools, meaning cloud databases with ready-made forms, views and simple automations. For many teams that is a sensible solution for months or even years. Before you choose one, check the specific tool's pricing: how the per-user fee is calculated, what the record and automation limits are on a given plan, and in what format you can export your data when you want to move. Logic built in such a tool usually cannot be exported, so when you move to your own system it has to be rebuilt.

The biggest benefit of this stage is that a tidy spreadsheet becomes a ready-made description of the data model. When you later talk to a developer about the panel, the lookup tab tells them which statuses the system has, the columns tell them which fields the forms need, and the ID column makes the import easier. The project starts from something concrete, not from piecing together knowledge from people's heads.

Count the cost of the spreadsheet before you ask what a panel costs

A conversation about a panel usually starts with "how much will it cost?". A better starting point is "how much does our current way of working cost us?", because only that number tells you whether any quote makes sense.

The method is simple. List every recurring task connected with the spreadsheet: retyping data into other systems, correcting mistakes, looking for the current version, assembling reports, answering "what stage is my order at?". For each one, note who does it and how long it takes in a typical week. Do not estimate from memory: log the real time for a week, because estimates off the top of your head are almost always too low or too high.

A sample calculation, to be replaced with your own numbers: if three people each spend half an hour a day retyping and checking data, then with 21 working days that comes to 3 x 0.5 h x 21 = 31.5 hours a month. Multiply that by the hourly cost of those people's work and you have a monthly cost you are already paying; it simply does not appear on any invoice.

Add the cost of mistakes to the hours, because they are rarer but more expensive: a parcel sent to an old address, an invoice that was never issued, a customer who received two contradictory confirmations. Write down the single-person risk too: what happens to the reports if the person who owns the formulas leaves the company. These items usually cannot be priced precisely, but list them so it is clear they are not zero.

An honest note to finish: hours saved do not always turn into money. Often they turn into time for work that has been put off until now. If the calculation shows two hours a month, the panel will not pay for itself, and you are better off staying with a tidy spreadsheet.

What goes into the first version of the panel, and what can wait

The most common mistake with a first panel is trying to put into it every idea the team has collected over the years. The project grows, the deadline slips, and the whole time the spreadsheet keeps running with all its problems. The first version should do two things: replace the spreadsheet in daily work and fix the two or three places that hurt most.

In practice the first version of a panel that replaces a spreadsheet usually includes:

• A data model. Tabs and columns from the spreadsheet turned into database tables with relationships, for example customers, orders and order lines.
• Login and roles. Accounts for the team and a basic split of who sees what and who can change what.
• Lists with filters and search. The equivalent of the spreadsheet, but with sorting that does not scramble the data and filters everyone can save for themselves.
• Forms with validation. The rules that today live in employees' heads, written down as conditions checked when a record is saved.
• Statuses with history. Instead of a row colour, a status field and a record of who changed it and when.
• Export to CSV or XLSX. So that accountants and analysts can keep working in their own software.
• A dashboard with a few numbers. The ones someone currently works out by hand, for example the number of orders in progress or the total of unpaid invoices.

What can usually wait: integrations with further systems, elaborate charts, phone notifications, custom user views and a mobile version. That does not mean they matter less. It means they are easier to design well once the team has worked with the first version for a few weeks and seen what it really lacks. The exception is integrations that remove the largest share of the manual work from the previous section. If most of the hours go into retyping data into the invoicing software, that integration belongs in the first version.

Security is not on the list of things for later. A panel has access to the whole company's data, so the level of protection for login, sessions and operation logging is set at the start, in proportion to the data it will hold. The detailed scope of what a panel can include, from roles and permissions through export to integrations, is described on our Panels & Dashboards page.

Moving data out of the spreadsheet: the part nobody talks about

Developers are keen to show screens of the future panel and rarely ask about the state of the data. Yet it is the import from the spreadsheet that most often takes longer than planned, because data entered by several people over several years is almost never consistent.

Typical problems that surface on the first import attempt:

• Dates in several formats. Some stored as the text "12.03", some as "2026-03-12", some as a number the spreadsheet merely displays as a date.
• The same value in many variants. The statuses "shipped", "shiped", "SHIPPED" and "ok" mean the same thing to a person, but to a database they are four different statuses.
• The "notes" column. It holds information that should be separate fields: payment method, preferred contact hours, a discount agreed verbally.
• Duplicates. The same customer recorded as a company under its full name, under an abbreviation and under the owner's name.
• Merged cells and helper rows. Totals, section headers and empty separator rows, which turn into fake records on import.

A well-run data migration looks like a small, separate project with its own steps:

Step five is the most valuable, because it reveals errors that have been invisible in the spreadsheet for years. Sometimes the rejected rows report alone justifies the project, because it turns up orders with no customer or invoices with no amount.

How to prepare for the conversation with a developer

The more concrete material you bring to the first conversation, the sooner you get a quote that reflects reality. You do not need a technical specification. You need material that shows how you work today.

What to prepare:

• A copy of the spreadsheet. If it contains customers' personal data, anonymise it or replace it with sample data, keeping the formats and the mess. The developer needs to see the real structure, not real names.
• A list of roles. Who uses the data, and what each of those people should be able to see and change.
• The record's path. The steps from creation to closure mentioned above, along with who is responsible for each transition.
• Reports made by hand. Ideally a sample report from last month, so it is clear which numbers should calculate themselves.
• The surrounding systems. Invoicing software, online store, courier company, CRM, email. For each one, whether data should go there or come from there.
• The biggest problem. One sentence about what hurts most today, because that decides what goes into the first version.
• Deadline and pace. Whether you want a quick version that replaces the spreadsheet straight away, or a polished system with the full scope.

At the first stage we ask three questions: what the panel should do, for whom, and what happens if you do not build it. The last question sounds odd, but it is the one that shows whether the project is justified. If the answer is "nothing in particular, we'll keep doing it in the spreadsheet", the best advice is often to tidy up the spreadsheet and come back to the subject in a few months.

If the spreadsheet contains data you do not want to show without an agreement in place, we sign an NDA on request before any material is exchanged. Remember too that when a developer is going to work on production personal data, for example during the import, you need a data processing agreement within the meaning of Article 28 of the GDPR. That is the obligation of the data controller, meaning your company, regardless of whom you hire.

How much does an admin panel cost and what drives the price

We price Panels & Dashboards from 699 PLN (Polish zloty). That is the lower bound for a small panel with a simple data model, not a package price, because we have neither packages nor a fixed price list. For a general outline of a project we give a price range, and an exact figure once the scope, deadline and requirements are agreed. Quotes and advice are free.

The price is driven most by factors that are easy to assess from the material in the previous section:

Integrations deserve a sentence of their own, because they are the hardest to estimate from the outside. Every system the panel has to exchange data with has its own API, its own limits and its own documentation of varying quality. That is why, when we quote, we ask for the specific names of the software you use, not a general "integration with invoicing".

We usually split payment into three equal parts, 33/33/33, tied to the stages of the project. The price includes a buffer for revisions equal to 15% of the project time, so small corrections after testing do not mean an extra invoice. During the work you have access to the repository and the staging environment, and at the end you get full rights to the code and documentation that lets another team take over the system. Starting prices for our other services are on the offer page.

The first weeks after launch

The day of the final import does not end the project. It starts the period in which you find out whether the panel has really replaced the spreadsheet. The first weeks say more about the quality of the system than all the earlier presentations put together.

The most important signal to watch for is people going back to the spreadsheet. If someone on the team opens the old read-only file even though they have access to the panel, ask what they were looking for. Usually it is a specific piece of information the panel does not show conveniently, or a view that took one click in the spreadsheet and takes three in the panel. That is not a failure of the project; it is exactly the kind of information the revision buffer is there for.

The second signal is fields nobody fills in. If the "responsible person" field is empty in most records, either it is unnecessary or the process is not as settled as it seemed during the conversations. Either way, it is better to notice after a few weeks than after a year.

For the first weeks after launch the system is monitored, usually for 90 days at no extra cost. Keep the read-only spreadsheet for an agreed period as a reference point, and then archive it. The panel's export stays for good, so people who like analysing data in a spreadsheet can carry on doing so, just on a copy rather than on the source.

Where to start this week

Deciding on a panel needs no upfront spending. It needs a few hours of organising knowledge that will be useful whichever option you choose, including if you decide to stay with the spreadsheet.

This list has one more advantage: after a week you have material you can show any developer, not just us. Comparing several quotes is much easier when everyone received the same record path, the same hours and the same description of the biggest problem, because then the differences in price come from the approach, not from each company guessing the scope differently.

If after that week the numbers show that the spreadsheet costs more than it gives, write to us through the contact form and send what you have collected. We reply within an hour, you talk to the person who will write the code, and if we think that in your situation you are better off staying with the spreadsheet, we will tell you so plainly. How the whole collaboration works, from the first message to support after launch, is described on our process page.