Most conversations about digital productivity tools in small businesses start in the wrong room. They start on the shop floor, or in the finance office, or with a well-meaning team member who found something on a podcast. Rarely do they start at the board table.
That is a governance gap, and it is widening.
Sitting on boards and chairing advisory boards for small and family businesses, I repeatedly see the same pattern. A business will run a rigorous process to approve a $40,000 piece of equipment. That same business will accumulate fourteen software subscriptions, grant three of them administrator access to the entire customer database, and never once table any of them at a board meeting.
The tools are not the problem. The absence of oversight is.
Technology is no longer an operational detail. It is a custodian of your customer data, a gatekeeper of your payments, and increasingly a single point of failure in your business continuity plan. Those are board matters.
Why the tech stack is now a director’s concern
Directors of Australian companies carry duties under the Corporations Act 2001 to act with care and diligence, and to act in the best interests of the company. Nothing in those duties carves out an exemption for software.
Three developments have made this concrete for small business boards.
- The Privacy Act reforms have narrowed the exemption
The small business exemption under the Privacy Act 1988, which has historically shielded businesses with turnover under $3 million, is under sustained review as part of the Commonwealth’s privacy reform program. The direction of travel is clear: fewer businesses will be exempt, and those that are exempt will still face reputational and contractual expectations from customers and larger clients who cascade privacy obligations down their supply chain.
A board that has never asked where its customer data is stored and what data we keep for how long is not positioned to answer that question when a client, an insurer, or a regulator asks.
- Cyber incidents are a small business problem
The Australian Signals Directorate reports that cybercrime costs Australian small businesses an average of roughly $49,600 per incident, with a cybercrime report lodged approximately every six minutes nationally. Small businesses are not incidental targets. They are chosen precisely because their controls are weaker.
- Fraud risk lives in the software
Let me say plainly what most technology conversations avoid. The overwhelming majority of internal fraud in small businesses is not sophisticated. It is enabled by a single administrator login shared across a team, an accounting package in which the same person creates the supplier and approves the payment, and a bank feed that nobody reconciles independently.
Segregation of duties is a control built into your software configuration. If your board has never seen the user permissions matrix for your accounting system, your board has not discharged its oversight of fraud risk.
The bespoke software trap
There is one risk I want to spend real time on, because it is the one I see cause the most damage and the one boards are least equipped to spot. I have also implemented bespoke software in my executive career.
At some point in the growth of a successful small business, someone will propose building something custom. A bespoke booking platform. A tailored inventory system. A purpose-built franchisee portal. The pitch is compelling: off-the-shelf software does not quite fit how we operate, so let us build exactly what we need.
Sometimes that is genuinely the right call. Often, it is a trap and it does not spring on the day you sign the development contract. It springs three or four years later.
What actually can go wrong
- The developer moves on. The individual or small agency that built your system takes a job elsewhere, retires, or closes. Nobody documented the architecture. The code is undocumented and idiosyncratic. What you own is an asset only that person could maintain.
- The knowledge never transfers. Bespoke systems are often built in close collaboration with one internal champion. When that person leaves, the institutional memory of why the system behaves as it does leaves with them.
- The technology stack ages out. A system built on a framework that was current in 2019 becomes progressively harder and more expensive to find developers for. The pool of people willing to touch it shrinks every year.
- Security patching stops. Commercial software vendors patch vulnerabilities as a matter of course. Bespoke software is patched only when someone is paid to do so. Nobody is paid to patch it because it appears to be working.
- The migration cost balloons. By the time the board accepts the system must be replaced, the business has years of data locked in a proprietary structure with no export path. The cost of leaving now exceeds the original build cost.
The question is never “can this be built?” It is “if the person who builds this is unavailable in five years, who else in the market can support it, and what would it cost us to find them?”
Questions a board should ask before approving any bespoke build
- What specific commercial outcome does this deliver that no available product can deliver, and how much is that difference worth in dollars per year?
- Is the system being built on mainstream, widely adopted technology, or on something the developer prefers?
- Who owns the intellectual property and the source code, and is that written into the contract? Do we hold a copy in our own repository, not the developer’s?
- What documentation will be delivered as a contractual obligation, not a good intention?
- Can we name at least three other providers in the Australian market capable of taking over this system?
- What is the data export path, and have we tested it before final payment?
- What is the ongoing support arrangement, what does it cost, and what happens if the supporting party ceases trading?
- What is the total cost of ownership across five years, including maintenance, hosting, patching and eventual replacement, compared with the subscription cost of a commercial alternative over the same period?
If a board cannot get satisfactory answers to those eight questions, the correct governance decision is to defer the build, not to trust the enthusiasm in the room.
A board-level framework for the tech stack
Boards do not need technical expertise to govern technology well. They need a disciplined line of questioning. The table below sets out the questions I bring to advisory board and NED discussions, and the answers that should concern you.
| Risk area | The question the board should ask | What a weak answer sounds like |
| Data custody | Where is our customer and employee data physically stored, and under whose jurisdiction? | “It’s in the cloud.” |
| Access control | Who can approve a payment and can that same person also create the supplier record? | “Everyone in the office has admin.” |
| Key person dependency | If the person who built or administers this system were to leave tomorrow, what would break? | “Only Dave knows how it works.” |
| Supportability | If the vendor or developer disappeared, who else in the market could maintain this? | “We’d have to rebuild it.” |
| Exit and portability | Can we extract our data in a usable format and move to another provider? | “We’ve never checked.” |
| Cyber resilience | When did we last restore from a backup to prove the backup works? | “It backs up automatically.” |
| Ownership | Who is accountable for this tool at management level, and what is it measured on? | “IT looks after it.” |
None of those questions requires the board to understand code. Every one of them requires management to have thought carefully. That is precisely the value a board adds.
My recommendations
Here is what I would put to any small business board or advisory board looking to bring discipline to this area. None of it is expensive. All of it is a matter of habit.
Establish a technology register and table it annually
A simple schedule listing every system in use: what it does, what it costs, who administers it, what data it holds, and who could support it if the current arrangement were to end. Most small businesses discover they are running twice as many tools as they thought, and paying for several nobody uses. Bring it to the board once a year as a standing item.
Default to supported, mainstream commercial software
Bespoke should be the exception you justify, not the option you reach for. If the business genuinely needs something that does not exist, first ask whether an available product plus a change to your process would get you eighty per cent of the way there. It usually would. Buying software to avoid fixing a process is one of the most expensive mistakes a growing business makes.
Contract for supportability, not just for delivery
Where a bespoke build is genuinely warranted, insist on source code escrow, contractually mandated documentation, IP ownership written into the agreement, mainstream technology choices, and a named alternative provider identified before you sign. Treat these as conditions of approval, not as nice-to-haves to negotiate later.
Test the backup. Actually, restore it.
An untested backup is a hope, not a control. Once a year, restore from backup and confirm the business can operate from the restore. Report the result to the board.
Review user permissions every six months.
Who has administrator access? Who has left the business and still has a login? Can any single person both create a payee and approve a payment? These take an afternoon to review and they are where fraud lives.
Assign named management ownership to every system.
Every tool has one accountable person and one measure of whether it is earning its place. “IT looks after it” is not ownership. If nobody owns it, cancel it and find out who complains.
Ask the exit question before the entry question.
Before approving any new system, ask how the business would leave it. If leaving is impossible or prohibitively expensive, you are not buying a tool. You are entering a dependency. Price it accordingly.
Good governance of technology is not about knowing more than management. It is about asking the questions management is too close to the work to ask themselves.
Bringing it back to the board table
Digital tools genuinely do lift productivity. I have seen it across restaurant operations, franchise networks, health services and community organisations. Automation removes drudgery. Good systems free people to do work that matters.
But productivity gained through technology and productivity retained through technology are different things. The first is a management achievement. The second is a governance one. It depends on whether the systems the business now depends on are documented, supported, controlled, recoverable and owned.
Small businesses in Australia do not fail because they chose the wrong project management app. They fail because a system nobody understood stopped working, and nobody could fix it.
That is the conversation your board should be having. If it is not on the agenda, put it on the agenda.
Frequently asked questions
Does a small business board really need to oversee software decisions?
Yes, at the level of risk rather than product choice. The board should not select the accounting package. The board should satisfy itself that customer data is protected, that segregation of duties exists within financial systems, that key systems are recoverable, and that the business is not dependent on a single individual or unsupported technology. Those are director-level obligations under the duty of care and diligence.
What is source code escrow and does a small business need it?
Source code escrow is an arrangement in which a third party holds a copy of your bespoke system’s source code and releases it to you if the developer ceases trading or fails to meet its support obligations. For any bespoke system your business genuinely depends on, it is inexpensive insurance and should be a condition of the development contract rather than an afterthought.
Is bespoke software always a bad idea for small business?
No. It is warranted where a genuine competitive advantage depends on a capability no commercial product offers, and where the business can absorb the total cost of ownership across the full life of the system. The mistake is treating bespoke as the default answer to “the software does not quite fit how we work.” Often the right answer is to change how you work.
How often should a small business board review its technology?
A full technology register review annually, as a standing board agenda item. User permissions and access reviews every six months. Backup restoration tested at least annually. Any new system exceeding an agreed-upon dollar threshold, or any system that holds customer data, should come to the board or advisory board before commitment.
What should an advisory board contribute to technology decisions?
An advisory board brings the independent challenge that management, operating inside the business daily, cannot bring to itself. Its role is not to pick tools. It is to interrogate the assumptions behind the decision: the total cost, the exit path, the supportability, the concentration of knowledge, and whether the underlying process was fixed before the software was bought.
Sara Pantaleo is a Melbourne-based strategic business advisor, non-executive director and advisory board chair. A Certified Fraud Examiner with more than 25 years of operational and governance experience, she currently serves on five boards and works with Australian small businesses on governance, franchising and sustainable growth through Affari SP.
Does your board have visibility of the systems your business depends on? Book a conversation about establishing an advisory board that asks the right questions.