Mr. Poodles: I Built a Penguin Companion for a Friend Living in a Hostel

Achitya Gulati — Sun, 04 Oct 2026 20:14:01 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

When I shared Mr. Poodles with the person I built it for, her feedback began:

It's goood

I love how it was made personally for me

The name branding and everything

That word—personally—is the heart of this project.

My friend lives in a hostel and has food restrictions. That combination shaped the app: ingredient information matters, available equipment matters, and a useful meal idea has to fit the place where she actually lives.

I built Mr. Poodles, a native Android companion that brings food checks, sourced recipes, calorie logging, meal planning, workouts, and a gentle conversational penguin into one personal space.

The starting point is four plain-language actions:

Can I eat this? Check pasted ingredients or look up a specific food or product, with conflicts and missing information made visible.
Find a recipe. Retrieve published recipes and check supported results against her restrictions and available equipment.
Find a workout. Find article-supported movements, with instructions and equipment constraints.
Log what I ate. Record food in everyday language, with evidence-based estimates where available and manual corrections when needed.

Saved recipes feed into planning and shopping. Separate Hostel and Home environments keep their own practical constraints.

And when she simply wants to talk, Poodles is there too.

Home puts the everyday actions in one place, with clear labels and large controls.

Demo

Watch the Android walkthrough on YouTube.

This short walkthrough shows Home, companion chat replies, and workout interaction. A beginner-workout request leads to a clarification; a push-up follow-up asks about a suitable wall and clear floor space. The workout detail panel also labels AI programming adjustments separately from article-backed instructions.

Making it feel like hers

The name, original penguin artwork, and pastel interface are part of the experience. The visual direction draws inspiration from cozy games such as Cats & Soup; the bundled illustrations and chime are original.

The same gentle personality runs through companion chat and the food, workout, and logging conversations. Poodles can acknowledge a difficult day without immediately turning it into a lecture. There are no guilt-driven streaks or demands for attention.

That warmth also needed a usable interface: clear labels, large controls, predictable Back/Home behavior, and drafts that survive navigation. Recipe and workout screens keep the useful context above the conversation, so asking a follow-up doesn't mean losing the result.

The launch screen and companion welcome carry the same soft visual identity into the conversation.

What she said

The rest of her feedback was:

Especially for someone who has food restrictions and lives in a hostel

It has everything a person would need

From calories to workouts

Both excerpts preserve her original wording.

This is feedback from one person, and that's precisely why it matters to this project. She recognized both the personal touches and the connection between the features.

Code

Explore Mr. Poodles on GitHub.

The original application code is MIT-licensed. Dependencies and hosted models retain their respective licenses. The repository includes setup instructions, tests, third-party notices, and release verification.

How I Built It

Open-weight AI, with application rules around it

The Android client uses Kotlin and Jetpack Compose. A Cloudflare Worker handles hosted inference and research requests.

The current companion and structured research paths use Llama 3.1 8B Instruct through Cloudflare Workers AI. An optional, separately consented fallback uses gpt-oss-20b through Groq. These are hosted open-weight models; inference does not run on the phone.

Exa and Tavily provide optional source retrieval. Both inference providers receive the shared Poodles personality and task-specific instructions.

The research flow is:

Android request + relevant profile constraints
                  |
          Cloudflare Worker
                  |
       Retrieve source material
                  |
   Open-weight model: structured research notes
                  |
       Validate evidence references
                  |
 Android parsers + food/workout-specific checks
                  |
       Display result or uncertainty

The model supplies conversational assistance and structured research notes. Application code decides whether the retained evidence is sufficient to construct a supported recipe, workout, or food-log estimate.

A friendly answer still needs evidence

One of the most important decisions was how Poodles should behave when information is missing.

For someone with food restrictions, an incomplete ingredient list cannot quietly become an all-clear. The app distinguishes Avoid, No listed conflict found, and Need more information. Ingredient matching cannot certify food safety.

The mascarpone check asks for the exact brand, variant, and country. Missing evidence stays visible.

Research claims carry a source ID, a retrieval snapshot ID, and an exact excerpt. Here is part of the actual backend validation in research.js:

const source = snapshot.sources.find(s => s.id === reference.sourceId);
if (reference.snapshotId !== snapshot.id) invalid('snapshot_mismatch');
if (!source) invalid('unknown_source');
if (reference.excerpt !== claim.text) invalid('quote_mismatch');
if (!source.excerpt.includes(reference.excerpt)) invalid('quote_not_found');

Those checks establish where a quote came from. They don't establish that a page is complete or that it describes the correct product. Additional checks handle identity, restrictions, and supported layouts; unresolved gaps stay visible.

Recipe adaptations are labeled separately from published originals. Unknown nutrition stays unknown. A calorie question does not count as permission to write a diary entry.

The bug that taught me to classify failure properly

During development, recipe requests repeatedly showed a source-lookup pause. An unreadable page was being treated like a provider-wide failure, preventing useful candidates from being tried.

The repair separates a page we cannot use from a service that is actually rate-limited or unavailable. Other candidates can still be tried within the existing request cap, while real cooldowns remain enforced.

That distinction is small in code and large in the experience: one bad page should not make the whole feature appear unavailable.

Reliability behind the mascot

Food-log operations use stable operation IDs and persisted results so retries cannot add the same meal twice. Local data uses version-compatible snapshots and atomic replacement; a failed write cannot masquerade as a successful save.

The recorded 0.4.1 release checks passed 339 Android/JVM/Compose tests and 101 backend tests, with zero lint errors. A real Android HTTP transport test rejected an unsupported source and then successfully produced a validated recipe through the deployed backend.

That live check ran on the build host. Physical-device upgrade and structured usability acceptance for the latest release remain pending; the feedback above is not a substitute for those checks. Details are in the release report.

Why Does Open Innovation Matter?

A personal app needs to remain adaptable as its person's needs change.

Open-weight models let this project build around inspectable application behavior and multiple inference options. The current implementation already integrates two different model/provider paths behind the same personality and evidence contract. A future self-hosted deployment is possible engineering work, rather than a promise that this version already runs offline.

A closed API could generate a friendly reply. The useful difference here is keeping the application's identity, validation rules, and data model separate from any single model service—and publishing the surrounding code so someone else can adapt it for their own friend.

Cost mattered too. This deployment targets free provider allocations, with bounded requests and an optional fallback. Hosted services still impose quotas; open weights do not make hosting unlimited. Ordinary use doesn't ask my friend to manage API keys.

Privacy is an explicit application choice: saved chat history and comfort memories have separate opt-ins, memories can be inspected and removed, and unrelated companion history is excluded from research requests. Online inference still sends the relevant request to its provider.

Community Wisdom

Two DEV posts helped inform the evidence design:

Check AI Citations Against Retrieved Source IDs by Ranknod: validate references against the sources supplied for that request.
Your AI cited a real file. It still lied to you. by Enhanciar: a valid citation alone does not prove the adjacent claim.

They informed the approach; the project's own tests and release records describe what this implementation actually verified.

What Comes Next

The next step is watching her complete the everyday flows on the latest build without coaching, then fixing the places where she hesitates. Broader source-layout support also needs more real-world testing.

Her feedback already gave me a useful direction: keep the personal touches, and keep the everyday needs connected.

The name made it feel like hers. The engineering has to earn that feeling every time she opens it.

DEV Community: Achitya Gulati