Adler Custom Systems
Book a Call

What should an Idaho contractor ask before hiring a software builder?

Straight answer up front. Then the details.

The short answer

Ask the questions whose answers are expensive to discover later: who owns the data and the code, who controls hosting and the domain, which system is the source of record for your accounting, how crews will test it in the field, what the estimate assumes, what you keep paying after launch, and what happens if the builder becomes unavailable.

Take the whole list below into every conversation — including with us. A builder who answers these clearly and in writing is showing you how the relationship will run. One who gets uncomfortable is telling you something too.

How to use this

You don’t need to be technical to use these. You need the answers written down and the same questions asked of everyone you’re considering, so you’re comparing the same things rather than comparing sales confidence.

One instruction that matters: ask the ownership, continuity and cost questions BEFORE you like someone. They’re much harder to raise after you’ve decided you want to work with them.

The hiring checklist

Fifteen categories. Work top to bottom — the early ones determine whether the project works, and the later ones determine what happens when something goes wrong.

A. Process

How they learn your operation. The strongest early signal of whether the result will fit.

  • How will you learn how our jobs actually move?Look for a described method — not 'we'll have a kickoff call.'
  • Will you talk to the people doing the work?Office and field, not only the owner. This is where the real workflow lives.
  • How do you map exceptions?The happy path is easy. Change orders, reschedules and unusual jobs are where systems fail.
  • What happens if discovery shows we shouldn't build?A builder who has never talked a client out of a project is worth a second look.

B. Scope

What you're actually buying first — and what you aren't.

  • What exactly are we building first?A named smallest useful release, not a vision.
  • What is deliberately NOT included?The exclusions are more informative than the inclusions.
  • How do we add something later, and how is it priced?Change requests should have a defined path before you need one.

C. Ownership

Data and code are separate questions with separate answers.

  • Who owns our business data — explicitly, in writing?Silence in an agreement is not the same as ownership.
  • Who owns the custom code, and by what mechanism?Assignment, license or something else — have it named.
  • What third-party or licensed components are involved?Normal and fine — but it should be visible, not discovered later.

D. Infrastructure

The accounts. Small-sounding, and the most common source of lock-in.

  • Who controls the repository, and whose name is it in?Ask for access during the project, not only at handover.
  • Who controls hosting, and whose card is it billed to?If you can't see the bill, you may not control the account.
  • Who controls the domain and DNS?The smallest item here and the most disruptive to lose.
  • Who controls third-party service accounts?Email, SMS, payments, mapping, storage — in your business name, ideally.

E. Integrations

Where 'it connects to QuickBooks' needs to become specific.

  • Which of our systems will connect, and in which direction?One-way and two-way are very different in cost and risk.
  • Which system is the source of record for each record type?Customers, invoices, payments and items each need one owner.
  • What happens when the connection fails?Retries, a visible queue and notification — not silent failure.
  • Who owns the connection when a vendor changes something?Third-party changes are the most common recurring maintenance item.

F. Migration

The stage most often underestimated on both sides.

  • What existing information needs to move?Customers, jobs, history, documents — decide what's genuinely needed.
  • How will migration be tested before we depend on it?Ask to see a sample migration checked against the old system.
  • Who cleans the data, and is that in the price?Messy history is the most common schedule and cost surprise.

G. Field use

Where contractor software succeeds or dies.

  • How will technicians and crews test this?Real people, real jobs, their own phones — not a demo device.
  • What happens with poor connectivity, if our sites have it?Only ask if it's genuinely your situation — offline capability isn't free.
  • How long does the core field action take?If it's slower than the text they send today, they'll send the text.

H. Security and access

Not a certification question — a control question.

  • How are roles and permissions handled?Who can see costs, customer data, pricing and other people's jobs.
  • Who has administrator access, and do we hold one?You should have a working admin account from day one.
  • How is access removed when someone leaves?Offboarding is the permission question people forget until it matters.
  • How are credentials and API keys stored and rotated?Expect a clear answer; expiry is a leading cause of quiet failure.

I. Testing

Ask how they test the messy cases, not the clean ones.

  • How do you test real jobs and real exceptions?Your actual jobs, including the awkward ones from last month.
  • What does a pilot look like, and who is in it?A small group, real work, a defined end and a fallback.
  • What happens to the pilot's findings?A pilot that changed nothing wasn't a real pilot.

