Building an AI-First SaaS: What We Learned Shipping ServicePilot

We build apps for clients. We also build our own, and ServicePilot — an AI-first job management platform for Australian trade and field-service businesses — is the one that taught us the most. It runs on web, iOS and Android against a single Supabase backend, and its headline feature is AI that drafts a priced quote from a plain-English job description or a forwarded customer email.

Here is what we would tell anyone starting an AI-first product now.

1. The AI must never be the last step before a customer sees something

Our original design had the AI draft a quote and offer a "send" button right there. It tested badly, for a reason that took us embarrassingly long to hear properly: a tradie's quote is their reputation. A wrong number does not just cost that job, it costs the referral chain behind it.

So we made approval structural rather than optional. The AI produces a draft. Every line item is editable. Nothing leaves the system without a human pressing send. That is not a limitation we apologise for in the marketing — it is the reason people trust it enough to use it daily.

The general lesson: in any workflow where the output is attributable to your user, the AI's job is to eliminate typing, not to eliminate judgement. Products that get this backwards get abandoned after the first embarrassing mistake.

2. Ground the model in the customer's own data, or do not ship it

An LLM asked to price a job will happily invent a number. It will be plausible, confidently stated, and wrong — and in a trade business, wrong by a few hundred dollars either way is the difference between losing the job and losing money on it.

Our quoting engine never asks the model for prices. It asks the model to identify which line items from this business's own catalogue apply to the described job, and in what quantity. The pricing arithmetic is ordinary code against the customer's rate card.

That split — the model does language, your code does the numbers — is the most important architectural decision in the product. It also means the same feature is verifiable: we can show a customer exactly which of their own catalogue lines produced the quote.

The corollary is a cold-start problem. A new customer with an empty catalogue gets nothing useful. We solved it by shipping starter price books for more than 40 trade verticals — electrical, plumbing, glazing, pest control, lawn care and so on — so the first quote works on day one and gets refined from there.

3. Multi-tenancy and AI features are the same security problem

Every AI feature widens your data surface. Ours reads jobs, clients, catalogues and past quotes. The moment that data crosses a tenant boundary, you do not have a bug — you have a breach.

Two rules we enforce without exception:

Tenant identity comes from the verified token, never from a parameter. This sounds obvious until you build an AI tool interface, where it becomes very tempting to let the model pass a tenant ID as an argument. Our remote MCP server — which exposes read-only business data to AI assistants — derives tenant scope entirely from the access token claim. No tool argument can influence it. A model cannot leak what it cannot address.

Row level security is the floor, not the ceiling. Postgres RLS enforces isolation at the database, so an application bug cannot read across tenants. We wrote up the Supabase RLS patterns we use, including the ones that quietly do nothing.

4. Cost per action is a product decision, not an infrastructure one

Per-request LLM costs are small. Multiplied by every quote across every customer on a flat monthly plan, they are a margin question you need an answer to before launch, not after.

What worked for us:

• Cache aggressively at the catalogue layer. Most jobs in a trade are variations on a dozen patterns. Matching against a customer's own history is cheaper and more accurate than asking the model again.
• Route by difficulty. Straightforward jobs do not need your most expensive model. Ambiguous multi-trade briefs do.
• Make the expensive path the one that generates revenue. Quoting is directly tied to the customer winning work, so cost per quote is easy to justify. Speculative background AI that nobody asked for is not.

5. Ship the boring surrounding software

This is the lesson that most surprised us. AI quoting is the reason people try ServicePilot. It is not the reason they stay.

They stay because the dispatch board runs the week, the recurring maintenance jobs generate themselves, the invoice goes out with a pay-now link, the SWMS attaches to the job, and it all syncs to Xero. The AI is the wedge. The operating system underneath it is the product.

We have seen a lot of AI-first products that are one clever feature with nothing behind it. They demo brilliantly and churn hard. If your AI feature sits inside a workflow, you have to build the workflow — and the workflow is where most of the engineering actually goes.

6. Mobile is not a companion app in field services

We built web first and mobile second, which was correct for shipping order and wrong for how we thought about it. Office staff quote and invoice. Crews work jobs from a phone, in a driveway, sometimes with one bar of signal.

Those are different products sharing a database, not one product on two screen sizes. Native iOS and Android — rather than a wrapped web view — gave us the camera, offline behaviour and background performance the field half genuinely needs.

What we would do the same

Grounding every generated number in the customer's own data. Keeping a human in the loop by design. Enforcing tenant scope at the token and the database rather than in application code. Shipping the unglamorous workflow software around the clever feature.

What we would do differently

Start the mobile apps earlier, and build the starter price books before the AI rather than after. The cold-start problem was foreseeable, and we did not foresee it.

If you are building an AI-first product and want a team that has shipped one end-to-end rather than just prototyped one, get in touch. You can also read the full ServicePilot case study or our guide to integrating LLMs in mobile apps.