Custom tools
The small things that remove manual work.
Most of the manual work inside a small business is copying information from one system into another, or producing the same document by hand every week. Neither needs a new subscription. Both can usually be removed with a small, boring piece of software.
When is a custom tool cheaper than another subscription?
When the requirement is narrow and specific to how your business works, when the alternative is a platform whose pricing scales with users or records you do not need, or when the job is simply connecting two systems you already pay for.
A subscription is usually better when the requirement is common, when the vendor handles compliance, security and updates you would otherwise own, or when the tool needs to keep pace with an external platform that changes frequently.
The honest cost of a custom tool is not the build. It is that you now own something that has to be maintained, and that has to be worth it over several years rather than over one.
What these actually are
Not software products. Small connections and utilities that remove a specific repeated task: moving data between two systems, generating a document, checking something on a schedule, or putting a form in front of somebody in the right shape.
The pattern is almost always the same. Somebody in the business spends two hours a week doing something mechanical, because the two systems involved do not talk to each other and nobody has ever had the time to look at it properly.
The correct response is rarely a new platform. Adding a subscription to solve a data transfer problem usually adds a third system that also does not talk to the other two.
What actually helps is a narrow connection built once, documented, and left alone. The measure of success is that nobody thinks about it again.
How we approach a build
The discipline is scoping down rather than up. Most failed internal tools failed because they tried to do four things.
Watch the task being done
Not a description of it, the actual task. Descriptions leave out the exceptions, and the exceptions are what make an automation break in week three. Sitting with the person doing it for twenty minutes is worth more than a specification document.
Work out what it costs today
Hours a week, multiplied out over a year, plus the cost of the errors it causes. If that number is small, we will say so and recommend leaving it alone. Not every annoyance is worth removing.
Check whether something already does it
A setting in a system you already pay for, a native integration, or an inexpensive connector. Building something that already exists is the most common waste in this category and we would rather find it than bill for it.
See the remaining steps: How we approach a buildHide the remaining steps: How we approach a build
Build the smallest version that works
One job, done reliably, with clear failure behaviour. A tool that handles the ordinary case and tells somebody when it cannot is far better than one that attempts to handle everything and fails silently.
- One job, not a platform
- Visible, loud failure rather than silent partial success
- Documented well enough for another developer to take it over
Put it on accounts you own
Hosting, credentials, repositories and any third party accounts in your name. If the relationship ends, nothing switches off and nothing has to be rebuilt.
Agree who maintains it
This is the part that gets skipped and the reason internal tools decay. Platforms change their interfaces, credentials expire, and something that ran perfectly for a year stops on a Tuesday. Either we maintain it or somebody does, and that should be decided at the start.
If a build cannot be justified against the cost of the manual work over a couple of years, we will tell you to keep doing it manually.
What is usually worth building
These come up repeatedly across local businesses and professional practices.
- Moving enquiries from a website form or a booking system into the software your team actually works in, without rekeying.
- Pushing outcome data from your CRM back into the advertising platforms, so campaigns optimise toward customers rather than form fills.
- Generating a recurring document or report that somebody currently assembles by hand every week or month.
- Watching something on a schedule and alerting a person when it changes: a listing, a competitor's pricing page, a licence renewal date, a stock level.
- Turning a spreadsheet that several people edit into a small form and a single record, which removes the version conflicts rather than managing them.
See the full checklist: What is usually worth buildingHide the full checklist: What is usually worth building
- Connecting a phone system to a CRM so calls appear against the right contact automatically.
- A small internal lookup tool that answers a question your team currently asks somebody else forty times a week.
- Bulk operations against a platform your team currently does one at a time through an interface.
Note how ordinary all of these are. The value is in removing repetition rather than in the sophistication of the solution.
Build, buy, or leave it alone
The third option is genuinely on the table and is the right answer more often than either vendor or developer will tell you.
| Item | Choose it when | It goes wrong when |
|---|---|---|
| Buy a product | The need is common and the vendor owns compliance and updates | Pricing scales on something you do not need |
| Use a connector | Two systems with existing integrations, simple logic | The logic grows and the connector becomes unreadable |
| Build custom | Narrow, specific, and it will still matter in three years | Nobody owns maintenance |
| Leave it alone | The manual work is genuinely small | It quietly grows and nobody revisits the decision |
The most expensive mistake in this category is building something bespoke to solve a problem that a setting in existing software would have solved.
Where AI fits, and where it does not
A great deal of what gets sold as an AI tool is ordinary automation with a language model somewhere in the middle. Sometimes that is exactly right and sometimes it adds cost and unpredictability to something that was deterministic.
Where a model genuinely helps: turning unstructured input into structured data, such as reading an email enquiry and extracting the details. Summarising something long. Drafting a first version of a document a person then edits. Classifying incoming messages so they route correctly.
Read the full breakdown: Where AI fits, and where it does notHide the full breakdown: Where AI fits, and where it does not
Where it does not: anything with an exact correct answer. Arithmetic, date handling, moving a record from one field to another, or deciding whether a value meets a threshold. Using a language model for those introduces failure modes into work that was previously reliable, and it costs more per operation.
The practical rule we apply is that if the task has one correct answer that can be computed, it should be computed. Models belong where the input is messy and the output is reviewed.
And everything a model touches needs a defined behaviour when it is wrong, which usually means a person sees the output before it has an effect.
The risks worth understanding before starting
Maintenance is the real cost and it is the one that never appears in a quote. Platforms change their interfaces, authentication tokens expire, and a tool that ran perfectly for eighteen months stops working the week you are busiest. Somebody has to own that.
Key person dependency is the second. A tool only one person understands is a liability disguised as an asset. Documentation and code somebody else could pick up is not optional, and it is the first thing to be dropped when a build runs late.
Read the full breakdown: The risks worth understanding before startingHide the full breakdown: The risks worth understanding before starting
Data access is the third. A connection between two systems usually holds credentials to both. Those should be scoped to the minimum needed, held in your accounts, and documented so you know what has access to what. In healthcare, anything touching patient information carries requirements that rule out several convenient shortcuts.
Scope growth is the fourth and the most common. A tool built to do one thing accumulates requests, and at some point it is a poorly maintained internal platform. The discipline is refusing the fourth feature and building a second small tool instead.
We do not publish a price for this piece of work on its own, because the right scope depends on what already exists. What is published is the bundle pricing: 2,400, 3,600 or 4,800 dollars a month depending on which channels are running. You can read the full breakdown on the pricing page, and you will get an exact number in writing before anything starts.
How to tell it was worth it
Time no longer spent, measured against the estimate made before the build. If nobody can say how long the task used to take, the benefit cannot be demonstrated, which is why that number is captured first.
Errors removed, which in some cases is worth more than the time. A rekeying process that introduces a mistake in one record in fifty has a cost that is not measured in hours.
Whether people actually stopped doing the manual version. Tools sometimes get built and quietly bypassed, which is a signal that the real process was different from the described one.
And the maintenance burden after twelve months. A tool that needed attention three times in a year has still probably paid for itself. One that needs attention monthly has not, and should be replaced by a product or removed.
How this connects to the rest
Custom work usually emerges from a marketing engagement rather than preceding one, because you have to see the repeated manual work before you know what is worth building.
The most common build by far is connecting CRM implementation to the advertising platforms, so outcome data flows back and campaigns optimise toward customers rather than form fills.
The second most common is making marketing automation possible across systems that do not natively talk to each other.
And it sits alongside AI chat and intake under the same principle: build the narrow thing that removes a specific failure, put it on accounts you own, and be able to switch it off without anything else breaking.
Bring the task, not the technology.
The useful version of this conversation starts with something somebody does every week that they should not have to. We will tell you whether to build it, buy it, or leave it alone.
Straight answers.
Do we own what you build?
Yes. Code, credentials, hosting and any third party accounts are in your name, and the work is documented well enough for another developer to take it over.
If we stop working together, nothing switches off.
How much does a small tool cost?
It depends entirely on scope, and we will not publish a figure that would be wrong for most requests. What we will do is scope it against what the manual work costs you today, so the decision is a comparison rather than a leap.
If the build cannot be justified against a couple of years of the manual alternative, we will say so.
What happens when it breaks?
Somebody has to own that, and it should be agreed before the build rather than after the first failure. Platforms change interfaces and credentials expire, so this is a question of when rather than if.
We build failures to be loud rather than silent, so the first sign is an alert rather than a month of missing data.
Should we use AI in it?
Only where the input is messy and the output is reviewed. For anything with an exact correct answer, deterministic code is cheaper, faster and more reliable.
Using a language model to move a value from one field to another introduces failure modes into work that was previously certain.
Is it safer to just buy software?
Frequently, yes, and we will say so when it is. A vendor owning security, compliance and updates is genuine value, particularly in regulated sectors.
Custom work wins when the requirement is narrow and specific to how you work, or when the alternative prices on something you do not need.
Where this comes from.
Primary documentation and published research behind the guidance on this page.
- NIST AI Risk Management Framework (opens in a new tab)
- Artificial intelligence, Federal Trade Commission (opens in a new tab)
- HHS guidance on HIPAA and online tracking technologies (opens in a new tab)
- OWASP Top Ten web application security risks (opens in a new tab)
- Data security guidance for business, FTC (opens in a new tab)
Talk to the team
A short call, a look at how the business currently shows up, and a straight answer on what we would do first.