Should You Build a Custom Field Service Platform?

You've paid for the software three years running. It does most of what you need, and the parts it doesn't do, your office manager works around with a spreadsheet and a whiteboard. Then you hired two more techs and the bill went up again. Somewhere in there you started wondering what it would cost to just have something built.

That's a fair question, and the honest answer isn't always yes. A custom field service platform makes sense for some HVAC, plumbing and electrical shops and is a waste of money for others. The line between the two has less to do with crew size than most people think.

By the end of this page you should be able to tell which side of that line your shop is on, and what to ask a vendor before you sign anything.

A custom field service platform starts from your jobs

Most field service management software is one product sold to thousands of shops. The database is fixed. The job screen is fixed. What you get to change lives in a settings menu: turn on deposits, rename a job status, hide a field your crew doesn't use. That's configuration, and it's cheap because the vendor built it once and sold it many times.

A custom build starts from your jobs. The data model is designed around the inventory and assets you actually track: an irrigation system with fourteen zones, a service agreement with four visits a year, a job that can't be closed until someone photographs the panel. Custom workflows mean the app moves a job from call to quote to dispatch to invoice the way your office already moves it, including the step everyone else's software doesn't have.

Work order management is where the difference shows up fastest. In an off-the-shelf app, a work order has the fields the vendor chose. In your own platform, it has the fields your techs need and nothing else, and it can trigger whatever should happen next without a human remembering.

You own the accounts and the code. That's the part most owners don't ask about until they want to leave, and it matters more than any feature comparison.

The rest of this comes down to when that's worth paying for.

Buying field service management software vs building your own

Jobber, Housecall Pro and ServiceTitan are good products. If your work looks like the work they were designed for, buying one is the right call, and we tell owners that. You get scheduling, invoicing and a tech app on day one, support when something breaks, and a monthly bill instead of a build.

Configuration gets you a long way. You can rename fields, set up job types, turn features on and off, build templates. Most field service management software lets you shape the surface of the app without touching what's underneath.

What configuration can't do is change the shape of a job. If your crew does something the vendor never planned for, like a multi-visit seasonal service, a system that needs measurements recorded in a specific order, or per-zone and per-controller asset tracking that has to carry from one year to the next, you end up putting it in the notes field. The notes field is where good information goes to die. Nobody reports on it and nobody automates from it.

The other wall is integrations. Every vendor has a list of what they connect to, and that list is the list. If the supplier portal, the county permit system or the accounting setup you actually use isn't on it, your office handles the gap by hand, forever.

A custom field service platform starts from your process instead of adjusting to theirs. You get custom workflows that match how the office already moves a job, and you can connect whatever you need to connect. You pay more up front and you take on decisions the vendor would have made for you.

When your work order management outgrows the settings menu

Most HVAC, plumbing and electrical shops never hit that wall. If your scheduling is a board of jobs and techs, your dispatching is one person moving names around in the morning, your inventory and asset tracking is a shelf in the van and a shelf in the shop, and your work order management is a checklist and a signature, an off-the-shelf app will do the job for years. Buy it, set it up properly, move on.

Three things tell you when you've outgrown it. How big your crew is and how many people touch a job. How complicated the work itself is, and whether the software can describe it without the notes field. And what you can spend, plus how long you can wait before the new system has to be running.

Take them one at a time.

Dispatching works fine until the crew gets bigger

A three-person plumbing or electrical shop pays for three seats. That's cheap almost anywhere, and the structure of off-the-shelf software fits a small crew fine: one dispatcher, one board, one way to close out a job.

At twenty or thirty people, two things change. Per-user pricing becomes a real line item that grows every time you hire. And the way a job moves through your office gets specific: a lead tech, an apprentice, a warehouse person, someone chasing the invoice. If the app can't describe those roles, your people work around it.

Work a template can't hold needs custom workflows

Most off-the-shelf work order management assumes one visit, one tech, one invoice. Plenty of trade work doesn't look like that. An irrigation crew does a spring startup, a mid-season check and a winterization on the same property, and each one has its own steps. An HVAC shop selling maintenance contracts needs the contract to generate the visits. A cleaning company runs the same route every other Tuesday.

You can force that into a template with notes and workarounds. Or the app can hold the steps itself, which is what custom workflows are for.

What per-user pricing plans cost against a fixed-price build

A custom build costs money up front. Per-user pricing plans cost money every month, forever, and the price goes up when you hire. Pull up your current pricing page and add a seat for the next two techs you plan to hire. That's the real number to compare against a fixed-price build.

Time matters too. A custom platform takes weeks of building before anyone uses it, and you keep running your current setup in the meantime. The rebuild we took over in June 2026 is a 13-week job. If you need something working Monday, configure what you have and revisit this after your busy season.

The crew's mobile app, the office screens, and what's underneath

