We are not a big company. Is there really anything wrong with running things on spreadsheets?

Spreadsheets are genuinely a good tool early on: quick to pick up, highly flexible, and free. The real problems appear in three situations. The first is several people editing at once, where versions overwrite each other and there is no way to tell who changed what. The second is a process with a defined order and approval gates, which a spreadsheet cannot enforce — nothing stops somebody skipping a step. The third is data that other systems need to consume, which means copying and pasting by hand every time. If none of those three apply to you yet, continuing with spreadsheets is a perfectly reasonable choice; there is no need to adopt a system early just to look more established.

Off-the-shelf software or custom development — how do I choose without regretting it?

The test is how important this particular process is to your competitiveness. For general administrative work — bookkeeping, payroll, basic inventory and order handling — packaged software is usually mature and inexpensive, and insisting on customization is simply wasteful. What genuinely justifies custom development is the part where you do things differently from your peers and that difference is where your advantage lies. One further factor to weigh in parallel is portability: with packaged and platform-based options, confirm in advance that your data can be exported in full and that the system can be connected to others through an interface, so you are not stranded when you want to move.

We built the admin system and nobody uses it. What usually causes that?

The most common cause is a mismatch between the way the system requires people to work and the way they actually work, so colleagues keep their own separate records alongside it and the system becomes extra labor rather than less. The second cause is a rollout that covered only how to operate the software, without explaining why the change was happening and without retiring the old method in the process — leaving old and new running in parallel, both incomplete. The third is cramming too much into the first version, producing an interface so complex that simply locating the right button takes time. The way to avoid all three is to involve the actual users from the requirements stage, and to trial the system with a small group before rolling it out widely.

Admin System Development: Build or Buy

It started as a single spreadsheet of orders. Then a tab was added for stock, then a group chat for dispatch notifications, and then two days at the end of every month to assemble all of it into a report.

By the time you notice that “someone changed it and nobody knows”, that “the same order shows three different numbers in three places”, and that “the colleague who left took the file only they knew how to use”, the problem is no longer the tool. It is that the process has nowhere common to live.

This article is about when to move from spreadsheets or off-the-shelf SaaS to a custom admin system, how to scope the requirements, how to choose an approach, and how to avoid building something nobody uses.

Signals that an upgrade is due

Growth alone does not oblige you to adopt a system. The signals that actually matter are these.

One: the same data is copied several times. The customer enters it when ordering, sales records it, the dispatch note is typed up, finance keys it in again. Every copy is an opportunity for an error, and once there is an error it is hard to trace back to the source.

Two: the process cannot be enforced. A manager is supposed to approve before anything ships, but in practice anyone who wants to skip that step can, and it only comes to light afterwards. A spreadsheet cannot impose a gate.

Three: permissions rely on good manners. Everyone can see everything, including salaries, costs, and customer contact details. The only way to restrict anything is to open a separate file — at which point the two files begin to disagree.

Four: reports are assembled by hand. Every month somebody spends several days pulling the numbers together, and nobody can fully vouch for the result.

Five: there is no history. Why was this order repriced, by whom, and when? There is no record.

Six: systems are not connected. The website, payments, logistics, and customer support all operate separately, with people ferrying data between them. This one is really an integration problem; for how to approach it, see the guide to system integration and API development.

If only one or two of these apply, deal with that one item. Four or more usually means the process has outgrown what a spreadsheet can carry.

Three dimensions to scope requirements across

The most common starting point for a failed admin project is a requirement that says only “we want a back office for managing orders”. To make this estimable and testable, at least three dimensions have to be scoped.

One: process

Draw the full path a record takes from creation to completion: who creates it, which states it passes through, who advances each state, which circumstances send it back, and when it counts as finished.

Ask specifically about the exceptions. The normal path is usually easy to write down; what consumes the hours is the exceptions — what happens on a cancellation, on a partial shipment, how the accounts are corrected after a return, how an urgent insertion is prioritized. In the spreadsheet era these were handled in somebody’s head. Moving into a system means defining them explicitly.

Two: roles and permissions

List every role that will use the system, and answer three questions for each: what can they see, what can they change, and what can they approve.

The usual blind spot is thinking only about your own department. In reality you also have to consider what managers need to view, what finance needs for reconciliation, whether external partners need limited access, and how permissions are revoked when somebody leaves. The later permissions are designed, the more expensive they are to change, because they permeate every screen.

Three: reporting

Ask “what decision is this number going to inform” before deciding what the report looks like. A great many reporting requirements are simply a transcription of an existing manual table, and the format of that table may only exist because it was convenient to lay out in a spreadsheet years ago.

What to confirm: how often it is reviewed, who reads it, whether it needs to be exportable, and how the definitions are set (does revenue count from the order date or the shipping date, is it inclusive of tax, how are returns deducted). If the definitions are not agreed, the finished report will always be told the numbers are wrong.

For a method of writing these three dimensions into a document, see how to write a software requirements specification.

Packaged, low-code, or custom: making the trade-off

