// Custom Software · Web Apps · Integrations

Custom Software That Runs Your Operations

We build operational web apps, integrations between tools that will not talk, and internal dashboards for service businesses. When off-the-shelf software forces manual workarounds that cost hours every week, the workaround has become the job. We build the system that replaces it.

Book a Free Scoping Call

See a System We Built

Delivery system · example screen

Work	Stops	Status
Recurring · route	12	Delivered
One-off · job	9	En route
Driver view · next stop	14	Scheduled
Invoice · outstanding	·	Queued

Example screen with sample data, layout only. We show what a system does, never a client’s real numbers.

// In short

What Is Custom Software for a Service Business?

Custom software for a service business is a system built around how your business already runs, instead of a product you bend to fit. It usually means jobs, scheduling, routing, invoicing and one dashboard, plus the integrations that stop anyone retyping the same job twice.

The honest part first: most businesses should not build software. Custom software development is worth paying for in a narrow set of cases, and this page is mostly about how to tell whether yours is one of them. Working out which side of that line you are on is what the free scoping call is for, and four questions further down will get you most of the way there on your own.

Remote across the United States, no office visit to arrange · Written and maintained by the GrowthRefactor engineering team · Last reviewed July 31, 2026

When the Workaround Has Become the Job

The tools you bought were supposed to save time. Now the day is spent working around them: the same spreadsheet reopened all morning, the same numbers retyped between systems, the same question nobody can answer without asking three people. That friction is the signal, long before anyone decides to build anything.

The spreadsheet that runs the business

One fragile file that everything depends on, that only one person really understands, and that breaks the moment two people open it at once.

The copy-paste between tools

Two systems that both hold half the truth and never speak, so a person becomes the integration, retyping the same job into three places.

The question with no answer

How many are outstanding? Where is that order? Nobody can say without a phone call and a hunt, because the information lives in five heads and four apps.

// Build vs buy

When Should a Service Business Build Custom Software?

When the tools you bought force you to work around them, and the workaround costs hours every week. The signal is friction, not ambition. Most businesses should not build, and we will tell you so, because a project that should not exist is bad for both of us.

Below is what actually rides on the build vs buy question, in the four places we see it decided wrongly. The test itself is four questions further down, and you can run it without us. If the answer is buy, spend the money on automating the follow-up instead, which is cheaper and usually pays back sooner.

01.

Buying when the process is genuinely yours

You pay twice: once for the subscription, and again in the workaround the product forces because it cannot model your routing rule or your pricing method. That second cost never appears on an invoice, which is why it survives for years.

02.

Leaving the glue role in place

The person moving information between systems becomes the only one who knows how the business really runs. That is a wage cost while they are there and a genuine risk the week they are not, and it grows quietly as you do.

03.

Building what an integration would have fixed

An integration moves data between two tools that each stay responsible for their own job. It cannot give you a screen that does not exist, or a rule neither tool understands. Knowing which of those you need is the difference between a small piece of work and a system, and it is the first thing we check.

04.

Building around a process still in motion

Every rule that changes after it is built has to be found, changed, tested and re-released. That is ordinary software maintenance and it is priced accordingly, which is why a system built around a process still in motion quietly becomes the most expensive thing on this page.

// What we build

Three Kinds of Custom Software We Build

Three shapes, in rough order of how often they are the right answer. The smallest one is at the end and is the one we suggest most.

01.

Operational web apps

The system your business actually runs on: orders, customers, scheduling, routing, invoicing, and a dashboard that answers the question you ask every morning.

Accounts and roles, so the office sees the money and the crew sees the run sheet
An audit trail: a record of who changed what and when, which is what you want the first time two people disagree
Built to work on the phone in a van, not just on the desk it was demonstrated on
Your database, your hosting, and a backup you can actually restore from

02.

Integrations

Two tools that both hold half the truth and never speak. We write the connection so a change in one lands in the other, and nobody is the human copy-paste layer any more.

Accounting, payments, scheduling, and the CRM, wired through their published APIs, the documented way one tool lets another read and write its data
Webhooks, where the tool tells us the moment something changes, and a scheduled check where it will not
Retries and an alert when a sync fails, because a silent integration is worse than none
Often the cheapest fix on this page, and the first thing we check for

03.

