Custom Tools & Integrations
Most businesses reach a point where the software almost fits. Two systems that don't talk to each other, a spreadsheet doing a job it was never meant to do, a calculation someone redoes by hand every week. That gap is usually smaller and cheaper to close than people expect.
- The same information gets typed into two different systems by a person.
- A spreadsheet has quietly become critical infrastructure, and one person understands it.
- You were quoted enterprise software pricing for a problem that isn't enterprise-sized.
- Your systems each work fine and none of them talk to each other.
- You need a number your tools can't produce, so someone rebuilds it by hand every month.
What you get
- Integrations between systems that don't natively connect, so information moves without a person retyping it
- Internal tools and dashboards built around how your business actually works
- Customer-facing calculators, estimators, and interactive tools for your website
- Data cleanup and migration between platforms
- Documentation written for whoever maintains it next, including if that isn't us
- Code and accounts that belong to you, not to us
Where this service stops
- We recommend against building whenever something existing would do. The first honest answer to "can you build this" is often "you shouldn't."
- Anything custom needs an owner. We build it to be maintainable and document it accordingly, but software with nobody responsible for it becomes a liability.
- We scope to the smallest version that solves the problem, then extend it if it earns the extension.
- Third-party APIs change without asking you. We build defensively and tell you where a dependency could break.
Also covered under this service
- API integrations
- Internal dashboards
- Website calculators and estimators
- Spreadsheet replacement
- Data migration and cleanup
- Scheduled reports
- Webhook plumbing
- Booking and quoting tools
What a custom tool should be
Custom software has a bad reputation for good reasons—most of it is built to impress rather than to survive. These are the properties we hold it to:
Smaller than you were expecting
Scoped to the one thing that hurts, not to everything adjacent to it. Most useful internal tools are unglamorous and do a single job reliably.
Maintainable by someone else
Ordinary technology, conventional structure, written documentation. The test is whether a competent developer who has never met us could pick it up—because one day that's exactly what happens.
Yours, including the keys
Accounts, code, and data in your name. If you stop working with us, nothing stops working. Tools that hold your business hostage are a business model, not an architecture.
Honest when it breaks
Anything depending on an outside system will eventually fail. It should tell you clearly rather than fail quietly and leave you trusting a number that stopped updating in March.
Justified by hours
A build should replace measurable work. If we cannot point to the time it saves or the errors it prevents, that is a reason not to build it.
Wondering if Custom Tools & Integrations is the right first step?
Describe your situation and we'll say whether this service would help, and what we would do first. If it isn't worth the spend yet, we'll tell you that.
Is this the right starting point?
This service fits if
- Your process is genuinely specific, and bending it to fit generic software costs more than closing the gap.
- You want to own the thing that gets built, including the ability to have someone else maintain it.
- You have a repetitive task with clear rules and real hours attached to it.
Probably skip it if
- An existing product would do the job. We'll tell you which one and how to configure it, and that's a shorter conversation than a build.
- You want a large, long-lived software platform. That needs a team and a maintenance budget, and we'll say so rather than start something we shouldn't finish.
What to expect
-
Find out whether to build at all
We look at the actual process first, and at what already exists that might do the job. A meaningful share of these conversations end with a configuration change instead of a project.
-
Build the smallest useful version
The narrowest thing that solves the problem, put in front of the people who will use it early enough that their reaction still changes the design.
-
Document and hand over the keys
Written documentation, accounts in your name, and a walkthrough with whoever will own it. Extensions happen afterward, if use justifies them.
Timeline
A focused integration is usually days to a couple of weeks. Internal tools and dashboards typically run a few weeks depending on how many systems are involved. The scoping conversation happens first and is short—often it ends the project early, which is a good outcome.
What we need from you
Access to the systems involved, and time from whoever actually does the work today. That person knows the exceptions, and the exceptions are what determine whether the build works.
How pricing works
Fixed-price by project, quoted after scoping. We quote the smallest version that solves the problem and price extensions separately, so nobody is committed to a large build before the small one has proven itself.
Ask what this would costThe questions buyers ask first
Straight answers to the two most common ones. If yours isn't covered below, ask—we answer either way.
Ask your questionIs custom software worth it for a business my size?
Sometimes, and the test is arithmetic rather than ambition. If a task takes someone four hours a week and follows rules that can be written down, the numbers usually work. If it's occasional, or the rules change constantly, they usually don't. We run that calculation with you before quoting, and it's the reason we talk people out of builds fairly often.
What happens if we stop working together?
Everything keeps running. The code, the accounts, and the data are in your name from the start, and the documentation is written for someone who has never spoken to us. That's deliberate: a tool that only its builder can maintain is a dependency you didn't agree to buy.
More questions
-
Automation wires existing tools together—Zapier, n8n, your CRM—so information moves without you. This is for when no combination of existing tools does the job and something has to be written. Automation is cheaper and faster when it fits, so we look there first and say so when it's the better answer.
-
Whoever you want, and that's the point of building it conventionally. We can maintain it, your developer can, or a future hire can. What we won't do is build something that structurally requires us.
-
It happens, and it's the main long-term risk with any integration. We build defensively, note which dependencies are most likely to shift, and make failures visible rather than silent—a broken integration that announces itself is a small problem, and one that quietly stops syncing is a large one.