Is Custom Software Secure? What Small Businesses Should Ask Before They Build

It comes up in almost every scoping conversation, usually near the end, usually phrased as an apology. This is probably a dumb question, but — is this going to be secure?

It is not a dumb question. It is one of the better ones, and the honest answer is that it depends entirely on who builds it and what you asked for. Custom software is not automatically safer than the platform you are using now, and it is not automatically riskier either. Security is not a property that software has or lacks by category. It is a set of decisions somebody made, or didn’t.

The good news for a small business owner is that you do not need to understand encryption to evaluate this. You need to know where the actual risks are, and you need to be able to tell the difference between a developer who has thought about it and one who is going to reassure you and move on.

The comparison you are actually making

When owners ask whether custom software is secure, they are usually comparing it to a well-known commercial product — something with a marketing site, a compliance page, and a security team listed on it. That feels safer. Sometimes it is.

But the comparison is less lopsided than it looks. Custom applications and commercial platforms are built on the same foundations: the same web frameworks, the same databases, the same cloud infrastructure from the same handful of providers. A custom application built by a competent developer runs on infrastructure that is just as hardened as what sits under the big platform. Nobody is spinning up a server in a closet.

There are real advantages on each side, and they are worth being clear-eyed about:

• A large vendor has a dedicated security team, formal audits, and a public track record you can look up. That is genuine value, and a solo developer cannot match it.
• A large vendor is also a much bigger target. Thousands of attackers actively probe widely used platforms because one working exploit gets them into every customer at once. Your internal scheduling tool is not on anyone's list.
• A custom application typically holds less data and has a smaller attack surface. It does what your business needs and nothing else — no marketplace of third-party plugins, no dormant features nobody uses.
• A breach at a shared platform is a breach of everyone on it, including you. Your data is in the blast radius of decisions you had no part in.

The place custom software genuinely can fall behind is where nobody was responsible for security. A vendor has to care because their whole business dies with a breach. A developer building one application for one client only cares if that is how they work. That is the gap the questions in this article are designed to close.

Where small business breaches actually come from

Here is the part that reframes the whole conversation. Most small business security incidents have nothing to do with application code. Almost nobody gets hit by a clever attacker studying their software for flaws. They get hit by the boring stuff.

• Stolen and reused passwords. Someone used the same password on your system that they used on a site that got breached three years ago, and attackers simply logged in.
• Phishing. An email that looked like it came from you asked an employee for their login, and they gave it.
• Accounts that were never turned off. A former employee, a contractor from two years ago, a shared login that four people know. Offboarding is where small companies leak.
• Software nobody updated. A known vulnerability with a published fix, running unpatched for eighteen months because updates were not anyone's job.
• Sensitive data scattered where it was never supposed to be — customer lists in email attachments, payroll in a spreadsheet on a laptop, client files in a personal cloud drive.

Look at that list and notice how much of it is about access and process rather than code. That is the useful insight here, and it cuts in a direction most people don’t expect: replacing scattered spreadsheets and email attachments with one application that has real user accounts and real permissions usually improves your security posture. Not because the software is clever, but because the data stops living in fifteen places nobody is tracking.

The shared-spreadsheet-on-a-network-drive setup that a lot of small companies run on has no access control worth the name. Everyone can see everything, there is no record of who changed what, and a single laptop left in a truck can put the whole customer list somewhere you can’t retrieve it from.

What should be in the build, not bolted on later

Some security work is structural. It is cheap when it is part of the original design and expensive when it has to be retrofitted into an application that already has users and data in it. These are the things to make sure are in scope from the start.

• Individual user accounts with real roles. Not one shared login for the office. Roles mean your dispatcher sees schedules and your bookkeeper sees invoices, and neither one needs to see everything.
• Multi-factor authentication, at least for administrators. This single control stops the overwhelming majority of stolen-password attacks, and it is trivial to include during the build.
• Encryption in transit and at rest. Standard practice, essentially free, and worth confirming out loud rather than assuming.
• An audit trail on the records that matter. Who changed this price, who deleted this job, when. Useful for security and, in practice, used far more often to settle ordinary internal disputes.
• Backups that have actually been restored from. An untested backup is a hope, not a plan — and restoring is the step nobody rehearses until the day it counts.
• A dependency update process. Every application is built on third-party libraries, vulnerabilities get announced in them regularly, and somebody needs to own applying the patches.

That last one deserves emphasis, because it is the most commonly skipped and it is where custom software really can drift into being less secure than a maintained product. Software is not a building. It does not sit still. The libraries underneath your application get security patches, and an application that is never updated becomes more vulnerable every year it runs untouched — not because anything changed in it, but because the published list of ways into it keeps growing.

This is the difference between a project that ended and a system that is maintained. If nobody is responsible for updates after launch, you have bought a slowly expiring asset. Ask who owns that work and what it looks like month to month.

Questions worth asking any developer

You do not need to evaluate the answers on technical merit. You need to notice whether they are specific. A developer who has built and maintained real systems will answer these quickly and concretely. One who hasn’t will speak in reassurances.

• Where will my data physically live, and who besides me can access it? You are listening for a named hosting provider and a short, specific list of people.
• Is data encrypted in transit and at rest? The answer should be an immediate yes.
• How do user accounts and permissions work? There should be roles, and there should be a way to remove someone's access in under a minute.
• Can we require multi-factor authentication? If the answer is that it could be added later, ask what later costs.
• How do backups work, how far back do they go, and have you ever restored from one? The third part of that question is the one that matters.
• When a vulnerability is announced in something my application depends on, what happens? You want a process, not an intention.
• If I find a problem after launch, what is the response? Ask about timeframes, in writing.
• What happens to my data if we stop working together? You should be able to export everything, in a usable format, without a negotiation.

One flag worth naming: a developer who tells you the system is unhackable, or that security is fully handled and there is nothing to discuss, is telling you they haven’t thought about it hard. People who work on this seriously talk in terms of layers, tradeoffs, and what happens when something fails — because that is the actual shape of the problem.

If you handle regulated data, say so early

Some businesses carry obligations beyond ordinary good practice. A medical or dental practice handling patient records has HIPAA requirements. Anyone touching card numbers has PCI obligations — which is usually best solved by never touching card numbers at all and letting a payment processor handle them. Law firms, accounting firms, and anyone holding client financial records have professional confidentiality duties that carry real consequences.

None of this makes a custom build impossible or exotic. It does change the design, the hosting arrangements, and sometimes the paperwork — and it is far cheaper to account for at scoping than to discover halfway through. If your industry has rules, put them on the table in the first conversation, even if you are not certain they apply.

The honest summary

Custom software built by someone who takes security seriously is at least as safe as the commercial platform you are considering, and often safer, because it holds less of your data and is not a target anyone is hunting. Custom software built by someone who never raised the subject is a real risk — not usually on day one, but three years in, when nothing has been updated and nobody remembers who has access.

The variable is not custom versus off-the-shelf. It is whether anyone is responsible for this after launch. That is a question you can ask in plain English, and the answer will tell you most of what you need to know.

How Kairos approaches it

Accounts, roles, and permissions are part of every build rather than an upgrade. Data is encrypted, hosting runs in your company’s own accounts, and backups are configured and tested before launch instead of after. Dependency updates are part of ongoing care, because an application nobody maintains is one that gets less safe every year on its own.

After 20 years of building custom software, Brad Walker has seen far more damage from neglected systems and stale accounts than from anything an attacker did cleverly. The unglamorous work is the work that matters.

Frequently asked questions

If you are weighing a build and want the security questions answered before anything gets designed, start with a conversation. We will tell you plainly where your data will live and who can reach it.