Custom Databases for SMEs: When Spreadsheets Stop Being Enough
A spreadsheet doesn’t set out to run a business. Someone builds it to track one thing, a supplier list or a job log, and it works well enough that other people start using it too. Then customer records go in, and stock counts and job notes, and the numbers behind a monthly report, until three or four people are opening the same file every day. The spreadsheet became the record system for part of the business without anyone deciding that it should, one added column at a time.
The tool is the same. The job it’s being asked to do isn’t, and that’s what decides whether a spreadsheet still fits or the business has quietly turned into a database problem.
The signs a spreadsheet has outgrown its job
A handful of signs tend to show up as the issue happens, and each one says something about how the process has grown. The software itself isn’t the issue. Several people start working from the same file at once, and duplicate or slightly different versions of the same record creep in because two people typed similar information into two different rows on the same day. Extra tabs and side spreadsheets start multiplying, each one built to work around something the original file can’t do. Reporting turns into someone rebuilding a summary from scratch every month, when a live view of the same information is already sitting there.
Excel isn’t at fault for any of this. A worksheet holds data in one flat table, up to 1,048,576 rows and 16,384 columns, according to Microsoft’s published specifications. The strain shows up the moment a business needs to link two or three of those flat tables together in someone’s head, cross-checking a customer list against a job log, which is precisely the job a database is built to do.
Why buying another app doesn’t always fix it
Buying a CRM or a project management platform is often the obvious next step, and for plenty of businesses it’s the right one. Standard software works well when a company’s process looks like everyone else’s, taking a customer through a typical sales cycle or tracking projects with clearly defined stages. The government’s SME Digital Adoption Taskforce sets out an ambition built on adoption of tools like cloud computing, CRM and resource planning software, estimating that even a 1% productivity uplift across UK SMEs could add £94 billion a year to GDP.
The friction shows up once a process doesn’t match the software’s assumptions. A business with unusual stages or industry-specific fields gets forced into a generic structure, and staff end up keeping a parallel spreadsheet to capture what the software can’t hold. Buying a second tool to cover what the first one leaves out can end up rebuilding the fragmentation the business was moving away from.
What changes once the data lives in a database
Microsoft’s own guidance on the two tools draws a clear line between them, with Excel suited to calculation, analysis and visualisation, and database software built for capturing, storing, querying and sharing information across a team.
Customer records, orders and stock levels become related tables that link to each other, so updating a customer’s address in one place changes it everywhere that record appears. There’s one current version of the information, because everyone is drawing from the same underlying data. Different people can be given different levels of access, so someone can update part of a record without seeing everything else it holds, something a shared spreadsheet can’t really enforce. Reports pull from live data, and routine steps, like flagging something overdue, can happen automatically, without anyone needing to remember to check.
The kinds of processes that hit this first
Stock and asset tracking is a common one. Products, quantities, locations and suppliers all need to stay linked as an item moves from arriving in stock to being invoiced against a job, and a spreadsheet struggles to hold that many moving parts without breaking. Customer and client records run into the same wall once contact details, orders, correspondence and service history need to sit against one record. And plenty of businesses simply run processes that don’t look like anyone else’s, with approvals, handoffs or sequencing that was never going to map onto a generic CRM or project tool. These aren’t case studies so much as patterns worth checking a business against, because the real test is how closely its own process matches the software already on the market and how much gets forced out of shape when it doesn’t.
Deciding if custom database development is worth it
Company size is a poor guide here. A five-person operation can run a genuinely complicated process, and a business with fifty staff can be served perfectly well by something off-the-shelf. What matters more is something closer to the ground, starting with how much daily operations depend on the process, and how much staff time gets swallowed by manual copying, double-checking and extra spreadsheets covering what’s missing. The same goes for how specialised the process is, and how many people depend on the exact same information at the same time. A business already contorting itself around software that doesn’t fit its process is another strong signal, and so is data that constantly needs shifting between systems that don’t talk to each other. Taken together, those factors are a far better guide to custom database development than the size of the business will ever be.
Getting from spreadsheet to database
A bespoke database is a natural continuation of a well-used spreadsheet. The Claris FileMaker platform exists to build custom business applications shaped by how a company already works, and it runs natively across Mac, Windows, iPad, iPhone and the web, with role-based access and record-level security built in from the start.
4TC builds FileMaker solutions from its London and Hertfordshire offices, and every project starts with the process that’s already there. The usual sequence is understanding how information moves through the business, working out what people need to see and do at each stage, and shaping the system around that before any existing data gets moved across. If a customer or stock spreadsheet already exists, that becomes the starting point for the new system. Anyone who recognises their own spreadsheet in the examples above might find it worth a look at 4TC’s FileMaker development work.
