Software
When a spreadsheet should become an application
A spreadsheet should become an application when several people depend on it at once, when who may change what starts to matter, or when the same data is copied by hand between tools. Before anything is built, write down the data model and the permissions: they decide the cost more than the screens do.
The short version
Most business software starts life as a spreadsheet, and it should. A spreadsheet is the fastest way to find out what the work actually needs. It becomes a problem when it stops being a tool someone uses and becomes the system the business runs on.
Signs it has already happened
- Several people edit the same file at once, and someone has the job of fixing it when their changes collide.
- Some columns must not be changed by some people, and the only protection is asking nicely.
- The same customer, order or job is typed into two or three tools by hand.
- Nobody can say who changed a figure, or when.
- A new hire needs a walkthrough of which tab is the real one.
One of these is an annoyance. Three of them mean the spreadsheet is now a database with no rules, and the business carries that risk every day.
Check what you can buy first
If an existing product does the job (a booking system, an accounting package, a CRM), use it. Custom software earns its cost where the way your business works is the advantage, or where three bought tools have to be glued together by hand. Write down which of those applies before anyone draws a screen.
Decide the data model before the screens
Most failed builds are not failed code. They are a data model agreed in a meeting nobody wrote down, and a permission rule that lived in one person’s head. So the order matters:
- What the application stores: customers, jobs, invoices, and how they relate.
- Who may see and change each thing, written as rules rather than left to each screen.
- The two or three screens the work happens on, prototyped and clicked through before the rest is built around them.
Get the first two right and the screens are cheap to change later. Get them wrong and every new feature inherits the mistake.
Buy it in pieces you can stop between
A long build bought as one project is a bet that everything goes to plan. Bought in phases, each at a fixed price, it becomes a series of smaller decisions, and the application is usable after each one. That is how we approach custom application development: vertical slices, deployed as they land, in a repository you own from the first commit.
If what you have in mind is a product other businesses would pay for, the problem changes shape. See what a first SaaS version should include.
Article FAQs
Still have questions?The short answers.
Should a business build a web app or a mobile app first?
A web app first, in most cases. One browser-based codebase covers phones, tablets and desktops, and nothing waits on an app-store review. A native app earns its extra cost when the work genuinely needs offline use, push notifications, the camera or other hardware access.
How do you stop a custom software project running over budget?
Buy it in phases and ship it in vertical slices: one complete feature at a time, deployed and usable. A fixed price per phase means the cost is known before each phase starts, and if the budget stops halfway the business has half a working application rather than a whole unfinished one.
Who should own the code of a custom application?
The business that paid for it. The repository should sit in the client's own organisation from the first commit, with the supplier's access removable at any time, and the handover should include the deploy pipeline and written documentation so another developer can take it over.
