Custom business software, designed with the people who use it.

Standard software (ERP, CRM, quoting software) is designed for thousands of companies: it imposes its logic, and everyone adapts. Custom business software does the opposite: it follows your logic, your steps, your exceptions.

Most often, it’s a web app: it opens in the browser, on a computer or a phone, with nothing to install. It can take several forms:

• an internal tool for one team (production tracking in manufacturing, field service management);
• a dashboard that brings together numbers from several systems;
• a portal open to your customers or suppliers.

It doesn’t replace your core software: it connects to it and handles what that software does poorly or not at all.

The need for custom business software rarely shows up all at once. It creeps in little by little, until one day it’s all you can see. If you check three or more of these boxes, the question is worth asking:

• a shared Excel spreadsheet does the job of software, and only one person knows how to fix it;
• the same data is retyped into two or three tools;
• your current software forces workarounds on you (repurposed fields, notes in comments, side files);
• to find out where a job stands, you have to ask someone;
• you pay for licenses covering features you barely use;
• the way you work is what sets you apart from your competitors, and no software reproduces it.

Conversely, if off-the-shelf software already covers the essentials with reasonable setup, keep it: I’ll tell you so during the audit.

The three aren’t mutually exclusive. An ERP runs the core of the business (sales, purchasing, inventory, accounting) with rules common to everyone. Off-the-shelf software (SaaS) covers a common need well, at a low entry cost. A custom application handles what’s specific to you.

So the right question isn’t “which one?” but “for which part?” A simple rule:

• what’s standard everywhere (accounting, payroll) stays in off-the-shelf software;
• what’s specific to your business and costs you time every day deserves a tool designed for you;
• in between, an API integration keeps the data flowing.

Custom software for a small business is entirely realistic, as long as you start with a narrow scope, the one that saves the most, and expand from there.

The price of a business application doesn’t depend on lines of code, but on a few factors you can pin down from the start:

• the number of screens and user flows: a five-screen tracking tool is nothing like a full customer portal;
• business rules: calculations, exceptions, permissions by role;
• the software to connect: an ERP with a modern API, or an old system linked through files;
• migrating your existing data, often underestimated;
• special setups: phones on the shop floor, offline mode, signatures.

To keep the budget under control, I split the project into phases: a first useful version (MVP), live quickly, then the next phases, each with its own fixed price and deadline in writing. You decide what comes next based on what’s already running.

Many companies already have a homegrown tool: built ten years ago by a vendor who’s gone or an employee who left. It runs, but nobody dares change it anymore. Rebuilding the business application becomes urgent when three signals add up: every change costs more than the last, the technology is no longer maintained (a security hole won’t get patched), and the team works around the tool with spreadsheets.

A successful rebuild doesn’t copy the old one screen by screen. It follows an order:

• map what’s really used: the screens people use every day, the business rules hidden in the code;
• redesign the experience with the people who use it, on a clickable mockup: that’s the UX redesign, often the best investment;
• migrate the data without loss, then run the old and new tools side by side long enough to check;
• switch over in phases, module by module, not in a single weekend.

Fixing a user flow on a mockup takes an hour. Fixing it after development takes days.

A business application is alive: your rules change, your software evolves, new needs come up. Three choices, made at the start, decide how long it lasts.

• Mainstream technologies, well documented, that other developers can pick up. No exotic stack, no low-code platform that locks you in.
• Code and accounts in your name: hosting, domain name, code repository. You’re not tied to anyone, including me.
• Documentation that explains how it works, the business rules, and the connections.

Getting these right keeps technical debt in check: the shortcuts that make every change more expensive than the last. After that, ongoing support is optional: monthly support if you want to keep improving the tool, or one-off phases when a need comes up. If AI belongs somewhere (reading a document, drafting a reply), it’s added to the existing application, like any business process automation.