Ask an owner what their software costs and they will name the subscriptions. The scheduler, the CRM, the invoicing, the phone system, the thing marketing insisted on, the spreadsheet that is somehow load bearing. Add it up and it is a real number but rarely an alarming one.
The cost that does not appear on that list is the person who moves information between them. Somebody exports a list every Monday. Somebody retypes the booking into the second system. Somebody checks whether the thing that was supposed to sync actually synced. None of it is anybody's stated job, so none of it is on a line item, and it is almost always the largest software expense the business has.
That is the number worth putting against a build, and once it is on paper the arithmetic frequently surprises people.
The hidden line item is a salary
Try this honestly. Pick the three handoffs between your systems that require a human. Estimate the hours a week each one takes, including the time spent finding and fixing what went wrong. Multiply by what that person costs you, including the part of their attention that is not available for anything else while they are doing it.
Most owners land somewhere between a few hours and most of a role. Then there is the part that is harder to price. The double entry that produced a wrong invoice. The lead that sat in an inbox because the form went somewhere nobody owned. The reporting nobody trusts, so decisions get made on feel.
You do not need a precise figure. You need to know whether you are looking at a small annoyance or a standing cost that will be there every year, growing with the business, forever.
Signs you have outgrown the stack
These are the ones we see most often, and any two of them together usually mean the current arrangement is near its limit:
- A spreadsheet has become the real system of record and everyone knows it
- Onboarding a new hire includes a verbal explanation of which tool to believe when two disagree
- You are paying for a platform to use one feature, because that feature has no standalone equivalent
- A process everyone follows exists nowhere except in one person's head
- You have stopped asking for a report because the last one took two days to assemble
- Somebody's calendar reminder is what keeps a critical step from being missed
That last one is worth dwelling on. A business running on somebody's personal diligence is fine until they are on holiday, and the failure is always discovered by a customer rather than by you.
What custom means now, and what it still costs
It is fair to say that building software has got meaningfully faster. The tooling is better, the models help with the ordinary parts, and things that used to be a quarter are now considerably less. That is real and it has changed which projects are worth starting.
What has not changed is what happens afterwards. Software has to be hosted, watched, updated when the things it depends on change, and fixed when an integration on the other side alters something without telling you. Anyone quoting you a build without describing that part is quoting you half the job, and the second half never ends.
This is why we would rather talk about what it costs to run than what it costs to make. A cheap build with no plan behind it becomes an expensive liability in about eighteen months, usually at the worst possible moment, and usually when the only person who understood it is unreachable.
Where custom is the wrong answer
We turn down more of these than we take, and the reasons are consistent.
Do not rebuild accounting. Do not rebuild payroll. Do not rebuild anything where the rules are set by somebody other than you and change without warning, because you will be paying someone to chase those changes forever and you will still be behind. The established products in those categories are cheap relative to what they handle, and the boring choice is the right one.
Be equally careful about replacing a CRM. Most businesses who want to are not unhappy with the CRM. They are unhappy that nobody enters anything into it, and a new system with the same habits produces the same emptiness at greater expense. That is usually a process conversation rather than a software one, and it is cheaper.
The good candidates look different. They are usually narrow, specific to how your business works, and sitting in a gap no product covers because the gap only exists for people who do what you do.
Build the seam, not the system
When a build is warranted, the mistake is to scope it as a replacement for everything. That project is long, expensive, and has to be right on the first attempt, which nothing ever is.
The better shape is to find the single worst handoff and automate only that. Keep every existing tool. Build the bridge. It is a smaller piece of work, it pays back quickly enough to be obvious, and if it turns out to be the wrong bridge you have lost weeks rather than a year.
Almost every larger system we run for clients started as one of these and grew because the next piece was clearly worth it. That order is not a compromise. It is the only way to find out what you actually needed, because the first version teaches you things no amount of planning would have.
Where AI genuinely belongs in this
There is enthusiasm to put a model into everything at the moment, and some of it is well placed. The parts that work reliably are the ones where a model does something people are bad at and the output gets checked: reading unstructured text and pulling the useful parts out, summarising a long history into something a person can act on, sorting incoming work by what it is about, drafting something a human then approves.
The parts that go wrong are the ones where a model is trusted to decide something consequential without review, or where it produces a number that then gets treated as fact. A model is confident whether or not it is correct, and building on that without a checkpoint is how a small error becomes a policy.
In practice the most valuable thing we build with AI is rarely the impressive part. It is usually the piece that reads what comes in, works out what it is, and puts it where it belongs, which is the same problem as an agent handling your front desk wearing different clothes.
How we scope it
We start by watching the work happen rather than asking what the system should do. What people say they need and what they actually do differ more than anyone expects, and the gap is where the useful build is hiding.
Then we agree the smallest thing that removes real work, what it costs to build, and what it costs to keep running. If we think you would be better served by configuring something you already own, we say so. That conversation has ended without a project more than once and we would rather that than the alternative.
We do this for businesses and medical practices across South Florida and keep the work in-house, which means the person who builds it is the person who maintains it. If you want to talk through whether something is worth building, we will give you a straight answer, including when the answer is no.