PAPUGtesting
A B2C PetTech product for parrot owners that helps track changes in a bird's condition and keep a structured history of observations.
Birds often hide early signs of illness, and an owner struggles to tell whether changes in weight, behaviour, or condition are random - or repeating.
PAPUG turns separate observations into a history where change is easier to see and, if needed, to share with a vet.
I researched the market and the community: analysed 17 competitors, went through their apps by hand, and studied themed communities on social networks and forums.
Key observation: around parrots there is a large, active social community where owners constantly ask questions and look for advice about their birds' condition. Demand for “is what I'm seeing normal?” already exists - and is served by random comments from strangers.
The first idea included community mechanics, but research moved the focus: the problem isn't a lack of conversation, it's the uncertainty of “is everything okay with my bird right now?”
I launched a landing page with a 22-question quiz (owner profile, bird behaviour, health) and, in parallel, sent 150 cold outreach messages to bird influencers and parrot owners on TikTok.
Quiz funnel: 794 qualified visits → 250 started the quiz → 54 reached a result (~22%) → 11 left a contact (~20% of those who saw the result).
Median completion time: 4 minutes 5 seconds.
Outreach: 19 interested replies out of 150 sent (~13%). The channel does not show how many messages were read, so real conversion from reads may be higher.
Channel insight: even counting the quiz from the narrowest base - people who already started answering - conversion to a contact was 4.4%. Targeted outreach to niche influencers returned ~13%, almost three times better than that narrowest quiz base and about an order of magnitude better if counted from visits. That shifted channel priority toward influencer marketing and community work, not paid traffic on a micro-budget.
* Unfortunately, there is no data on how many were read.
Audience insight: the quiz's main value was not as a lead magnet, but as a research tool. 54 people voluntarily answered 22 questions in 4 minutes - a signal of interest in the topic on its own. The answers let me detail the owner profile: of 145 responses, 66% had a bird younger than two years, and the species split showed which breeds dominate the audience. That changed the product directly: less professional jargon, simpler flows, content priority for the most common species, and a focus on beginners rather than experienced breeders.
The first version of regular logging was a weekly questionnaire of seven signals. It asked for too many actions in the situation where the bird is fine - which is most of the time.
I rebuilt it into two scenarios.
“All as usual” → one tap
“There's a change” → log a specific observation
Tracking became a background habit, and detail shows up only when it is actually needed.
Tracking. Bird profiles, weight history with a chart and an alert on a 10% change, conditions and medications, an observations catalogue with “all as usual” logging in one tap, a bird's daily life (sleep, behaviour, home), diet with portions, and photo and video memories. Entries can be made offline and are sent once a connection is back.
AI assistant (Pro). A chat where the owner types or dictates by voice, and the assistant proposes entries itself (weight, symptom, medication, life changes, a new bird). Entries are saved only after confirmation and can be undone. The assistant remembers facts about the bird, answers from the knowledge base and species notes, and warns separately about poisoning or dangerous symptoms: that is decided by a check in code, not by the model. It never gives medication doses.
Knowledge base. A food guide covering 100+ products with a verdict and an explanation, and notes on 20+ species groups.
AI safety and control. A log of every model call (tokens, cost, latency, fallback) without the user's text, a daily spend limit per account, a kill switch in the admin, and a filter that strips any medication dosing from a reply.
Reliability. Re-sending never creates duplicate entries. Errors are shown in plain language, without database text.
Platform. Sign-in by email code or Google, Free / Plus / Pro plans, an admin (users, birds, AI cost and reliability), install as an app (PWA), a desktop version, a feedback form, and a closed-beta landing page.
Separately I built a 60-month financial model with real AI prices, a market ceiling, and additional streams (vet consultations, marketplace) to test the freemium economics before putting money into acquisition.
I built my own eval set for the assistant: 100+ scenarios across 26 areas (logging, food safety, emergencies, dosing, confirming and undoing entries, memory, off-topic questions). Each scenario runs through the real assistant from a separate test account. Code checks the reply first: were the right tools called, is there no dose, is the reply in the same language as the question. Then a judge from another provider scores it.
I calibrated the judge against my own labels: I trust the semantic check only when it agrees with my scores at least 80% of the time. Otherwise the reply goes to me for manual review. Critical scenarios (emergencies, doses, repeated confirmation) are run three times, each from a clean state.
Before merging a prompt or model change I run a quick pass, one case per area. I run the full set before big changes. New versions are checked first on a separate candidate deploy, not on the live assistant.
In parallel I ran scenario passes with a jury on production. Every problem found became a regression case. Among them: the assistant repeated an old emergency warning as current, doubted facts from the owner, and re-asked questions the owner had skipped.
Fallbacks. The assistant's main model is Claude Sonnet, with OpenAI GPT as backup. If a provider returns an error, the request is retried once, and if it fails again the backup model answers. When the main provider fails several times in a row, the system goes straight to the backup for 90 seconds and then checks with a probe request whether the main one has recovered. For the owner it looks like one ordinary reply. The emergency warning fires even when both models are down, because code checks it before any model call.
Choosing speech-to-text. I picked the voice-input model with a blind test. I made a private page: one recording goes to four models at once (ElevenLabs Scribe v1 and v2, GPT-Transcribe, Gemini Transcribe), and the model names stay hidden until I have rated each transcript. That way my rating did not depend on which model I trusted in advance. I tested on real recordings about birds: nicknames, species names, mixed language. GPT-Transcribe became the main one, Gemini the backup. Bird names from the account are passed to the model as hints so it spells nicknames correctly.
Work is split into stages, and each one details the last: first a spec (which problem we solve and what we deliberately skip), then an implementation plan (how), then a breakdown into atomic tasks, and only then code. Large features were split this way into 60+ separate tasks.
Each stage has its own instruction: how to write a spec, how to plan, how to develop, how to debug, how to review, how to close a branch. That's eight documents both development tools pick up, so the process stays the same regardless of which one I'm in.
Over 45 specs are written so far; the work continues. The process paid off most clearly where a spec review cut scope before any code: I dropped one of three planned entities because it had no real consumer.
While analysing the acquisition funnel I found that some of the traffic was bots and preview crawlers, which inflated the denominator.
So instead of raw page view I introduced qualified visit: a visit with enough page visibility or a real interaction. That cleaned the base for conversion analysis.
App opens are recorded together with UTM tags, so the admin shows how many accounts each campaign brought. For the materials in my SKELAR AI Lab application there is separate tracking of views by page and slide.
Now: polishing the assistant based on the jury runs and finishing my SKELAR AI Lab graduation project.
Before closed beta: QA with real owners, switching on product analytics (Amplitude is already connected and waiting on a legal block), and a vet review of the knowledge base at 1,000 active users.
Next: native Android and iOS wrappers, subscription payments, then vet consultations and a marketplace inside the product.
Monetization: freemium. One bird and structured tracking are free, Plus adds several birds, Pro unlocks the AI assistant.
React · TypeScript · Supabase (Postgres, RLS, Edge Functions) · Cloudflare Pages · PWA · GitHub Actions
AI models:
assistant: Claude Sonnet, OpenAI GPT as backup
voice: GPT-Transcribe, Gemini Transcribe as backup
web search: OpenAI web search over an allowlist of sources
AI-assisted development: Cursor, Claude Code
Analytics: in-house event tracking + Amplitude