If you're asking what to ask before trusting your business to new software, start with six questions. Ask who owns your data and how you get all of it out. Ask who built the app and who fixes it. Ask what each worker can see, who handles card security, and what the price covers when you add a truck.
Get each answer in writing, then test it with real jobs. A good vendor can answer all six within a day. Slow or vague answers before you sign usually mean slow or vague answers after.
What should I ask about my data before trusting my business to new software?
Ask who owns your customer list, property notes, job history, estimates, invoices, payments and photos, and get the answer in writing. Your customer list is the business. If you leave, you need all of it back in a format you can open.
Send these questions by email so the replies are on paper:
- What happens to my data if I cancel? Ask for the export format, any export fee, how long the data is kept and when it's deleted.
- Can I export customers, properties, job history, estimates, invoices, payments, photos and notes myself, without calling support?
- Do you use my data to train products or sell insights? Which subcontractors touch my data, and where is it stored?
Ask for a test export before you sign. The NIST small business cybersecurity guide recommends identifying your critical business data and the systems and services that handle it. It also recommends assessing risk from suppliers before a formal relationship starts. For a service pro, that critical data is a short list: customers, addresses, gate codes, what's owed and who's on a plan.
How can I tell if there is a real developer behind an app?
Ask who understands the code today and who fixes it when something breaks at 7 a.m. on a Monday. A business can't run on software that breaks when the people behind it can't fix it.
Three practical checks:
- Who understands it. Ask how a recent bug was found and fixed, and how long the fix took. A real answer names the problem and the fix in plain words.
- Who fixes it. Ask whether the person who answers support can reach the person who changes the code.
- What it runs on. Ask what cloud infrastructure hosts the app and who watches it.
Whether AI tools helped write an app matters less than whether someone knows what the code does. Plenty of solid software is built with modern tools. The real risk is software nobody can diagnose.
Who do I call when my field service app breaks?
Before you move a single customer, you should be able to name the support channel, the people behind it and how they respond, in writing. Ask where you send a problem, how you track it and who sees it.
Then ask about the bad days:
- How often are backups made, how long are they kept, and how fast can my account be restored? Can a deleted job, photo or customer record come back?
- How quickly will you tell me about a breach, what help do you give, and who notifies my customers?
Put support and breach terms in the contract, not just a sales call. NIST's guidance on working with outside vendors says contracts should clearly document service levels, responsibilities and expectations. Breach-notice rules vary by state, so check with your state or an attorney on what you'd owe your own customers.
What can a technician see or change?
A technician should see their own visits and the notes and gate codes they need, and nothing more unless you allow it. Ask for separate permissions for the owner, the office, techs and any subcontractors. Ask whether a former employee's access can be shut off the same day they leave.
Ask for these controls by name: multi-factor sign-in, role-based access, encryption, audit logs, limits on the vendor's own staff access, and a written incident-response process. Also ask whether you can see who changed an estimate, invoice, customer record or payment. When a customer disputes what was promised, that history settles it.
Who is responsible for card payments and PCI?
The business owner stays responsible for card security even when an app and its payment company handle every card. The PCI Security Standards Council says PCI DSS applies when a merchant outsources all payment processing. The merchant must confirm the provider's compliance, keep written agreements on who is responsible for what, and check compliance at least once a year.
Ask which payment company processes the cards. Ask whether card numbers or security codes ever enter the app's own system. A setup where the software never stores sensitive card data is simpler to live with. Confirm with your processor which self-assessment, if any, applies to you.
What should I look for in an app I will not outgrow?
Look for an app that runs one truck and several crews on the same account, with the price for users, crews and messaging written down before you sign. Switching software costs a season of evenings, so pick one you won't have to leave.
Ask for written pricing on users, crews, locations, scheduling, customer texts, storage, payment tools, onboarding, support and future price increases. Then read the cancellation terms. Look at the minimum commitment, notice period, automatic renewal, early-termination fees, export charges and how long access lasts after you give notice.
Worked example: a two-truck pest control company
Say a pest control company runs two trucks and about 220 quarterly customers. The owner sends 12 written questions to an app she's testing. She also enters 10 real customers, their 10 jobs and 10 invoices for the coming quarter.
The vendor answers 9 of the 12 questions in writing. The other 3 (breach notice, backups and export fees) get a phone call and a promise to follow up. The test export returns all 10 customers and all 10 jobs, but only 8 of the 10 invoices, and no photos.
The quote, as an example: $59 a month plus $30 per tech, on a 12-month term that renews automatically. With 2 techs, that's $59 + $60 = $119 a month, or $1,428 a year. A third tech in spring makes it $149 a month, or $1,788 a year, and leaving early means paying out the term.
Before moving 220 customers, she asks for the 3 missing answers in writing, a complete export with invoices and photos, and a price for 4 techs. If those don't arrive, the trial failed.
| Question | Good answer | Warning sign |
|---|---|---|
| Data if I cancel | Format, fee and delete date in writing | "We'll work something out" |
| Test export | You run it yourself today | Only through support, later |
| Who fixes bugs | Names a recent fix | No one can reach the code |
| Backups | How often, how long, how fast | "It's in the cloud" |
| Card data | Never stored in the app | Unsure who processes cards |
| Price as you grow | Written for more crews | Quote for today only |
How do I measure whether a software trial passed?
Score a trial on two numbers: how many of your questions came back in writing, and how much of your test data came back out.
- Written-answer rate = questions answered in writing ÷ questions asked × 100
- Export completeness = records returned in the export ÷ records entered × 100
In the pest control example, the written-answer rate is 9 ÷ 12 × 100 = 75%. Export completeness is 28 ÷ 30 × 100 = 93%, with no photos. Anything under 100% on either number is a question to settle before the whole customer list moves, not after.