Internal tools and dashboards

The small thing that gives a person their afternoon back. Rarely glamorous, usually the highest return for the money, and almost always the first thing we suggest.

One screen that answers the question you currently ask three people
The report that gets rebuilt by hand every month, built once
Reads from the tools you already have, so nothing has to be replaced to start

Not sure which of the three you need? Book a free scoping call and we will tell you, including when the answer is none of them.

// What you own

What You Own and Operate Afterwards

Not features. What your own team ends up holding once the build is finished and we have gone, which is the part worth checking before you commit to anyone.

The accounts, in your control

Someone on your side administers the roles: who joins, who leaves, who can see the money. No support ticket to add a driver, and nobody outside your business holding the keys to your staff list.

Your data, exportable on demand

The customers, the schedule and the money live in one place, in your database, and you can take the whole lot out whenever you want. That is the test we tell you to run on your current tools before you trust any of them.

The code, and the freedom to leave

The code sits in your repository, the versioned store holding the code and every change ever made to it, in your name, with the documentation beside it. No per-seat rent forever, no vendor lock-in, and no permission needed to change it or hire someone else to.

The integrations, which need watching

The honest one. The automation that catches the lead and the system that runs the job stay in sync through the API, and if a vendor changes their end, somebody has to notice. That is either us on a support arrangement or your own person, but it is not nobody.

// Flagship build

A Water Delivery Management System

A water delivery operation was running on messages, paper, and a spreadsheet. We built one system to hold the whole thing: customer accounts and recurring schedules, order intake, route and stop sequencing, a driver view for marking deliveries, invoicing and outstanding balances, and a reporting dashboard.

It went through the same test as everything else on this page. Off-the-shelf delivery and route management apps were looked at first, and they did not match how the recurring accounts or the stop sequencing actually worked. Standing orders ran on a fixed cycle rather than as bookings, and the run order was one the drivers reorder by street. That is the fit problem in the first of the four ways this gets decided wrongly, met head on, and it is the only reason a build was the right call here.

This is the build we point at when someone asks whether we can actually write software rather than configure it. It is real and it is in use. We are not publishing screenshots or numbers from it, because those are the client’s and we have no measured before-and-after we could stand behind.

Three calls we made on it, and why. This is the part a feature list never shows you, and the part worth asking any developer about before you hire them.

The driver view came first, not the dashboard

The owner asked for reporting. But the data the reports needed did not exist until drivers were marking stops, so the phone screen shipped first and the dashboard came after it had something real to read.

Recurring schedules, not a calendar

Most of the round is the same customers on the same cycle. Modeling that as a repeating schedule, rather than a separate booking per delivery per customer, kept the daily run sheet to one generated list instead of something anyone had to maintain.

Route optimization stayed out of the first version

It was the most requested feature and the least useful one. The drivers already knew the best order for the streets they drive daily. Sequencing they could reorder by hand beat an algorithm that would have cost far more to build than the problem was worth.

Talk to us about a build

What it replaced

Orders arriving in messaging apps
Routes planned from memory
Deliveries confirmed by phone call
Invoices written by hand each month
Balances nobody could see in one place

The hard part

Not the code. Getting the existing customer list, balances and standing orders out of a spreadsheet that had been edited by several people for years, and into a shape a database would accept, without losing a customer or inventing a balance. That is the part every migration underestimates, and the part we now quote for separately.

// Compare

Build vs Buy: Custom Software Compared With Off-the-Shelf

Off-the-shelf here means the category built for your trade: a field service, job management, or route planning platform. Three of these seven rows go against us, and they are the ones most buyers weigh first, because those platforms are cheaper to start, usable immediately, and maintained by somebody else. The four that go the other way only matter once the fit problem is costing you more than the build would.

How an off-the-shelf product and a custom build differ on the seven things that decide it
Decision factor	Off-the-shelf	Custom build
Fits your process	You bend to fit the tool	Built around it
Upfront cost	Low or free to start	Higher
Cost over five years	Per seat, per month, forever	One build, then whatever you choose to fund
Who owns the data	The vendor holds it	You do
Changing something	Submit a feature request, wait	A scheduled piece of work
Time to first use	Available immediately	Longer, it is being built for you
Maintenance	Included in the subscription	Yours to fund

