Building our own SaaS taught us how to build yours
What should you know about AI SaaS company lessons from a vendor that runs its own products?
Running TheEazy CXM, HXM and Zentrix in production is where our patterns for evals, multi-tenancy and cost control come from. We carry pager duty, pay our own inference bills and answer to our own customers, and every practice we bring to a client build was first tested on a system we could not walk away from.
The AI SaaS company lessons we bring to client work were not learned from clients. They were learned from running TheEazy CXM, a CRM and customer-experience product from the same group, alongside HXM and Zentrix, as live multi-tenant software with paying customers, support queues, upgrade cycles and a monthly inference bill we have to explain to our own finance team. A services company that has never operated a product tends to optimise for handover. A product company that has never done services tends to build only what it needs. Being both is uncomfortable and useful, and this article sets out what it taught us and how it shows up in the systems we build for others.
Why running a product changes how you build for others
When you operate software, three things stop being abstract. Reliability is a phone call at night, not a slide. Cost is a line you can see rising per account, not a forecast. And the gap between a feature that demos well and one that customers use is measured in your own churn. The practices we describe on the about page, evals over demos, shadow mode before autonomy, policy-gated actions and model-agnostic routing, are each a response to something that hurt on our own products first.
Seven lessons and where they came from
| Lesson | What happened on our products | What we now do on every client build |
|---|---|---|
| Evals before features | An AI feature that impressed in a demo regressed after a model update and nobody noticed for weeks | An evaluation suite is the first deliverable and the release gate |
| Tenant isolation is not optional | Early shortcuts in data scoping cost a painful refactor once customer count grew | Tenant scoping in the data layer, the retrieval index and the prompt context from day one |
| Cost per account is a product metric | Inference spend grew with usage in ways per-seat pricing had not anticipated | Per-tenant cost tracking, per-task model routing and usage limits built in, not bolted on |
| Shadow mode before autonomy | Letting an assistant act on records too early produced clean-up work and lost trust | Suggest first, act with confirmation, act alone only after measured accuracy |
| Adoption is designed, not assumed | A copilot placed behind a menu was ignored; the same capability inline in the workflow was used | Copilot UX is designed into the screen where the work happens |
| Boring infrastructure wins | Novel components created incidents that ordinary ones would not have | Managed databases, plain queues, standard observability; novelty only where it earns its place |
| Support is where the roadmap lives | The most valuable feature requests came from support tickets, not from planning | Weekly review of escalations and knowledge gaps in every agent deployment |
Multi-tenancy: the lesson we paid for
Multi-tenant SaaS with AI features has a specific set of failure modes. A retrieval index that is not scoped by tenant will eventually surface one customer's document to another. A prompt context assembled from the wrong account is a data leak with a friendly tone. A shared rate limit means one heavy tenant slows everyone. We learned each of these on our own products, at small scale, and fixed them before they mattered. In client builds the tenant identifier travels with every request from the API layer through retrieval to the model call and into the logs, and the evaluation suite includes cross-tenant probes that must return nothing. The architecture is described in multi-tenant LLM architecture for SaaS.
Cost control: what a monthly inference bill teaches
Paying your own bill changes your engineering. On our products we discovered that a small number of tasks generated most of the spend, that caching was worth more than any prompt optimisation, and that a cheaper model passed the threshold on more tasks than we had assumed. We also learned to report cost per account, because a customer whose usage costs more than their subscription is a pricing problem you need to see early. Every SaaS build we deliver now tracks cost per tenant and per task from the first week, and the pattern for pricing AI features is in how to price an AI feature in your SaaS product.
Evals: the practice we adopted after being burned
The first AI feature we shipped in our own product had no evaluation suite; it had a demo that went well. A provider updated the underlying model, behaviour shifted subtly, and the change was found by a customer rather than by us. The suite we built afterwards is the ancestor of the one we now ship with every client feature. It is also why our stance on this is unbending: we have seen what the absence costs, and we were the ones paying.
Adoption: features die quietly
A capability that lives behind a menu item is a capability nobody uses. We learned this by watching usage analytics on our own products and seeing an assistant with strong evaluation scores and almost no sessions. Moving the same capability inline, next to the record the person was editing, with a suggestion they could accept in one click, changed the picture. It is why our copilot builds begin with where the work happens rather than with the model, and why we measure adoption alongside accuracy; see copilot adoption: why most AI features die in a month.
We do not recommend anything to a client that we would not run on our own product at night.
Where being a product company helps a services client
The practical benefits are specific. We have reference implementations of tenant scoping, cost tracking, evaluation harnesses and routing that are already in production, which is why fixed-price programs can be short. We have opinions about SaaS operations, upgrade cycles, feature flags and support tooling that come from doing them rather than reading about them. And for clients building CRM-adjacent products, TheEazy CXM is a concrete example of the patterns, and sometimes a component to integrate with rather than rebuild. The SaaS development service, from $31,500 or ₹20.8L, is built on those reference implementations.
Where it does not help, and what we do about it
A product company can be tempted to build every client the product it already has. We guard against that with the discovery sprint, whose recommendation is sometimes to buy, wait or not build, and by keeping our reference components as licensed, replaceable pieces rather than a platform the client is tied to. Clients own their code and can remove any component of ours; that is the same ownership stance we hold everywhere, and it stops the product side of the group from becoming a lock-in strategy for the services side.
A worked example
A field-service SaaS company wanted an in-app copilot that could summarise job history, draft customer messages and update records on request. Almost every decision in the build came from our own product experience: the copilot was placed inline on the job screen rather than in a side panel; record updates began in suggest mode and moved to confirmed actions only after shadow-mode accuracy was measured; every model call carried the tenant identifier and was costed per account; and the evaluation suite included cross-tenant probes from the first run. Their product team recognised the trade-offs because they were the same ones they faced elsewhere in their product. The outline is in the in-app copilot case study.
Team and timeline
SaaS builds run as fixed programs: a Sprint Zero at $3,250 or ₹2,00,000 to settle tenancy, pricing and the AI scope; a Launch 6 at $26,500 to $45,500 for a six-week MVP; or a SaaS development engagement for a larger platform. The team is typically two engineers and a product lead, with our reference components licensed into the deliverables with source. After launch a Care Plan carries the backlog, the quarterly model re-evaluation and the cost review. Prices are on the pricing page, and the SaaS-specific view of our work is on the SaaS industry page.
Before you start: a checklist
- Ask any vendor whether they operate a multi-tenant product themselves, and what it taught them
- Decide the tenancy model before the first line of code; it is the hardest thing to change later
- Require cost per tenant and per task to be reported from the first week
- Plan the AI features as suggest, confirm, then act, with a measured gate between each
- Design where the copilot appears in the workflow before choosing the model
- Put cross-tenant probes in the evaluation suite
- Agree which vendor components are licensed in and confirm they can be replaced
- Set up a weekly review of support escalations as the roadmap input
Questions clients ask
- Will you push your own product on us? Only where the discovery sprint shows buying it beats building, and we will show the reasoning. Most client builds do not involve it at all.
- Are your reference components a platform we are tied to? No. They are licensed with source, replaceable, and you own everything built on top.
- Do you use the same tools internally that you deliver? Yes: the evaluation harness, routing layer and cost tracking in client builds are the ones running on our products.
Related reading
Read multi-tenant SaaS architecture: the decisions that avoid a rewrite and the about page for the group behind the products. For the tenancy patterns we started from, AWS's SaaS architecture guidance is a solid primary reference.
We build for clients the way we build for ourselves because we have to live with the second one, and that is the best guarantee we can offer on the first.
Frequently asked questions
Why does it matter if an AI vendor runs its own SaaS?
▾
Because operating a product exposes the failure modes that a handover hides: regressions after model updates, cost growing per account, tenant leaks and features nobody uses. A vendor that has paid for those lessons builds differently.
What are the main lessons from building SaaS with AI features?
▾
Evaluate before you ship, scope every request by tenant, track cost per account and per task, introduce autonomy in stages, design the feature into the workflow, and treat support escalations as the roadmap.
Does Eazyware build client products on TheEazy CXM?
▾
Not by default. Client products are built on their own code, which they own. TheEazy CXM is a reference for CRM patterns and occasionally an integration target when discovery shows buying beats building.