Approach	What it suits	Main limitation
Off-the-shelf software	General administrative work (bookkeeping, payroll, standard inventory and orders)	The process has to bend to the software; limited room for customization
Low-code platform	Simple processes, shifting requirements, wanting to trial quickly	Complex logic hits a wall; data and screens are hard to migrate
Custom development	Where the process is your competitive advantage, or existing systems must be connected	Higher initial investment; requires clear requirements
Hybrid	Packaged software for the general parts, custom for the critical process, connected together	Requires planning for integration and data consistency

The core question is whether this particular process is where you differ from your peers.

For work like bookkeeping and payroll, the way it is done is much the same across Taiwan, the mature products on the market are cheap and stable, and customizing them makes almost no sense. Conversely, if the way you take orders, schedule work, or price jobs is itself where your advantage lies, forcing it into the fixed process of a packaged product means grinding that advantage away.

Low-code platforms deserve a sentence of their own: they are very well suited to validating requirements. Before committing to custom development, build a working version quickly on a platform and let colleagues use it for a month or two. You will find that some of the requirements on the original list are never used at all, and that critical requirements nobody thought of will surface. This is the same reasoning behind building a minimum viable product.

One thing to watch is portability: whichever you choose, packaged or platform, confirm in advance that your data can be exported in full and that the system can be connected to others through an interface. A system you cannot move out of will constrain your options later.

For a comparison of the real costs of hiring engineers versus engaging an external team, see outsourcing versus building an in-house team.

Five common failure modes

One: it gets built and nobody uses it. The way the system requires people to work does not match the way they actually work, so colleagues maintain their own records alongside it and the system becomes additional labor. The root cause is almost always that the real users were not involved at the requirements stage.

Two: the process was never changed, only the place it is typed into. A messy process transplanted unaltered into a system stays messy, and is now harder to adjust than it was in a spreadsheet. Adopting a system should be the occasion to tidy the process up.

Three: too much in the first version. The reasoning goes “if we are doing it, let us do all of it at once”, and the result is a complex interface, a long development period, and requirements that have changed again before launch. More features is not the same as more usable, and in most admin systems only a handful of screens genuinely get used every day.

Four: the data was not cleaned before migration. Duplicates, errors, and inconsistent formats in the old data are carried into the new system untouched; after launch the numbers do not reconcile and colleagues quickly stop trusting the system. For the risks of data migration and how to audit it, see the legacy system modernization guide.

Five: only the boss wants it. The requirement originates with management wanting to see numbers, but the people entering the data are frontline staff who get nothing out of the system. In that situation data quality will certainly deteriorate. The fix is to make the system valuable to the people entering data too — pre-filling frequently used values, removing duplicate entry, letting them look up the information they themselves need.

The most direct way to judge whether these risks have been cleared is to ask frontline colleagues one question before launch: if the old method were switched off tomorrow, would you feel relieved or inconvenienced? If the answer is the latter, something is still unresolved.

Launching in phases

An admin system is a poor candidate for a single full cutover, because it is tied to live operations and the cost of a failure is the business stopping. A steadier rhythm looks like this:

Phase one: get one main line working end to end. Pick the most painful and also the most straightforward process (order intake through to dispatch, for instance) and build it until it runs completely, leaving reporting and peripheral features out. The goal is for a small group of people to genuinely use it every day.

Phase two: extend to related processes and permissions. Adjust based on the real feedback from phase one, then bring the other roles and processes in.

Phase three: reporting and integration. Reports only become meaningful once enough clean data has accumulated in the system; connections between systems belong in this phase too.

Every phase needs a firm date on which the old method is switched off. Run old and new in parallel for too long and both sets of data end up incomplete, at which point nobody trusts the system.

NETVANA’s software development process works in two-week sprints with a working demo at the end of each cycle, which suits exactly this kind of internal system where adjustment happens as you go — you can trial it in a real environment early, rather than seeing the finished product for the first time at acceptance. At project close, source code, design files, and documentation are handed over in full, which matters especially for an admin system, because it will stay with the company for many years.

The value of an admin system is not in its screens. It is in taking rules that were scattered across the organization and living in particular people’s heads, and turning them into a process the whole organization shares. Get that right and new joiners get up to speed faster, handover risk falls, and the numbers management sees can finally be relied on.

If you are weighing packaged software, a platform, or custom development, or you want to clarify the process before deciding how much to invest, talk to NETVANA about your requirements. NETVANA’s consulting services include technical architecture review and technical due diligence, and our software services are quoted after an initial consultation; for what each service includes and delivers, see the software services overview.

Further reading: for how to write requirements and acceptance criteria, see how to write a software requirements specification. For how to connect systems to each other, see the guide to system integration and API development. And for a cost comparison of outsourcing against an in-house team, see outsourcing versus building an in-house team. For pushing admin alerts to staff through an official account, see The LINE Bot Development Guide; and for adding AI features once the workflow is clear, see Adding AI Features to Your Business; and for which membership and CRM features you actually need, see Building a Membership and CRM System. For turning the data your admin system collects into reports, see Reporting Systems and Dashboards; and for the in-store variant of the same back-office problem, see POS and Retail System Development. Before building a custom internal tool, run it through this buy-or-build framework; see Buy SaaS or Build Custom Software. Before building custom admin tools, check signals a low-code platform is hitting a wall; see Are Low-Code and No-Code Platforms Right for You. For the same spreadsheet-or-custom question scaled up to a full ERP rollout, see ERP Selection for Small and Medium Businesses.