The maintenance row is the one people skip, and it is the one that decides whether a build was a good idea three years later. The FAQ below sets out what maintaining a custom system actually involves, including the parts you can do without us.

Landed on the custom side? Book a free scoping call. Landed on the other side, and we will say so on the call rather than quote you anyway.

// Do it yourself

Four Questions You Can Answer Without Us

You do not need a consultant to work out whether you have a build-shaped problem. These are the four questions we ask on a first call, in the order we ask them. Answer them over a coffee and you will know before you speak to anyone.

Who is the glue, and what do they do all day?

Find the person whose job is mostly moving information between systems. Sit with them for an hour and write down every place they retype something. That list is your specification, and it is worth more than any proposal.

If nobody in the business fits that description, you probably do not need a build.

Do your tools already have an API?

Look each tool you pay for up in the Zapier app directory, or search its name plus the word “integrations”. If two of them already appear, the fix may be a connection rather than a system.

This is the question that most often turns a build into something far smaller.

Can you export your own data today?

Log into the tool that holds your customers and try to export the whole list. If you cannot, or it costs extra, you have found a real risk that has nothing to do with whether you build anything.

Do this whatever you decide. It is the cheapest insurance in this list.

Has the process stopped changing?

Ask whether how you quote, schedule and invoice is the same as it was six months ago. If it keeps moving, wait. Building around a moving process means paying twice, and we would rather tell you that now.

This is the one that ends the most conversations, including ones we would have been paid for.

If the answers point at buying rather than building, that is a good outcome and you have saved yourself a project. Our longer writeup of the first question is When to replace your spreadsheet with custom software. If they point the other way, that is the conversation.

// How it runs

From Scope to Shipped

The scoping call is free. Discovery after it is paid, and you leave it with a written specification you own outright, whether or not you build it with us. Take it to another developer if you want. That is the point of writing it down.

Free scoping call, then discovery you keep

We map how the work really happens, not how the org chart says it does. You leave with a written spec you own, even if you never build it with us.

Fixed quote

Scope, price, and dates in writing, off the back of the spec. No hourly meter running while we work out what you meant.

Build in milestones

You see working software at each milestone, not a status update. Something you can click beats a percentage on a slide. Changes you ask for mid-build get quoted before they start, not billed after.

Ship and support

It goes live, your team gets shown how it works, and you own the code. Ongoing support is optional and priced separately, and leaving it does not switch anything off.

What this does not include

A fixed price before discovery. The scoping call is free and will tell you the shape, but the number follows the written spec, not the other way round.
Data migration inside the build price. It is quoted separately because it is the genuinely unpredictable part, and burying it would just make the first number look better.
Taking over an undocumented codebase sight unseen. We will look at it and tell you honestly whether it is worth continuing or restarting, but that assessment is its own piece of work.
Ongoing feature work after launch unless you want a support arrangement. Ending one does not switch anything off, because the system runs on your hosting.
A guarantee about what the system will do to your revenue. We will describe what it removes from your week. Anyone putting a number on the rest has not seen your books.
A native app in the App Store or on Google Play. These are web applications, built to work properly in the browser on a phone in a van. A native app is a separate decision and worth its own conversation.

// What it costs

What Does Custom Software Cost?

There is no price list on this site, on purpose: a number quoted before anyone has looked at your process is a number that will change. What we can tell you is exactly what moves it, so you can see which parts of your own project are expensive before you ask anyone for a quote.

How many roles use it

One office screen is a small project. Office plus drivers plus a customer login is three interfaces and three sets of permissions. Cutting a role from version one is the single biggest lever you control.

What it has to talk to

A tool with a documented API is straightforward. A tool with no API, or one that only exports a file overnight, is where the hours go. Check this before you scope anything.

The state of the data you are moving

Data migration is quoted separately because it is genuinely unpredictable. A clean export is quick. Years of a shared spreadsheet with duplicates and free-text notes is the part that surprised us on the water delivery build.

How settled the rules are

“It depends who the customer is” is the most expensive sentence in a discovery session. Every exception is a branch somebody has to build and test. Write your exceptions down before the call.

What it costs to keep running

Not zero, and this is the column that belongs against the per-seat subscription. Hosting and a domain, whatever the integrations call that meters its own usage, and an optional support arrangement. It does not scale with headcount, which is the actual difference, but anyone telling you a build has no run rate is selling.