J. Timeline

Judge the assumptions, not the number.

  • What assumptions is the estimate based on?Scope, integrations, migration, decision speed — all of it.
  • What changes the schedule?Ask for the three most likely reasons it slips.
  • Is this an estimate or a commitment?Both are acceptable answers; ambiguity isn't.
  • What do you need from us, and how often?Your availability is one of the biggest factors on the date.

K. Cost

Separate one-time from recurring before you compare anyone.

  • What is included in the build price?Discovery, design, build, migration, integrations, training — name each.
  • What remains recurring, and roughly what range?Hosting and third-party services are real and ongoing.
  • What counts as a change request?The definition matters more than the rate.
  • What would make this cost more than quoted?A builder who can answer this specifically has done it before.

L. Support

What happens after launch, agreed before launch.

  • What support is included, and for how long?Especially in the first weeks, when questions peak.
  • What is optional, and how is it priced?Hourly, project-based, monthly — you should be able to choose.
  • Is continued access to our system tied to paying you?The single most important question in this category.
  • How do we reach you when something breaks?And what response should we reasonably expect?

M. Continuity

Ask it directly. The answer should be a document.

  • What happens if you become unavailable?'We're not going anywhere' is a reassurance, not a plan.
  • Could another qualified developer take this over?From the documentation alone — not from a phone call with you.
  • What documentation will exist at handover?Ask to see an example from a previous project.
  • Are there transition obligations in the agreement?What happens to access, code and accounts at the end.

N. References

Relevance over quantity.

  • Can you show comparable work, or describe it?Confidentiality is a fair reason not to name a client — vagueness isn't.
  • Have you built for businesses where work happens in the field?Office software experience doesn't transfer automatically.
  • What project didn't go well, and what changed after it?The most revealing question on this page.

O. Local and onsite

Decide what proximity would actually be used for.

  • Do we actually need someone local — and for what?Name the specific use: ride-alongs, training, rollout presence.
  • Which parts of this benefit from onsite observation?Usually field workflow, rarely office reporting.
  • If you're not local, how will you learn the field reality?A good remote builder has a real answer to this.
  • Would we trade relevant experience for a shorter drive?Be honest about which one you're actually buying.

Save or print this page and bring it to every conversation. Nothing on it is gated, and there’s no email to hand over — it’s more useful to us if you actually use it.

Use it on us too

This checklist was written to be used against Adler Custom Systems. That’s the point of publishing it. If we can’t answer the ownership, continuity, cost and support questions clearly and in writing, you should treat that exactly as you would from anyone else.

The five answers that should worry you, from anyone:

  • Vagueness about who owns the data and the code
  • A price or a timeline before anyone has looked at your workflow
  • Continued access to your system depending on a continued payment
  • No answer to 'what if you become unavailable?' beyond reassurance
  • No plan for how the field will test it before rollout

One more, less obvious: a builder who agrees with everything you say. You are hiring judgment as much as construction, and a builder who has never told a client “that isn’t worth building” probably isn’t going to tell you either.

ACS guidance — written from operator experience building systems for contractors, not from vendor marketing. Last reviewed August 10, 2026.

Reviewed by Connor Adler, Adler Custom Systems

ACS guidance for evaluating software builders, including ACS. This is operational guidance, not legal advice — ownership, licensing and contractual obligations are determined by the actual agreement and should be reviewed by an attorney. No ACS pricing, timeline, support or contractual terms are stated or implied on this page.

Our approach

We design systems around your business.

Built from inside the operation—not from the sidelines. The people doing the work help shape the system.

  1. Listen
  2. Map
  3. Build
  4. Test
  5. Refine

Worked with Connor

Robert, ACS testimonial contributor.

He Helped Me Believe

Robert shares how working with Connor helped him believe in himself, gain clarity around his purpose and begin turning his mission into something real.

Watch Robert’s story

Where to go from here

Take the Idaho Systems Audit

Bring the checklist to your conversations — and bring clarity about what actually needs fixing. Seven questions about how your operation runs, with an honest read on whether a build is even the right answer.

Take the Idaho Systems Audit
  • About two minutes
  • No sales call required

Keep reading

Related questions