The feature list looks a lot like the software you already pay for. The difference is in the details, like whether the crew's app still has offline access in a basement with no signal, and the details are where a shop either saves an hour a day or loses one.

Scheduling holds the calendar and the crew's day. Dispatching moves a job to the right tech and tells them about it without a phone call. Quotes go out from the field, get followed up on their own, and turn into a job with one tap when the customer says yes. Invoicing sends the bill and chases it, so the office manager isn't calling the same three customers every Friday.

The crew gets a mobile app that works on their own phones, iOS and Android, and holds job notes, photos, inventory and asset tracking, and the next stop. A customer portal gives people a place to see their quote, approve it, pay it and look up what was done last spring, which cuts the "can you resend that" calls. Reporting and analytics answer the questions you actually ask: what got billed, what's still open, which jobs ran long.

None of this is bolted on. We build the flow around how your HVAC, plumbing or electrical shop already works. If your techs quote three tiers on an irrigation install, the quote screen has three tiers. If your busy season runs on a route list, the schedule shows a route. Payments run through Stripe in your account, texts through Twilio in your account, and both go where your process needs them.

Start with the two or three things that break most weeks. Those get built first.

Whose name is on the hosting and integration accounts

Every account we touch is created in your name, on your card. Hosting. The database. The Apple and Google developer accounts. Stripe. Twilio. You sign up, you're the billing owner, and you add us as a user. We get access. We never get ownership.

That sounds like a small administrative detail until the day you want to leave.

Here's what happens to owners who don't have it. The vendor opened the App Store account under their own company name, so your app lives on their shelf. The hosting is on their AWS bill. The Stripe account that takes your customers' money is theirs, with your payouts routed to you as a favor. Your customer database sits on a server you've never logged into. The SMS number your customers have been texting for four years belongs to somebody else's Twilio account.

Now you want a different developer, or a lower price, or just faster replies to your emails. Ask for your data and see what comes back. Sometimes it's a CSV and a shrug. Sometimes it's a migration fee. Sometimes it's silence for three weeks while your shop keeps running on software you can't change.

Chris will say it straighter than most: an agency or IT shop that opens accounts in its own name and holds the client there is doing something close to criminal. Being the opposite of that is the reason this company exists.

The practical version is that you keep the keys to every piece. The integrations run on your credentials, so if you decide to change payment processors or move your texting to a different number, you make that call. Your app store listing, your reviews, your ratings, your download history stay attached to your business.

Ask any vendor you're talking to, this week: whose name is on the hosting account, and whose card pays for it? If the answer is theirs, ask what it costs to get it moved to yours. The number they give you tells you what the relationship really is.

The code should be yours too

Accounts are half of it. The other half is the software itself.

When we build, we set up a GitHub account in your name and the repository lives there. Every line of the app, the web frontend, the API, the automation logic. You get a perpetual licence and the source code, not a login that stops working when the invoices stop.

That means you could hire another developer tomorrow. You give them access to your repo, they read the code, they pick up where we left off. No penalty, no exit fee, no period where your business is frozen because someone else is holding your software hostage while you negotiate.

Chris's position on this is blunt: a shop that writes code for a client and keeps the repo in its own name has built a trap, and the fact that it's normal in the industry doesn't make it any less close to criminal. We built the company to work the other way around.

There's a side effect worth knowing. When the client owns the code, the vendor has to earn the next job on the work. We keep building for people because they want us to, not because leaving would cost them their business.

Ask to see the repo before you sign. Ask whose account it sits in.

What we're building right now

Pete runs Make It Rain, LLC, an irrigation company in Fairfield County, Connecticut. We took over his field service platform in June 2026 as a 13-week rebuild, and that work is underway as this goes out.

The build has four pieces. A Flutter mobile app that runs on both iOS and Android, so the crew has one app and we maintain one codebase instead of two. A web frontend for the office, plus a customer portal on the same web side, so a homeowner can look at their own jobs and paperwork without someone in the office pulling it up for them. An API underneath both, which is the part nobody sees and everything depends on. And two outside services wired in: Stripe for payments, Twilio for the texting.

Every one of those accounts is in Pete's name, on Pete's card. Stripe, Twilio, hosting, the database, the Apple and Google developer accounts. We have access to do the work. He has ownership.

Irrigation is seasonal in Connecticut, which shapes the whole thing. Spring startups and fall blowouts come in waves, and the software has to handle a few hundred properties needing the same visit inside a few weeks. That's a different scheduling problem than an HVAC shop running steady service calls year round.

We're productizing the platform as we go. The parts that aren't specific to irrigation, meaning the dispatch board, the job notes, the invoice chasing and the payment flow, are being built so they can be set up for plumbing, electrical, HVAC and cleaning companies without starting from zero. A trade shop coming in later gets most of a working platform and a shorter build for the parts that are actually theirs.

If you want to see where it stands, ask us. We'll show you.

The fixed-price, no-per-user-fee model

