Custom Software Development
Eleven tools that do not talk to each other.
Custom software is worth building when the work that matters happens in the gaps between the things you already pay for.
Book Strategy Call
- Starts with
- Whether to build at all
- Replaces
- The spreadsheet holding it together
- You own
- The code and the accounts
Software, or an app?
People use the words interchangeably and they are not the same job. One fixes how the business runs. The other is a product someone uses.
You want custom software
- The work happens between the tools you already pay for
- A spreadsheet has quietly become the system of record
- Two systems disagree and a person reconciles them by hand
- Reporting means exporting from three places
That is this page. Keep reading.
You want an app
- Customers or vendors need somewhere to log in
- You are launching a product rather than fixing operations
- It has to work on a phone, properly
- The thing you are building is what you sell
Plenty of engagements are both, and the answer is usually obvious once somebody has actually looked at how the work moves through your business. That looking is the first thing I do.
The number that decides it is not the licence fee.
Off-the-shelf looks cheaper because the invoice is visible. The cost that is not on any invoice is the hours your team spends moving data between tools, reconciling two systems that disagree, and rebuilding the same report every month.
Count those hours honestly for one month. If the answer is small, configure what you already own properly and keep your money. If it is most of somebody's job, you have found your business case.
What this usually turns out to be.
- Internal tools that replace the spreadsheet everyone actually trusts
- Integrations so two systems stop disagreeing
- Portals for customers, vendors or staff
- Reporting that pulls from one place instead of three
- Workflow and approval systems with a real audit trail
- Replacing software nobody supports any more
What people ask before they commit.
Building software around how a specific business actually works, rather than adapting the business to fit a product built for everyone. In practice it usually means internal systems, integrations between tools that do not talk, portals, and reporting. The distinction that matters is ownership: the code and the accounts are yours, so no vendor can change the terms underneath you.
What you walk away with
One instrument. You own it.
Nothing held hostage, nothing locked to a platform you cannot leave.
The codebase
Yours, in your repository
The infrastructure
Your accounts, your billing
The accounts
Registrar, analytics, ads
The documentation
Written for the next person