Do you build the whole product, or just the AI parts?

The whole product: the app, the backend, the AI integration, the monitoring and the store submission. I work with existing teams too, in which case I own the AI system and its operational plumbing and integrate with what you have.

Both. My shipped iOS apps are native, and the platforms behind them are web applications. Which one you need first is a product question we answer together, and the honest answer is often 'the web version, then the app, once you know people want it'.

How do you keep AI costs under control in a product?

Every model call carries a cost and latency budget, spend is measured per user and per feature, and the product is designed to degrade gracefully rather than run over. You see the numbers from the first week of real traffic, not from the first surprising invoice.

Can you take over a product someone else started?

Often, yes — starting with a review of what exists, what it costs, and where it will fail. Sometimes the right call is to keep it and add the missing operational layer; sometimes it is to rebuild the core. You get that recommendation in writing before any rebuild is proposed.

What happens after launch?

The product is monitored, so failures are visible. Beyond that we agree a support arrangement that fits you — some clients want a retainer, some want to hand it to their own developers with a runbook. Both are fine; the code is written to be handed over either way.

You need the product itself shipped, not a proof of concept.

AI product development

Production apps and web products with AI at the core, shipped to real users and real app stores — with the operational plumbing that keeps them alive after launch.

The situation

A proof of concept proves the model can do the thing. It does not prove that the product survives a real user, a real bill, a real app store review, or a real month of running unattended. Businesses that want the product itself shipped are hiring for the second problem, and it is a different job.

I build production applications with AI at the core — iOS and web — and I take them all the way to users, including App Store submission and the operational plumbing that keeps them alive afterwards. Seven of my own iOS apps are live on the App Store today, and the web platforms behind them run in production.

How I approach it

Scope to a product, not a feature list

The first conversation is about who uses this, what they do with it in the first sixty seconds, and what has to be true for them to come back. AI is a means to that, not the point of it. A product that leans on a model for one well-chosen job beats one that sprinkles AI on every screen and asks the user to be impressed.

LLM integration with a budget on both axes

Every model call in a product I ship has a cost budget and a latency budget. The product degrades gracefully when either is exceeded — a cached answer, a simpler path, an honest message — instead of hanging or quietly running up a bill. Model choice is made per job, not per fashion; a cheaper model that answers in under a second often beats a smarter one that does not.

Retrieval and evaluation, so it is right about your data

Where the product has to know your content — your documents, your catalogue, your history — I build the retrieval pipeline that grounds the model in it, and the evaluation set that tells us whether it is actually answering correctly. Without an evaluation set, 'it seems better' is the only quality metric you will ever have.

App Store submission included

Shipping to iOS means privacy manifests, review guidelines, screenshots, metadata and the rejection you get anyway. I have done this seven times for my own apps. It is part of the delivery, not a surprise at the end.

Monitoring from day one

I once had a production system die and go unnoticed for 25 days because its errors went to a log nobody read. Everything I ship now heartbeats, and a missed heartbeat pages someone. You will not learn about an outage from a customer.

What gets delivered

iOS and web applications, App Store submission included
LLM integration with cost and latency budgets
Retrieval and evaluation pipelines
Monitoring, so a silent failure does not go unnoticed for weeks

What it costs to get wrong

A demo that works on the founder's laptop and falls over on the first real data set, with no evaluation to show why.
Per-user AI costs nobody modelled, discovered when the product starts to succeed.
An App Store rejection three weeks before launch for something — privacy declarations, a required permission string — that should have been handled in week one.
A silent failure that runs for weeks, because the system was built to work rather than built to be watched.

Why you can believe this

Seven iOS apps shipped to the App Store, plus the production web platforms behind them. The monitoring point is not theoretical: I once had a system die and go unnoticed for 25 days because its errors went to a log nobody read. Everything I build now heartbeats.

Explore the work Read the ai-os case study

Live on the App Store

Questions buyers ask

Do you build the whole product, or just the AI parts?: The whole product: the app, the backend, the AI integration, the monitoring and the store submission. I work with existing teams too, in which case I own the AI system and its operational plumbing and integrate with what you have.
iOS, web, or both?: Both. My shipped iOS apps are native, and the platforms behind them are web applications. Which one you need first is a product question we answer together, and the honest answer is often 'the web version, then the app, once you know people want it'.
How do you keep AI costs under control in a product?: Every model call carries a cost and latency budget, spend is measured per user and per feature, and the product is designed to degrade gracefully rather than run over. You see the numbers from the first week of real traffic, not from the first surprising invoice.
Can you take over a product someone else started?: Often, yes — starting with a review of what exists, what it costs, and where it will fail. Sometimes the right call is to keep it and add the missing operational layer; sometimes it is to rebuild the core. You get that recommendation in writing before any rebuild is proposed.
What happens after launch?: The product is monitored, so failures are visible. Beyond that we agree a support arrangement that fits you — some clients want a retainer, some want to hand it to their own developers with a runbook. Both are fine; the code is written to be handed over either way.