AI
YOUR OWN AI SERVICE
- 5+ projects
- from 1 week
- full cycle
A product of your own on top of an existing model: your logic, your interface, your data and your rules. It runs under your brand and solves your problem instead of answering everything.
WHO IS IT FOR?
Three situations that call for a service of your own rather than a subscription
- .01
THERE IS AN IDEA, THERE IS NO PRODUCT
You know what problem the service has to solve and who you would sell it to. Then the forks begin: which model, where it runs, what a request costs, and what happens once there are a lot of users. Every answer here drags the others along with it. Until they are drawn into one scheme the project cannot be priced — only a number named at random and revised later.
- .02
THE PROTOTYPE WORKS, THE PRODUCT DOES NOT
Thrown together quickly, it produces a result, and the first users even like it. But there are no accounts, no payments, no plan limits, no control over spending — and any load beyond a dozen people breaks both the service and the budget. Almost all the distance between a demo and a product is invisible: it is what happens when the model gets something wrong, when requests spike, and when a user decides to see how much the system can take.
- .03
IT HAS TO BE YOURS, NOT SOMEBODY ELSE’S
The job can be done with existing services, but every one of them is somebody else’s subscription, somebody else’s rules and somebody else’s access to your data. Selling that on to your own clients under your own name is not going to work. A service of your own also lifts the ceiling on price: you sell the result rather than reselling access, and you do not depend on what the provider decides to change tomorrow.
WHAT'S INCLUDED
We do not build below this line
- - Discovery and architecture.01
- - A model chosen and the cost per request worked out.02
- - Custom design, never a template.03
- - Built from scratch, no off-the-shelf assemblies.04
- - Accounts, roles and limits.05
- - Guardrails and control over answers.06
- - Admin panel by LUNO.07
- - Launch on our servers.08
- - Documentation and project handover.09
- THIS IS THE FLOOR, NOT A PACKAGE
Everything listed ships in every project — even the simplest and cheapest one. There are no stripped-down versions.
- THE ECONOMICS ARE WORKED OUT BEFORE THE BUILD
Every request to the model costs money. Exactly how much, and how that sits against the price you charge a user, is worked out during discovery rather than after launch.
- THERE IS NO CEILING
We do not assemble from templates, so we never run into someone else’s limits. From there the service is built out around how your product works: load, integrations, local models, plans of your own.
WHAT'S INSIDE
THE DATA STAYS WITH YOU
The model can be deployed on a dedicated server — yours or ours: requests, documents and conversations never reach an outside provider. The infrastructure is run by someone with twenty years behind them, and it is the same infrastructure the rest of our projects live on. If nothing sensitive is involved we work through a provider, which is cheaper and quicker. Which of the two it is gets decided before the start, not discovered after launch.
AI IS NOT NEEDED EVERYWHERE
Where accuracy has to hold without exception — calculations, money, legally binding decisions — ordinary code is more reliable and cheaper. A model works well where something has to be read, understood, compared or drafted. During discovery we say plainly which steps stay deterministic and which go to the model. Selling you AI where a script would do is a bad deal for us too: projects like that do not work, and we are the ones who end up explaining why.
EVERY REQUEST COSTS MONEY
Building it and running it are two separate bills. The second depends on how many users you have and how large their requests are, and it does not go away once the project is handed over. We work out the cost per request before development and set it against the price you charge, across several growth scenarios. And we build in what brings it down: caching repeats, splitting simple and hard requests between different models, limits and alerts when spending spikes.
THE MODEL CHANGES, THE PRODUCT STAYS
Talking to the model lives in a layer of its own: changing provider, or moving to a local model, does not rewrite the product. This is not future-proofing for its own sake but insurance — over the past two years prices, access terms and the quality leaders have all changed. Plus rules and limits on answers, a journal of every request, and statistics: what people ask, where the model gets it wrong, and what is worth caching.
CATEGORIES
Two levels of scope. Yours is the one you recognise yourself in
FIRST VERSION
WHEN IS THIS YOUR CASE?
What you need is a service that runs and can be shown to users and investors — not everything finished at once. We build the core: the main scenario end to end, accounts and roles, plan limits, control over what the model costs, payments, the admin panel, launch on our servers. The rest is designed into the architecture but not developed, so you can test demand before committing the whole budget.
PRODUCT UNDER LOAD
WHEN IS THIS YOUR CASE?
The service has to stand up to real use from day one: thousands of users, spikes in requests, demands on response time and availability. Queues and load balancing, caching of repeated requests, a fallback model provider in case one fails, local deployment wherever the data must not leave the perimeter. Plus a plan model with limits, API access for your own clients, spend monitoring in real time, documentation and handover to your team.
FAQ
Answers to the most popular questions
From $2.000 for a first working version to $10.000 and up for a product built to take load. The figure depends on the number of scenarios, on whether the model runs through a provider or on your own server, and on what you need from response time and availability. That is why the work starts with discovery — it is part of every project and produces the scheme of the service, an estimate by stage, and the cost per request.
A first working version, 1–3 weeks. A product built to take load, from 3 weeks. For scale: a marketplace with its own CRM, five payment providers and a ticket system took us 40 days. We name the deadline after discovery and hold to it.
Those are two separate bills: building it and running it. Running it comes down to the server plus what the model charges per request — and the second depends on how many users you have and how large their requests are. We work this out during discovery across several growth scenarios, so you can see at what number of users the product starts making money and at what number it starts burning it. If the sums do not add up, better to know before the build.
Almost never. Training from scratch costs more than the whole build and pays off in a handful of cases. Most jobs are covered by an existing model tuned to your data and your rules: it knows your context and answers along your scenarios. If the job genuinely needs a model of its own, we say so during discovery — together with an honest estimate of what that costs.
Whichever clears the bar on both quality and cost per request — that is chosen for the job, not decided in advance. A pair often works out cheaper: a less expensive model handles the simple requests, the harder ones go to a stronger one. We design the architecture so the model can be swapped: the market moves fast, and tying yourself to one provider is a risk rather than a decision.
That is a real risk, and the architecture is what covers it. Talking to the model lives in a layer of its own, so changing provider does not rewrite the product. For critical services we build in a fallback, and where the data is sensitive or the volume is high, a local model on your own server. The dependency cannot be removed entirely, but switching it can be made a matter of days rather than months.
It will get things wrong — the question is what follows. We build in limits on what the service may and may not answer, checks before an answer goes out, and a journal of every request. Where a mistake is expensive, the answer goes to a person for confirmation. We do not build a service that takes irreversible actions unchecked.
Limits per account and per plan, rate limiting, cutting off attempts to use the service for something it is not for, and spend monitoring in real time with an alert on any spike. For an AI product this is not optional: with no limits one user can burn a month of model budget overnight.
You do. The sources, the rights and the documentation are handed over with the project — this is not a subscription to a service of ours and not a tie to us. Model access is registered in your name and the provider bills you directly: we do not resell access and we take no cut per request.
The service can stay on our infrastructure: monitoring, model updates, reworking the scenarios. With AI products the first months almost always go into tuning against the real logs — they show what users actually ask, where the model gets things wrong, and what is worth caching to bring the bill down. How we work after handover is agreed separately: one-off changes, or continuous development with a team assigned to you.