Home > Product Work > AI product, end to end
AI product, end to end
Founder & Product Builder
StayKeel turns any link into a structured summary and lets you ask questions across everything you saved, in any language. I did the research, chose the models by measurement, designed the system and the interface, and run it in production.
One action, three models, and code where code is enough
The product looks simple on purpose. You share a link from your phone or paste it on your computer; a minute later there is a card with a short, medium or full summary in the language of the content. Later you can ask a question and get an answer built only from your own archive, with every source cited.
Behind that one action sits a pipeline where three models of different size each do the step where they cost least and perform best, and plain code takes the decisions that don't need a model. I don't hand everything to the biggest model. Every choice in that pipeline was made by measuring, not by preference.
The Challenge
My Role
Everything, from research to production
- User research with alpha testers across devices and levels of digital comfort.
- Product decisions and backlog, prioritised with MoSCoW and WSJF.
- Model evaluation: criteria, blind benchmarks, cost measurement.
- Design system, brand system and interface.
- Front end, deploy, security and QA, with user isolation proven by tests.
Scope
- Sources: web articles, videos, public reels, LinkedIn posts, code repositories, PDFs
- Input from phone share sheet, desktop, and an optional messaging bot
- Any language in, the same language out; questions answered in the language you ask
- Progressive Web App, no store, no download
- Free beta, paid subscription later
Approach
Each decision either removes a step for the user, or removes a cost for the system.
One action, not a workflow
The user does one thing: share a link. Parsing, cleaning, summarising, tagging and indexing happen without a setting to choose. Each kind of source has its own parser, because a video, a PDF and a post fail in different ways, and a generic reader fails on all of them.
A chat built for trust, not for conversation
The assistant answers only from what you saved and never from the open web. Every answer lists its sources, and tapping a source opens the original card. If the archive doesn't contain the answer, it says so. The same principles I tested in Falak applied to a product in production.
Three models, each where it earns its place
A small, fast model does the high-volume work. A larger model is used only where quality is visible to the user. A third model classifies and routes. Code handles deduplication, guards and checks, because a model shouldn't take a decision that a rule can take reliably. Exhaustive search went from 1 result to 66–73 relevant cards with this split.
Rules before the test, every time
Before each evaluation I write the criteria, fix the configuration, score blind and run three times. Cost is measured against the estimate, not assumed. A blind benchmark of 8 models chose the current ones and cut the cost per answer by about 10×. Retrieval quality went from 43% to 73% hit@10.
Research with the people who will actually use it
Alpha testers on different phones and with different comfort with technology. Their sessions turned into a backlog prioritised with MoSCoW and WSJF. Several decisions came straight from them: the phone share sheet as the main entry, the bot made optional, installation as a home-screen icon.
Fast and minimal, measured
The interface follows research on neurodivergent reading: three reading levels, no infinite scroll, colour as an accent only, fixed card sizes. Everything that did not serve reading was cut.
Key Decisions & Trade-offs
What I chose, what I gave up, and what the measurement said.
| Decision Point | Options Considered | Why We Chose | Result |
|---|---|---|---|
| Which model does what | 1. One top model for every step 2. Three models by role, code for the rest | The best model on every step is the most expensive and not always the most accurate for the task. Splitting by role let the small model do volume and the large one do only what the user sees. | Cost per answer ÷10 |
| How to pick a model | 1. Reputation and benchmarks published by vendors 2. Own blind benchmark on own content | Public benchmarks don't cover my sources, my languages or my cost ceiling. Criteria written first, 8 models, blind scoring, fixed configuration, three runs. | The three models now in production |
| Retrieval | 1. Keep the first setup 2. Re-chunk and re-index the whole archive | Re-indexing everything costs time and a migration. The measurement said the first setup was missing more than half of the relevant cards. | hit@10 from 43% to 73% |
| Where the chat can look | 1. Archive plus web search 2. Archive only, sources always shown | A web fallback makes answers look better and makes trust wrong. Archive only means the answer is checkable in one tap. | Every answer cites its sources |
| How people get links in | 1. A messaging bot as the only entry 2. Share sheet first, bot optional | Testers didn't want a setup step, and iPhone needed a path that did not depend on the bot. The share sheet became the main path; the bot stayed for those who like it. | Setup in two minutes, no manual step |
| Native app or PWA | 1. App Store and Play Store 2. Installable web app | One person, two stores and review cycles was not sustainable. A PWA installs as an icon, updates instantly, and keeps one codebase. | One build, every device |
Which model does what
How to pick a model
Retrieval
Where the chat can look
How people get links in
Native app or PWA
What I Learned
The best model is relative to your data
Public benchmarks measure other people's tasks. On my own content, languages and sources, the ranking was different and the most expensive model was not at the top. The only benchmark that counts is the one run on the archive the product will actually answer from.
Retrieval before the model
A better model cannot answer from what retrieval didn't bring. Measuring hit@10 showed the first setup was missing more than half of the relevant cards. Fixing that moved quality more than any model change, and it is where I look first now.
Mixing models is a recipe, tuned to the archive
Which model does which step depends on the data: how long the sources are, how many languages, where an error is visible to the user and where it isn't. The split that works is not a rule I can reuse elsewhere; it is the result of measuring this archive, and it will change when the archive changes.
Cost and quality in the same test, or you optimise one and pay the other
Measuring quality alone pushed me towards the biggest model; measuring cost alone towards the smallest. Measuring both, three runs, fixed configuration, is what made the ÷10 on cost possible without losing answer quality.
See it, or talk about it
StayKeel is live and free during the beta. If you are building an AI product where cost, quality and trust all have to hold at once, I'd like to compare notes.