Against that sits the number nobody puts in a proposal: what the current workaround already costs you in wages every week, and what your existing subscriptions cost per seat over five years. Both are figures you already have. Work them out before you talk to anyone, including us.

Start with the free scoping call, and the written scope comes out of discovery after it

// Why us

Why Us for a Build

Three things worth checking in any custom software development company, ours included. Ask each of them of whoever you are talking to, and the answers will separate the shops that write software from the shops that resell it.

We write code, not just configure it

Plenty of shops assemble templates. When your process needs something the platform cannot do, we write the code that covers it instead of telling you it is impossible. The water delivery build is what that looks like.

We tell you when not to build

We talk people out of the projects that do not earn their cost, including ones we would have been paid for. The four questions are the test we use, and we hand them over rather than keeping them for the sales call.

Automation and software under one roof

Most agencies do the marketing half. Most software shops do the operational half. We build both and keep them in sync, which is where the real leverage lives. The same studio also handles your SEO and the site it all runs on.

// Who it’s for

Who Custom Software Is For

Not everyone. Custom software for service businesses earns its place when the fit problem is costing you more than the build would. These are the shapes where that tips over. We work remotely with clients across the United States.

Operations-heavy service businesses

Distributors, route delivery, printing and packaging, professional services. When the spreadsheet has run out and the tools do not talk, this is where a custom system pays for itself first.

Field and route businesses

Scheduling, stop sequencing, and a driver view for marking work done, like the water delivery system we built. Paper and messaging apps stop scaling long before you do.

Home services at scale

Once you are past a couple of crews, quoting, scheduling, and invoicing outgrow the off-the-shelf CRM. A tool built around your jobs removes the daily reconciliation.

Anyone the tools have failed

If a booked job means retyping it into three systems, or a simple integration would save a person a chunk of every week, that is usually a small build, not a platform.

If the bottleneck is finding customers rather than running the work, this is the wrong page. Start with SEO, social media management or Google Ads, and come back when the operations are what is holding you up.

// FAQ

Custom Software FAQ

Do I own the code?

Yes. The repository is yours from day one and you can see every change as it lands, and ownership of the finished work transfers in full on final payment. It lives in your repository and your hosting, with documentation written as we go. You are never renting access to your own business system, and you never need our permission to change it or hire someone else.

What does a custom build cost?

There is no price list here on purpose, because a number quoted before anyone has looked at your process is a number that will change. The scoping call is free, discovery is paid and leaves you a written specification you own, and the build is a fixed quote off the back of it. What drives the cost above sets out what actually moves the number, so you can shrink your own project before asking anyone to price it.

What happens to the data in my spreadsheet?

It gets migrated, and it is usually the least predictable part of the project, so we quote it separately rather than burying it. We take your export, work out the duplicates and the free-text notes that do not fit a field, and agree with you what happens to each of them before anything is loaded. Nothing is deleted at your end: the old spreadsheet stays exactly where it is until you are satisfied the new system holds the same truth.

Who maintains it after launch, and what if I stop paying you?

Support is optional and priced separately, and ending it does not switch anything off. The system keeps running on your hosting because it is yours. What a support arrangement buys is someone watching the integrations, applying security updates, and being available when something breaks.

One boundary worth stating plainly, because the word “support” is used to blur it: something that does not do what the written scope said it would is not support work. That is the build not being finished, and it gets fixed. New things you think of afterwards are quoted as new work. If you would rather hand ongoing care to your own IT person or another developer, the documentation and the repository are there for them, and we will talk them through it.

Can it talk to my other tools?

Yes, and that is where the interesting work lives. Your marketing automation catches and books the lead, the custom system runs the job afterwards, and the two stay in sync through the API. Where a tool publishes an API or webhooks we use them; where it does not, we work out what it can export and how often, and we tell you before you commit. Most agencies can do the first half. Most software shops can do the second. We do both.

How long does a build take?

A small integration is short work. An operational system is a bigger piece of work, and we ship it in milestones rather than disappearing until launch day, so you are using part of it long before the last part is finished. We are not going to put a number on a public page, because that would be a promise made before seeing your process. The scoping call is where you get a real answer for your case, in writing.