Per-seat pricing punishes you for growing. Hire two techs in spring and the monthly bill goes up, even though the software didn't change. Most field service plans are built that way on purpose: the vendor's revenue rises with your headcount, forever, whether or not they ship you anything new.

We quote a build at a fixed price. You know the number before work starts, and it doesn't move because the crew got bigger or because we spent longer on something than we planned.

What you get at the end:

• A perpetual licence. You can run the software as long as you want, with no renewal date and no switch we can flip off.
• The source code, handed over, not held back.
• No per-user fees. Add a tech, add a dispatcher, add a seasonal helper. The price stays the price.

There are still real costs after launch: hosting, your SMS and payment accounts, and any work you want done next. Those are on your card, in your name, and you can see every line of them. That's a different thing from a subscription that quietly grows every time you hire.

The honest tradeoff: a fixed-price build costs more up front than a monthly plan does in month one. Off-the-shelf software is cheaper to start and cheaper to abandon. A custom field service platform costs money once and then stops charging you for people. Which one is cheaper depends on how long you plan to be in business.

What ongoing maintenance actually costs you

Software you own still has running costs. Hosting, the database, your Twilio number, your Stripe account, the Apple and Google developer accounts. Those bills land on your card every month whether we're involved or not, and you can read every line of them. If you ever want to see what you're actually paying to keep the app running, log into those accounts and look. Nobody has to send you a report; it's on your phone before the crew leaves the yard.

Updates work differently than they do on a subscription. When Apple or Google changes something, the app needs a build to stay in the stores. That's real work and it costs real money. It's also work you approve, on your schedule, from whoever you want doing it.

Nobody can force an upgrade on you. If a vendor decides to redesign their scheduling screen, every shop on that platform learns the new screen. When the code is yours, the custom workflows your crew already knows stay exactly as they are until you ask for a change. Your dispatcher doesn't come in Monday to a rearranged calendar.

The practical version: budget for hosting and your platform accounts as a fixed monthly cost, and treat new features as projects you decide to fund. Some years you'll spend nothing beyond hosting. Some years you'll want three changes. That's your call, not a renewal date.

How to vet a custom software vendor

Ask the ownership questions first. They're the fastest way to find out who you're dealing with, and most vendors answer them in under a minute.

• Whose name goes on the accounts? Hosting, database, app store listings, Stripe, Twilio. Every one of those should be created in your business name, on your card. If a vendor says they'll "handle all that on our side," you've learned something important.
• Who owns the code repository? Ask for a GitHub account in your company's name with you as the owner. Then ask whether the source code is included in what you're paying for. "You get the app" and "you get the code" are two different deals.
• Is the price fixed or hourly? Fixed price means the vendor has thought the build through and is carrying the risk of getting the estimate wrong. Hourly means you are.
• Are there per-user fees? Ask what happens to your bill when you hire two more techs next spring.
• What happens if we part ways? The answer you want is boring: you keep the accounts, you keep the repo, you hire someone else, nothing breaks. If there's an export process, a transition fee, or a clause you need a lawyer to read, ask why.

Then one more, less about paperwork: ask who you'll actually talk to when something breaks on a Tuesday morning. A name, not a ticket system.

We hold the view that opening client accounts in the agency's own name is close to criminal. It's the single thing this company was built to be the opposite of. You don't have to take our word for it. Ask any vendor the account question and watch how comfortable they are with it.

If you want to run those questions past us directly, book a New Project Consultation.

Common questions about custom field service platforms

What's the difference between a CRM and field service management software?

A CRM tracks people and sales. Who called, what you quoted, when to follow up, what the customer bought last spring. It's built around the relationship.

Field service management software tracks work. Which job, which tech, which truck, what time, what parts, what got signed off in the driveway. It's built around the day.

Plenty of shops need both, and a lot of the field service tools on the market bolt a light CRM onto the side. If your problem is quotes going cold, you have a CRM and follow-up problem. If your problem is techs showing up without the right information, that's field service.

How long does a custom build take?

Depends entirely on scope. The rebuild we're running now is scoped at 13 weeks: a Flutter app for iOS and Android, a web frontend, an API, Stripe for payments, Twilio for texts. A narrower build takes less. If a vendor gives you a timeline before they've asked what your crew does all day, that number means nothing.

What happens if we stop working together?

You keep everything. The hosting, the database, the app store listings, the payment and SMS accounts are all in your name on your card from day one. The code sits in a GitHub account you own. Hire someone else on a Monday and they can clone the repo and get to work.

Do I need custom software if I only have a few techs?

Usually not. Configurable software handles a small crew doing fairly standard work, and it handles it cheaper. Custom starts making sense when the work itself is unusual, or when you're paying per user for seats every month with no end date.

If you're weighing a build against what you're using now, it helps to talk it through with someone who'll tell you when off-the-shelf is the better call. Book a New Project Consultation and bring your current bill and your biggest headache.