LilyAssist
EdTech SaaS
AIWeb
An AI-powered evaluation platform that helps school psychologists spend less time on reports and more time supporting students.
Learn More All services
AI products that hold up in front of real customers
We find the use case worth a model, prove it on your own data, and ship it with the rules that matter enforced in code - so it answers, books and hands over to a person correctly when a real customer is on the other end.
You are probably here because
- You have an AI idea and no clear read on whether it is worth building
- You have a prototype that demos well and breaks in front of real users
- You need an assistant that acts on real data - a calendar, a schedule, a customer record - not one that only talks
- You have a quote for an AI build and want to know what you are actually buying
What decides whether it works
An AI feature is easy to demo and hard to trust. The demo runs on a clean example. Production runs on the message nobody planned for, in front of a paying customer.
What decides whether it works is engineering, not prompting: what the assistant may do on its own, where it stops, who sees its output first, and what each conversation costs. We answer those before we build, not after the first complaint.
We have done this
All case studies
Connexa
AI Networking App
iOSAndroid
iOS
AndroidA relationship intelligence app that preserves the context behind every professional connection.
Learn More
Appointexo
AI SaaS
AIWebTelegram
An AI receptionist for appointment-based businesses, living inside the chat app their clients already use.
Learn More
GataTot
Conversational AI
AIWhatsAppWeb
An AI concierge on WhatsApp that turns a few plain words into a job a tradesperson can price.
Learn MoreWhat the work covers
Included
- Use-case discovery: which problem is worth a model, and which is better solved by a form
- A working pilot on your real data, not a scripted demo
- Success criteria agreed before the build and measured after it
- The assistant itself: the tools it can call, the data it can read, the actions it can take
- Guardrails in code - what it must never say, send or decide on its own
- A handover to a person, and clear rules for when it happens
- Evaluation: scripted conversations replayed on every prompt, tool or model change
- Integration with the systems the answers have to come from
- Deployment, monitoring, and cost per conversation as a tracked number
Not included
- Training foundation models from scratch - we build on existing commercial and open-source models
- A chat box on a product that has nothing worth asking it
- A promise that the model will never make a mistake - we design for safe mistakes instead
“Yurii and his team are incredible! Every step of the way, from ideation to MVP to a full-featured product with ongoing technical support, has been excellent.”
Rebecca Branstetter, Ph.D.
School Psychologist & CEO, The Thriving Students Collective
How the work runs
The same four steps we use on everything, in this service’s terms.
1
Observe
Find the use case worth building
We look at where the work actually goes and which part of it a model can carry. Sometimes a form and a rule would be faster, cheaper and more reliable - and we say so before you have spent anything.
2
Plan
Decide what it may and may not do
An assistant is defined by a list of actions, not a personality. We write down what it can call, what it can read, what it must hand to a person, and what has to be enforced outside the model. That list is the spec.
3
Uncover
Build the pilot and measure it
A working pilot on your data, with an evaluation harness beside it: scripted conversations replayed on every change, reporting cost and latency per message. A prompt change stops being a guess.
4
Ship
Launch with the guardrails on
The handover to a person works, the guardrails hold, someone reviews the output where it matters, and the running cost is visible. From there it improves on real usage, not on opinion.
What it costs
Typical bands rather than a quote. The number moves with scope, and we would rather you knew the range before the call than after it.
2-4 weeks
AI Pilot
$9.5k - $25k
One use case, proven or disproven, with the findings either way.
6-10 weeks
MVP Sprint
$25k - $80k
The pilot becomes a product real users can reach.
Ongoing
Product Partner
Custom
Your long-term product team after launch - roadmap, releases and continuous improvement.
Questions we get asked
Do we own the code, the prompts and the evaluation sets?
Yes, all of it, from the first commit rather than at handover. The code lives in your repositories, on your accounts. That includes the parts people forget to ask about: the prompts, the scripted conversations we test against, the architecture notes and the deployment configuration. Nothing runs on infrastructure with our name on it, and there is nothing you would have to license from us later. If you move the project to another team or in-house, they get a working system and the documentation to keep it running.
Which AI models do you use, and how much does it cost to run?
Whichever model fits the job - commercial or open-source, from any provider - chosen for the use case and named in writing before we build. An evaluation harness measures tokens, latency and cost per message, so the running cost is a tracked number rather than a surprise on the first invoice. Those numbers change decisions: on one product, a newer model wrote noticeably better replies but measured slower and no cheaper on real conversations, so the existing one stayed. You see the same numbers we do, and the model can be swapped later without rebuilding the product.
What happens when the assistant gets something wrong?
It is built to be wrong safely, because never being wrong is not on offer from any model. Anything that must hold is enforced in code, not asked of the model: contact details stripped before they can leak, permissions checked outside the conversation, actions limited to a fixed set of tools. There is also a defined point where the assistant stops and hands the conversation to a person, with written rules for when that happens. Being corrected by the customer is part of the flow, not an error.
Can you work within our data privacy constraints?
Yes. The constraints shape the architecture from the start, which is the difference between a system that passes review and one that gets rebuilt. We have built an education product to HIPAA and FERPA practice, where district requirements drove the design, and an EU product under GDPR with consent collected before any measurement runs. The practical questions come first: what data the model may see, where it is stored, how long it is kept, and who can read it afterwards.
What if the pilot shows the idea does not work?
Then the pilot did its job, at a fraction of what a full build would have cost to learn the same thing. A pilot is scoped to answer one question, and a clear no is a useful answer. You keep the findings, the working code, the evidence behind the conclusion and a recommendation on what to do instead. We would rather tell you in week three that a form and a rule beat a model here than sell you the larger engagement. That is why the pilot is a separate step.