What if I only need a small fix?

Then ask for the small fix. Not everything needs a project. Quite often the thing costing a person a chunk of every week is a script or a single integration, and we would rather do that than talk you into a platform you do not need.

How much of our time does this take?

More than most agencies admit, and it is the input that most often decides whether a build lands well. Discovery needs sessions with whoever actually does the work, not whoever owns it on the org chart. Migration needs decisions from you on the edge cases before anything is loaded, because we will not guess what a note in a spreadsheet cell meant.

And each milestone needs somebody on your side to try it on a real job and say what is wrong. We are not going to quote you hours for that, but if nobody on your side has any time at all, the honest advice is to wait until they do.

How do you handle security and backups?

Access is scoped by role, so the crew sees the run sheet and not the accounts. Data goes over an encrypted connection, and the database is backed up on a schedule we agree with you, with a restore actually tested rather than assumed. The common web application risks are catalogued publicly in the OWASP Top Ten, and that is the list any build worth paying for should be checked against, ours included.

Our own access is worth asking about too, and most people forget to. The hosting and the database are in your name from day one. We work in them while we are building, your customer data stays inside your own hosting rather than being copied anywhere of ours, and when the build ends or a support arrangement stops, our access is removed. You should ask any developer that question before you hand over an export.

Who actually writes the code?

The person who takes your brief. There is no account manager relaying messages to a team you never meet, and the work is not passed to a subcontractor once the contract is signed. That is the honest advantage of a small studio, and it is also the reason we turn down projects that do not fit: we cannot staff our way around a bad match. You can read more about how the studio works.

How do I choose a custom software development company?

Run the four questions first, because the most valuable answer is often that you do not need one yet. If you do, every check that matters can be made before you sign anything. Who actually writes the code, and does it stay with them or go to a subcontractor. Whose name the repository and the hosting are in, and from what date. Whether the written specification out of discovery is yours to take to somebody else. What the stack is, and whether an ordinary developer could pick it up. What happens to their access when the work ends.

Two more that people forget. Ask what they would tell you not to build: a supplier who has never talked a client out of a project is a supplier who quotes every project. And ask for the maintenance answer in writing before you ask for the build price, because that is the row that decides whether the build was a good idea three years later.

What if my team will not use it?

Then it was built wrong, and that is a design problem rather than a training problem. It is why the driver view on the water delivery build shipped before the dashboard the owner asked for: the people doing the work had to be using it daily before anything else made sense.

It is also why we build for the phone in the van rather than the desk the software was demonstrated on, and why each milestone needs somebody on your side trying it on a real job and telling us what is wrong, while changing it is still cheap. A system the crew works around is the same problem you started with, wearing a different logo.

What if we want to stop part-way through?

You stop at a milestone boundary and you keep what exists at that point: the written specification from discovery, the code shipped so far, and the repository it has been sitting in since day one. There is no clause that claws any of it back. It is not the outcome either of us wants, but a build you cannot walk away from is a worse deal than the subscription you were trying to escape.

What happens if you disappear?

Fair question to ask any small shop. The answer is that you hold the code, the repository, and the hosting from day one, and we write the documentation as we go.

The shape is deliberately ordinary: a mainstream server language, a relational database, a standard JavaScript front end, and hosting you can buy from more than one supplier. Nothing exotic, nothing proprietary to us, and no framework so unusual that hiring a replacement becomes its own project. The exact stack is named in the written scope before you commit to anything, so you can have your own developer read it first. If we vanished tomorrow, another developer could take it on. That is the point of owning it.

// Related services

Wire It Together

Each service is stronger wired to the others. Here is where this one usually connects.

SEO

Get found in search and the AI answers sitting above it.

Website Design

Fast sites built to book jobs, not just look nice.

Google Ads

Clicks wired to a system that actually catches them.

Marketing Automation

Missed-call text-back and follow-up, so no lead slips.

Google Business Profile

Win the local map pack and the reviews behind it.

Not sure which fits? Book a free scoping call and we will point you at the one that moves your numbers most.

// From the blog

Find Out Whether You Should Build at All

Send one message describing the workaround that is costing you time. We reply within one business day and set up the scoping call, which is free. You will leave it knowing whether this is a build, a much smaller integration, or something you should buy off the shelf instead.