Database Applications in New Zealand

The spreadsheet is the specification

Send it. Not a description of it — the actual file, with the real data in it, including the sheet called "old" and the one somebody hid.

It tells a developer more in twenty minutes than an hour of meetings, because it contains every decision the business has made and never written down:

• Columns used for two different things depending on the row.
• Rows that are really notes, subtotals, or a heading someone typed.
• Five spellings of the same supplier.
• A formula that encodes a pricing rule nobody has stated aloud since 2019.
• Colour coding that means something to one person.
• A column of dates, three of which are text.

Every one of those is a decision somebody has to make during the project. Found before quoting, they are lines in a brief. Found during the build, they are change requests.

Rule out what you may already own

If your business runs on Microsoft 365, you are already paying for SharePoint lists and Power Apps. Between them they handle a good deal of what people commission applications for, and they can be maintained by your own staff.

Airtable and similar tools are genuinely good for a list with a few views and a handful of users.

Building becomes right when you need:

• Real permissions — not everyone seeing everything.
• An audit trail that cannot be edited by the people it records.
• Rules the data cannot break, enforced by the database rather than by hope.
• Integration with your accounting or operational systems.
• Volumes or concurrency those tools handle poorly.
• An interface designed around your work rather than around a grid.

Ask each developer which tool they considered and what it would have missed. Silence from all five is worth a follow-up.

The rules live in people's heads

This is where these projects overrun, and it is entirely predictable.

Somebody knows that this customer always gets the old price, that orders over a certain value need a second signature, that the Tuesday delivery is treated differently, and that if the reference starts with a particular letter it goes to a different person.

None of it is written down. All of it has to be encoded.

The way to surface it cheaply is to sit with the person who uses the spreadsheet for two hours and watch them work, rather than interview them. They will do six things they would never have thought to mention. Ask each developer whether that is in their approach — the ones who have done this before will ask for it themselves.

Do not lose to the spreadsheet on speed

The most common reason these applications fail is that they are slower to use than the file they replaced, so within two months there is a private copy on someone's desktop and you are worse off than before.

Spreadsheets are genuinely fast. You can paste fifty rows, sort by any column, type across a row without touching the mouse, and see everything at once.

So ask specifically:

• How do I add twenty records at once?
• Can I complete a record without leaving the keyboard?
• Can I sort and filter on any column?
• How many clicks to do the thing people do fifty times a day?
• Can I still export to Excel?

That last one matters more than it sounds. Fighting the export loses; people will get their data out one way or another. Making it easy is what stops them keeping a shadow copy.

What you are actually buying

Be clear about the benefits, because they justify the cost and they are not "it looks nicer":

• One version. Nobody is working from Tuesday's copy.
• Permissions. Not everyone can see the margins or change a price.
• History. Who changed this, when, and what was it before.
• Rules that hold. A required field is required; a date is a date.
• Reports that are current without someone rebuilding them each month.
• No single point of failure in the shape of one person who understands the file.

If none of those matters in your case, keeping the spreadsheet is a respectable answer and a developer should be willing to say so.

Replacing Access has one extra problem

If the system being replaced is an Access database, it has probably run the business for a decade and contains reports people depend on and cannot describe.

Two things to insist on: an inventory of every report and form currently in use, produced before the build, with a decision on each; and the old database kept available read-only for several months after go-live. The second removes most of the fear from the changeover.

Also settle who is hosting the replacement. Part of the reason for moving is usually that a file share is a poor place for an application, so the answer should not be another one.

Comparing five quotes

Read for:

• Who asked for the actual file rather than a description?
• Who named an off-the-shelf tool that might do it?
• Who proposed sitting with the person who uses it?
• Who asked about bulk entry and exporting to Excel?
• Who listed the reports that must survive?

Send the spreadsheet, say how many people use it and how often, and describe the one thing about it that always causes arguments. Developers who have done this will spend most of the conversation on the file itself.