AI-powered apps
Chat assistants, document intelligence, OCR, and on-device ML — scoped honestly, built to run at a cost your business can live with.
An AI demo takes an afternoon. An AI feature that runs every day, for every user, at a cost you can defend and a failure rate you can live with, is a different piece of engineering — and it is mostly not about the model. It is about what happens when the model is slow, wrong, unavailable, or expensive.
So we scope AI features by what they replace. If a person currently retypes numbers from a photograph, document intelligence has an obvious floor and an obvious payoff. If the answer is "customers will love chatting with it", we would rather find that out in a week than build for three months on it.
Most of this work lands inside products that already exist — an existing Flutter or Android app, or a web application and its backend — whether or not we built the original. Adding AI is usually an integration problem, and integration problems live in someone else's codebase.
Our published case studies cover web and mobile builds rather than AI features specifically — so rather than dress one up, here is the honest route in.
Where it pays
Telling a client an AI feature is not worth building is a normal outcome of a scoping call, and cheaper for everyone than discovering it in month three.
Capabilities
Three distinct engineering problems that get grouped under one word.
Chat, assistants, summarisation, and structured extraction. The engineering is in the scaffolding: grounding answers in your data so the model is not guessing, constraining output to a shape your code can parse, handling refusals and timeouts as normal states, and keeping prompts in version control where they can be reviewed like any other logic.
Receipts, invoices, forms, and identity documents. Text recognition is the easy half; the hard half is turning a page of characters into the specific fields your system needs, knowing when a scan is too poor to trust, and routing low-confidence results to a human instead of silently writing bad data.
Vision, OCR, and speech running on the handset. Nothing leaves the device, there is no per-request cost, and it works on a plane. Where a task fits an on-device model, this is almost always the better answer — cheaper, more private, and faster than a network round trip.
Engagement
Short loops, early evidence, and a decision point before the expensive part.
Which task, done by whom today, and what "good enough" means as a number. A feature without a success threshold cannot be finished.
The narrowest version that touches real data — your documents, your questions, your edge cases. Days, not sprints.
Run it against a held-back set and count the failures. This is the honest decision point: build, reshape, or stop.
Wire it into the product with the unglamorous parts — caching, rate limits, fallbacks, and a path for when the model is unavailable.
Log inputs, outputs, cost, and latency from day one, so quality and spend are things you can see rather than infer.
The evaluation step is the one most AI projects skip, and the reason so many arrive in production with no agreed definition of working. We would rather spend a week proving a feature is a bad idea than a quarter proving it slowly — which is the same bias toward early bad news described on our about page.
Per-request pricing means a feature's cost scales with success, which is a strange thing to discover after launch. We design against it: on-device inference where a task allows it, caching for repeated questions, prompt and context discipline because tokens are the bill, cheaper models for the many easy cases with escalation reserved for the hard ones, and rate limits that cap the worst day rather than trusting the average. You see a projected running cost before the build, based on your own expected volumes.
The first question is whether the data needs to leave the device at all. Where on-device processing covers the task, it is the default — no third party involved, nothing to review. Where a hosted model is genuinely needed, we go through it with you explicitly: what is sent, what the provider's terms say about retention and training, what can be redacted or tokenised first, and what your own users are told. Sensitive fields are stripped before they travel where the feature still works without them.
A hosted model is a third-party service that will occasionally be slow, rate-limited, or down, and unlike most dependencies it can also return confident nonsense. So AI paths are built to degrade: timeouts and retries with backoff, a defined behaviour when the call fails, output validated against an expected shape before anything acts on it, and confidence thresholds that route uncertain results to a person. The product should get less capable when the model is unavailable, not broken.
Model choice is a decision that ages badly, so integrations are written behind an interface rather than sprinkled through the codebase. Swapping providers, or moving a task on-device once a smaller model becomes good enough, should be a contained change — not a rewrite. Prompts and evaluation sets are yours and stay portable.
FAQ
Mostly Google's Gemini API for language features, and ML Kit or TensorFlow Lite for on-device vision, OCR, and speech. The choice is made per feature against quality, latency, privacy, and running cost rather than fixed in advance — and integrations are written so a provider can be changed later without a rewrite.
They can be, if built naively, because per-request pricing means cost scales with usage. We design around it: on-device inference where possible, caching, prompt and context discipline, cheaper models for easy cases, and rate limits. You see projected running costs against your own expected volumes before the build starts.
Yes — it is our most common AI engagement. We integrate into your current web or mobile codebase whether or not we originally built it, starting with a read of how your data is stored and what the feature would actually need to reach.
The first question is whether data needs to leave the device at all; where on-device processing covers the task, that is the default. Where a hosted model is needed we review explicitly what is sent, what the provider's terms say about retention and training, and what can be redacted or tokenised first.
It is turning documents — receipts, invoices, forms — into structured fields your system can use. Accuracy depends heavily on document quality and layout consistency, so rather than quote a number we measure it on your actual documents during evaluation and design a human review path for low-confidence results.
No data leaves the handset, there is no per-request cost, and it works without a connection. The trade-off is capability: on-device models are smaller and narrower. Where a task fits one, it is usually the better engineering answer on every axis that matters.
It will, sometimes, so the product is designed for it. Output is validated against an expected shape before anything acts on it, confidence thresholds route uncertain cases to a person, and failure behaviour is defined rather than accidental. Features where a wrong answer is unacceptable and nobody reviews the output are ones we advise against building.
Usually we will talk you out of it. Grounding a capable general model in your data through retrieval, or fine-tuning a small on-device model for a narrow task, solves most business problems faster and cheaper. Training from scratch is a research budget, and if that is genuinely what you need we will say so rather than take the work.
We agree what "good enough" means as a number before building, then evaluate against a held-back set of real examples. That produces a decision point — build, reshape, or stop — before the expensive integration work. Cost, latency, and quality stay instrumented after launch.
Yes, and it is a good use of a scoping call. Often the outcome is that one narrow workflow is worth automating and three others are not — which is a cheaper answer to receive early than late.
Next step
Tell us about your product. You'll get a straight answer on approach, timeline, and cost — usually within 24 hours.
