Add AI to the app you already have. About three weeks. No rewrite.
Assistants, smart search, document and image scanning, voice and recommendations, built into your live iOS or Android app, in the codebase you already have. Swift, Kotlin, Flutter or React Native. You get a written plan with the feature, the cost to run it every month and the store and EU disclosure work, before anyone writes code.
Your app already works and already has users. That is the hard part, and it is done. Adding AI to it should not mean rebuilding it. We work inside the codebase you have, Swift, Kotlin, Flutter or React Native, and ship one working AI feature in about three weeks, behind a switch you control, so you can turn it on for a small group of users first and off again in a second if you do not like what you see. Before any of that, you get a written plan: which feature, why that one, what it will cost to run every month, what happens when it is wrong, and what Apple, Google and the EU now require you to tell your users. Most of our work is not the model. It is the twenty decisions around the model that make the difference between a feature people use and a chat bubble people close.
Why people call us
You are the one who is liable, not the model vendor. A tribunal has already held a company responsible for what its chatbot told a customer.
You can price a build. Nobody will tell you what the bill looks like in month seven, when the feature is popular.
Since November 2025 this stopped being a worry and became a review gate. Developers are being rejected on it now.
You have seen competitors ship AI that nobody uses. You do not want to spend three weeks proving that again.
Who you’ll actually work with
I have been building mobile apps for seven years and shipped more than fifty of them. When clients ask me for AI now, my first job is usually to talk them out of the version they arrived with, not because AI does not work, but because the feature they picked was picked from a competitor’s app instead of from their own users. So I ask what your users do by hand today inside your app. If there is a real answer, AI is worth your money and I will tell you exactly what it will cost to run. If there is not, I will say so, and you will have spent nothing. I read every enquiry that comes through this page myself.
What you actually receive
| You get | What it actually is | When |
|---|---|---|
| AI feature plan | A written document, 6 to 10 pages. The feature, why that one and not the other six, where it sits in your app, the model we picked and why, the monthly cost with the arithmetic shown, what happens when it fails, and the disclosure work Apple, Google and the EU require. | End of week 1 |
| Working feature in your app | Merged into your branch, behind a feature flag you control. Not a demo, not a prototype in a separate app. Your build, your store listing, your users. | End of week 3 |
| The test set | 40 to 80 real questions or documents from your own product, with the right answer written next to each, and the score the feature got. This is how you know it works, and how you will know if it stops working. | End of week 3 |
| Monthly cost model | A spreadsheet, not a sentence. Cost per user per month at three levels of usage, with the cap we set and who can raise it. | End of week 1, updated at launch |
| Store and EU disclosure pack | Consent screen copy, privacy-label changes, App Review notes, and the Article 50 AI-disclosure text your app needs to show. Written for you to paste. | End of week 2 |
| Fallback behaviour, specified | Exactly what your app shows when the model is slow, offline, unsure or wrong. Written down and built, not left to chance. | End of week 2 |
| Handover note and the repo | Everything in your repository from day one. Prompts, test set and cost model in plain files, not locked in a tool of ours. | Throughout |
See a real one. Sample deliverable needed
An actual plan we handed a client, with their name taken out. This is what you get at the end of week one.
What you can add
Every AI feature costs roughly what it touches. One that reads is cheap. One that understands your documents is more. One that acts on a user’s behalf is the most, because it needs the most care. So the menu is grouped that way rather than feature by feature.
Nothing new is stored, nothing is decided. The feature reads what already exists and gives it back in a more useful shape.
Smart search. Your users type what they mean instead of the exact word you named the thing.
Summarisation. Long threads, documents, transcripts or histories, made short.
Voice input and commands. Talking instead of typing, for the screens where typing is the friction.
Good first move if you have never shipped an AI feature. Lowest running cost of the three, and the easiest to turn off if your users shrug.
The feature works from your content and your documents, and holds a conversation about them.
In-app assistant. Answers from your help centre, your product content, your policies. If the answer is not in your sources, it says so and offers a person.
Document and image scanning (OCR). Invoices, IDs, contracts, receipts, forms. Photograph it, get structured data back into your existing fields.
This is the band most apps should be in. It is where the measurable business change usually is: fewer support tickets, faster onboarding, less typing.
The feature does something on the user's behalf. Books, files, updates, sends. More value, more care, more testing.
Personalisation and recommendations. What each user sees, ordered by what they actually do.
Agents that take action. Multi-step work inside your app, with limits you set and a record of every step.
We will not sell you this band first. If your app has never had an AI feature, we will put you in Band 1 or 2 and come back to this once we can see how your users behave with it.
Not sure which band? Start with the AI Readiness Audit, a fixed-price week where we look at your app, your content and your users and tell you which feature is worth building, which one is not, and what it will cost to run. Fee: Fee needed, and it comes off the build if you go ahead. If we tell you not to build anything, you keep the document and owe nothing further.
Get your AI feature planInside an assistant
Most people picture a chat box. The chat box is about five per cent of the work. Here is the rest, because the rest is what decides whether your users keep it open.
It reads your help centre, your product content, your policies, your catalogue, whatever you point it at. It does not answer from general knowledge, and when the answer is genuinely not in your sources it says so and offers a person instead of guessing. That single behaviour is the difference between an assistant and a liability.
Before we build, we write down what it must never do: no prices it has not been given, no promises about refunds or delivery, no legal or medical opinions, no commitments made on your behalf. Those limits are code and tests, not a paragraph in a prompt that a clever user can talk it out of.
When a user is angry, when the same question comes back a third time, or when the assistant is not confident, it stops and passes over, carrying the conversation with it, so your person does not start with “hi, how can I help?” to someone who has already explained themselves twice.
You can read what your users actually asked. This is worth more than the feature. Within a month you will know what your product is missing, in your customers' own words, at a level of detail no survey will ever give you.
Inside the app first, because that is what this page is about. The same assistant can also sit on your website, on WhatsApp, or inside your team’s own tools. One set of sources, one set of limits, several front doors. If the team-facing version is the one you actually want, that is AI Agents & Business Automation.
Once a month we read the real conversations, find where it did badly, add those to the test set and fix them. An assistant that is never reviewed after launch does not stay still. It quietly drifts as your product changes around it.
AI inside the product
The features that stick answer one question well and hand back to a person the moment they are unsure. The sections below are about building that kind and pricing it honestly.
When it’s wrong
Any honest answer to “will it make things up” starts with yes, sometimes. What separates a safe feature from a dangerous one is not the model. It is what the app does in the moment it is wrong. This is where we spend most of week two.
The five things we build every time
It answers only from your sources. If the answer is not there, it says it does not know. It is not permitted to fill the gap.
It shows its working. Wherever it makes sense, the answer carries a link to the page it came from, so a user can check it in one tap and you can trace any complaint.
It has a hard “do not answer” list. Money, legal, medical, promises. Written down before we build, tested like any other feature.
It fails to something useful. When the model is slow, down or unsure, your users do not see a spinner or an error. They see the search results, the help article, or a way to reach a person. We specify this before we build it, and you sign it off.
We grade it before you ship it. 40 to 80 real questions from your product, right answers written next to them, scored. You see the score. You also see the ones it got wrong, and you decide whether that is good enough to launch.
Plain answer: what your users type into the feature is not used to train anybody’s model.
We use business API tiers, not consumer products. OpenAI’s own policy states: “By default, we do not use your business data for training our models.” API inputs and outputs are retained for a limited period for abuse monitoring, up to 30 days, and zero-data-retention is available on eligible endpoints.
Where your data is sensitive enough that “up to 30 days” is still too long, we say so and move the feature on-device, where nothing leaves the phone at all. See What it costs to run.
One honest caveat, because you will not hear it from most agencies: a vendor’s retention policy is a policy, not physics. During the New York Times litigation OpenAI was ordered by a court to preserve output data beyond its own stated policy. Court orders beat privacy pages. If your data is that sensitive, on-device is not a nice-to-have. It is the requirement, and we will tell you that before you sign anything.
What it costs to run
Most agencies will not put this on a page, because the honest answer is “it depends”. So here is the arithmetic instead of the answer.
Not how many users you have. The share who open the feature, and how often, is the number that matters, and it is the one nobody estimates correctly first time.
An answer that has to search a 400-page manual costs more than one that reads a paragraph. This is a design decision, and we make it deliberately.
The spread between the cheapest and the most expensive model is more than a hundredfold. Almost no product needs the most expensive model for every request.
USD per million tokens, input / output, list price from each vendor’s own page.
| Vendor | Model | Input | Output | Source |
|---|---|---|---|---|
| OpenAI | gpt-5.6-sol | $5.00 | $30.00 | pricing |
| OpenAI | gpt-5.6-terra | $2.00 | $12.00 | pricing |
| OpenAI | gpt-5.6-luna | $0.20 | $1.20 | pricing |
| OpenAI | gpt-5-nano | $0.05 | $0.40 | pricing |
| Anthropic | Claude Opus 5 | $5.00 | $25.00 | pricing |
| Anthropic | Claude Sonnet 5 | $2.00 | $10.00, introductory, through 31 Aug 2026; $3.00 / $15.00 from 1 Sep 2026 | pricing |
| Anthropic | Claude Haiku 4.5 | $1.00 | $5.00 | pricing |
| Gemini 3.1 Pro (preview) | $2.00 | $12.00 | pricing | |
| Gemini 3.6 Flash | $1.50 | $7.50 | pricing | |
| Gemini 2.5 Flash-Lite | $0.10 | $0.40 | pricing |
Checked 10 August 2026. We re-check this table every quarter. Next check: November 2026. Prices move, and one of them moves on 1 September 2026. That is precisely why we build so you can change model without changing your app.
We size it before we build it. Cost per user per month at three levels of usage, in a spreadsheet, at the end of week one.
We cache the repeated parts. Most of what an assistant reads is the same every time. Cached reads are charged at a fraction of the normal rate.
We route by difficulty. Easy requests go to a cheap model. Only the genuinely hard ones go to the expensive one. This is usually the single biggest saving available.
We batch what can wait. Work that does not need an instant answer runs at roughly half price.
You get a hard cap. A monthly ceiling you control, with an alert well before it. Nobody at our end can raise it. Default cap needed
We tell you in month one if the estimate was wrong. Not in month six.
For a real set of features, nothing has to leave the device at all. No per-request fee, works with no signal, and your users’ data never travels.
Apple’s Foundation Models framework runs a model on the device from Swift. Apple’s Core AI is marketed on exactly this basis: “zero server dependencies and zero token costs.”
Apple Small Business Program members with under 2 million lifetime first-time downloads get free access to the latest Foundation Model on Private Cloud Compute — a genuine zero-inference-cost path almost nobody is using yet.
ML Kit’s GenAI APIs run on Gemini Nano through AICore: summarising, proofreading, rewriting, image description, speech recognition. On-device, no per-request fee.
Core ML and TensorFlow Lite / LiteRT for classification, detection and scanning work that does not need a language model at all. Often the right answer, and rarely the one proposed.
One thing on-device does not buy you: it does not exempt you from telling users they are talking to an AI. The EU disclosure duty applies wherever the model runs. See The dates you can’t miss.
The dates you can’t miss
Our standards
The code is in your repository from day one. The prompts, the test set we grade answers against, the cost model and the integration plan are all yours and all in plain files, not locked inside a tool of ours, not a platform you have to keep paying us for. The model is a setting, not a marriage: we build behind one interface, so moving from one provider to another is a config change and a re-run of the test set, not a rebuild. That matters more than it used to. Claude Sonnet 5 is priced at $2 / $10 per million tokens as an introductory rate through 31 August 2026 and goes to $3 / $15 on 1 September. Prices move. Your app should be able to move with them.
An MIT NANDA study found that around 95% of enterprise generative AI pilots produced no measurable return. We sell AI features, so that number costs us money to print. We print it because the projects that fail nearly all fail the same way: the feature was chosen because AI was available, not because a user was stuck.
So here is what we look for before we agree to build. We publish it now, before we have seen your app, so you can hold us to it later.
A job your users already do by hand, inside your app. Not a job you imagine they might want done. Something you can watch them doing today.
Content of your own that is good enough to answer from. If your help centre is thin or out of date, the assistant will be thin and out of date. Fixing the content usually beats adding the AI, and we will say so.
A way to tell right from wrong once it ships. If nobody can look at an answer and say whether it was correct, we cannot grade it, you cannot improve it, and you will never know if it broke.
Something sensible for the app to do when the model is unavailable or wrong. If the honest answer is “the screen is useless without it”, that is a much bigger decision than a three-week feature.
Miss two of those four and we will tell you to spend the money on something else. That conversation is free, and it happens before you pay us anything.
The reason this page exists is that AI Integration grew 178% in client spending on Upwork, their In-Demand Skills 2026 report, published February 2026. It is a real number and we are not going to pretend otherwise. But it measures freelance-platform spending in 2025 against 2024, not what app owners budgeted, and the same body of Upwork research shows the other half of the story: commodity generative work saw +90% more contracts started but 13% lower earnings per contract, while AI-augmented professional services grew 72% in volume. Demand is real. The easy end of it is being commoditised fast. That is exactly why we sell the judgement around the model rather than the model.
Fixed scope, fixed duration, one feature at a time. We do not open-end this work.
Behind a feature flag from day one. Turn it on for 5% of users. Turn it off in a second.
Your existing stack, your existing patterns. We match the codebase we find. An AI feature that looks foreign inside your app is a maintenance problem we handed you.
Everything in writing before it is in code. The plan comes at the end of week one and you can stop there.
We say no. If the honest answer is that AI does not belong in your product yet, you will hear it from Anand directly.
Industries
| Industry | The AI feature that earns its money here | Our proof |
|---|---|---|
| Fintech & Banking | Document and ID scanning in onboarding; assistants that answer from your own policy documents rather than guessing | Hindustan Loan · Fidex Wallet · QuickChain |
| Legal-Tech | Summarising long documents; smart search across matters; strict “do not answer” limits, which matter more here than anywhere | DigitsLaw · ActivePass |
| CRM, HR & Internal Business Tools | AI inside the tool your own team uses all day. The fastest place to see a result, because you can measure the hours | PTB Admin Panel · PM Fund Manager · FMSoft CRM |
| Retail, POS & E-commerce | Recommendations; search that understands what a customer meant; receipt and invoice scanning | Vencru POS |
| Real Estate & PropTech | Scanning documents at the point of sale; assistants that answer from listings and policy | Tata Power Solaroof |
| Logistics & Field Operations | On-device scanning and voice input where there is no signal. The case for on-device AI is strongest here | Field-operations app for a client we do not name |
| Energy & Utilities | Assistants inside field apps; automatic reading of installation and asset documents | Tata Power Solaroof |
| Events, Media & Community | Recommendations; summarising long threads; AI inside the publishing tool rather than the reader's app | Pray The Bible · Virtue Insight |
| EdTech & Training | Summarising material; voice input; personalised sequencing | No claim made |
| Healthcare & Wellness | Structured intake, document scanning, strict limits on anything that resembles advice | We have no healthcare case study yet. We will tell you that on the first call rather than after you have signed |
How the work runs
We look at what you already have
Your repository, your app in the stores, your content, your analytics. We find out what your users actually do today, what your backend can already give an AI feature, and what will break if we touch it. If the backend is not ready, we tell you now. That is Backend, API & Integrations, and it comes first.
We pick the feature, and argue about it
Against the four criteria in Our standards, out loud, with you. This is where we say no if no is the right answer. Most clients arrive wanting Band 3 and leave happier in Band 2.
You get the plan
The written document: the feature, the model and why, where it sits in the app, the monthly cost with the arithmetic shown, the failure behaviour, and the store and EU disclosure work. You can stop here. The plan is yours either way.
We build it into your app
In your branch, in your stack, behind a feature flag. Not a demo in a separate project. Daily progress you can see.
We build the failure behaviour and the disclosures
What the app does when the model is slow, offline, unsure or wrong. The AI-disclosure text, the Apple consent screen, the privacy-label changes, the App Review notes.
We grade it against real questions
40 to 80 real questions or documents from your own product with the right answers written next to them. You see the score and the failures. You decide whether it is good enough to launch.
We ship it, and turn it on slowly
Store submission with the review notes prepared. Live to a small share of users first, watched, then widened. Cost dashboard and cap active from the first day.
Then, if you want it: once a month we read the real conversations, add the bad ones to the test set, and fix them. That is Mobile App Maintenance & Optimization and it is a separate, cancel-anytime arrangement.
Working together
We look at your app, your content and your users, and tell you which AI feature is worth building, which is not, and what it will cost to run every month. You get the written plan. Fee: Fee needed, credited against the build if you go ahead. If our answer is “don’t build anything”, you keep the document and owe nothing further.
The most common way to start. One feature, one price, one date, one flag. See What you can add.
You have developers; you do not have anyone who has shipped an AI feature into a live app before. We work inside your process, in your repository, at your standup.
Conversations reviewed, test set grown, costs watched, models swapped when prices or quality move. The version of this that includes the rest of your app is Mobile App Maintenance & Optimization.
No minimum contract size. We judge each project on whether we can do it well, not on what it is worth. We have run one-month engagements and multi-year ones, and we prefer long ones, but we have never required one.
How you get a quote. Send the form. Anand reads it and replies with either a number and a date, or the two questions he needs answered before he can give you one. No call is required to get a price. If a call helps, book twenty minutes.
Get your AI feature planI have worked with a lot of freelancers in the past, and Anand is by far one the best… delivered a pixel-perfect output
Their technical expertise ensured seamless updates, and their proactive communication kept me informed throughout.
Tasks were handled thoughtfully, with good attention to detail and a willingness to ask questions when clarification was needed.
Tech we use
If your app needs something not on this list, we bring in a specialist we have worked with before and we manage the delivery. You still have one team and one point of contact.
Questions
It works with what you have. We build inside your codebase, Swift, Kotlin, Flutter or React Native, and merge into your branch behind a feature flag. If we find a reason a rebuild would be cheaper than an integration, we will tell you in week one and you can stop there with the plan in hand.
Sometimes it will be wrong. Anyone who tells you otherwise is selling. What matters is what your app does at that moment. It answers only from your sources, it says “I don’t know” instead of guessing, it links to where the answer came from, it has a written list of things it must never discuss, and it hands over to a person. We grade it against 40 to 80 real questions from your product before you launch and you see the score. Details in When it’s wrong.
It depends on how many of your users touch it, how much reading each answer needs, and which model answers, so we model all three before we build and give you a spreadsheet, not a sentence. For shape: Anthropic’s own documentation prices 10,000 support conversations at roughly 3,700 tokens each at about $37 on Claude Haiku 4.5. You also get a hard monthly cap that only you can raise. The full arithmetic and the current published prices are in What it costs to run.
Not without you agreeing to it. The cap is set at launch, you get an alert well before it, and nobody at our end can raise it. If the feature is more popular than we modelled, that is a conversation about a good problem, not a surprise invoice.
No. We use business API tiers. OpenAI's policy states plainly that by default they do not use business data to train models. Data may be retained for a limited abuse-monitoring window, up to 30 days, and zero-retention options exist on eligible endpoints. If that window is still too long for your data, we move the feature on-device, where nothing leaves the phone at all. We also say the uncomfortable part out loud: a retention policy is a policy, and a court can override it, so for genuinely sensitive data, on-device is the requirement, not the upgrade.
Yes, if you reach anyone in the EU. Article 50(1) of the EU AI Act applied from 2 August 2026 and requires you to tell people they are interacting with an AI. The four-month transition running to around 2 December 2026 covers marking AI-generated content, not the disclosure itself, so if you have been told you have until December, that is the wrong half. Several US states have their own versions. We build the disclosure in and hand you the text. The full dated table is in The dates you can’t miss.
It is a real risk and it is now a review gate rather than a worry. Since 13 November 2025, Apple's guideline 5.1.2(i) requires you to disclose that personal data is going to a third party, including a third-party AI service, and to get explicit permission first. Google clarified on 15 July 2026 that the Play User Data policy covers third-party AI integrations too. Every feature we ship comes with the consent screen, the privacy-label changes and the App Review notes prepared.
Often, yes. On-device models, Apple's Foundation Models framework on iOS, ML Kit GenAI on Gemini Nano on Android, plus Core ML and TensorFlow Lite for scanning and classification, run with no signal and cost nothing per request. Not every feature can run this way, but more can than most people assume, and we will tell you which parts of yours can.
Two weeks for a Band 1 feature, three for Band 2, four for Band 3, from go-ahead. The written plan arrives at the end of week one either way, and you can stop there.
Then you turn it off. It is behind a flag from day one, and you launch it to a small share of users first exactly so you find that out cheaply. This is also why we argue about the feature choice in week one against four published criteria, and why we will tell you not to build it if it fails two of them. See Our standards.
You own all of it, from day one, in your repository. Prompts, test set and cost model in plain files. The model provider is a setting behind one interface, so switching from one to another is a config change and a re-run of the test set. You can take everything to another team tomorrow.
Yes. That is most of this work. If the app is also unstable or nobody understands the code, do App Rescue & Code Audit first. Putting an AI feature on top of a codebase that already crashes just gives the crash a new name.
That is what the AI Readiness Audit is for. One fixed-price week, you get the written plan, and the fee comes off the build if you go ahead. If the honest answer is that AI does not belong in your product yet, we will say so and you will owe nothing further.
Anand reads every enquiry from this page himself and leads the plan. Our team builds it. Where a project needs something outside our daily stack, we bring in a specialist we have worked with before and we manage the delivery. You still have one team and one point of contact. Meet Anand →
A short call, an honest answer on whether we are the right team, and a scope you can hold us to.
Start a project
