AI product development: copilots, assistants and AI-native CRMs

A CRM designed with the model inside it from the start. It reads call notes and email, drafts follow-ups, scores leads against your own history, summarises accounts and flags exceptions for a person to decide. It still has contacts, pipeline, permissions, reports and integrations, and it runs on the same Spring Boot and MySQL foundation as a traditional CRM.

An assistant answers questions from your data and shows its sources. A copilot drafts and acts inside a tool your team already uses, with a person approving each step. An agent carries out multi-step work on its own, with approval only where a wrong move would be expensive. We pick the shape the job can genuinely support today.

It depends on four things: how many systems it reads from or writes to, the state of the documents it learns from, how much a wrong answer costs, and where the model has to run. A read-only assistant over one clean document library is a small project. A copilot that drafts inside your CRM, respects every user's permissions and logs each action is a larger one. We give a fixed price once the scope is clear, or bill two-week sprints while it is still being discovered. The proposal states the number before work begins.

Three things: model usage, billed by the provider per token; hosting for the application, index and database; and monitoring. We estimate the cost per request during design, set a limit in code and report it in production. Where a smaller model scores the same on your evaluation set, we use it.

Usually, yes. If it runs on a modern stack such as Spring Boot, we add the feature inside the same backend. If it is Salesforce, HubSpot or another product, we build alongside it through its APIs. Each feature, such as a summary, a score or a drafted reply, gets its own evaluation set, and nothing needs a rewrite.

Not by default. OpenAI, Anthropic and Google Cloud each state that business and API data is not used to train their models unless you opt in or give permission. We use only the providers you approve in the proposal, under their API data terms, and serve an open-weight model in your network when no outside provider is acceptable.

We do not promise a model never makes things up. We ground answers in retrieval with citations so a wrong answer is visible, constrain outputs where the format matters, measure against an evaluation set built from real questions, and put a human approval step on anything where a wrong answer is expensive.

Yes. AI work starts with a feasibility check on your real data and a written go or no-go. After that, product sprints run for two weeks with a demo at the end of each, and you can stop after any sprint.

Most first production releases ship in six to twelve weeks. Scope, evaluation criteria and the date are agreed before work starts, and you see a working build every week.

Whichever scores best on your evaluation set at a cost you accept. We usually benchmark Claude, Gemini, OpenAI models and an open-weight option, and design so the model can be swapped later without a rewrite.

Models, prompts and data keep changing, so the evaluation set keeps running. You can run the product yourself with the runbook we hand over, or keep us on a monthly retainer for monitoring, model upgrades, evaluation runs and new features.