Case Study
FeedCount
Turning feeding data into a daily decision.
Most baby apps focus on tracking. FeedCount focuses on the decision that comes after tracking.
A mobile-first progressive web app that helps parents estimate how much formula may still be needed today.
Overview
Role
Product Discovery · Product Strategy · UX Design · Frontend Development
Stack
SvelteKit · JavaScript · PWA · localStorage · Netlify
Platform
Mobile-first PWA
Status
Live MVP
The problem
The problem wasn’t tracking
At first glance, this looked like a tracking problem. In reality, tracking was already solved.
I was already using a baby tracking app that recorded formula intake reliably. The data was available whenever I needed it. The challenge appeared after the data had been collected.
Several times a day, I found myself checking how much formula had already been consumed, estimating a daily target, calculating what remained, and thinking about how the remaining amount could fit into the rest of the day.
The friction came not from complexity, but from repeatedly translating data into a practical decision.
Tracking
- Feed tracking
- Intake logging
- Daily history
Decision-making
- Daily estimate
- Remaining formula
- Future bottle planning
Existing tools solved tracking. FeedCount focuses on decision-making.
Reframing the problem
The estimate was not only age-based
My initial assumption was that formula planning was mostly based on age. That assumption came from how infant formula is commonly presented: age ranges, feed counts, and bottle sizes.
As I researched infant nutrition guidance, I learned that estimated daily energy requirements are more nuanced. They depend on age, weight, and sex. The resulting formula volume also depends on the energy density of the specific formula being used.
That changed the product definition. The challenge was not simply recording bottles. The challenge was translating several inputs into a practical estimate that could be updated throughout the day.
Initial assumption
- Formula planning is mostly age-based.
Actually influence formula planning
- Age
- Weight
- Sex
- Formula energy density
- Today’s intake
From:
How much did the baby eat?
To:
Given what has already happened today, how much formula may still remain?
Defining the MVP
Reducing scope was a product decision
Once the problem had been reframed, the next challenge was defining the smallest product that could solve it.
There were many directions the product could have expanded into. Existing baby apps often include feeding logs, sleep tracking, diaper changes, growth charts, reminders, caregiver sharing, and long-term analytics. It would have been easy to follow the same path.
Instead, I focused on the single decision that created repeated daily friction: estimating how much formula may still remain today.
Could have built
- User accounts
- Cloud sync
- Caregiver sharing
- Multiple children
- Breastfeeding estimation
- Notifications
- Growth charts
- Analytics
Actually built
- Local setup
- Daily intake
- Remaining formula estimate
- Bottle split
The MVP stayed focused on the decision, not on building a complete feeding platform.
The solution
A small tool for a repeated daily decision
FeedCount keeps the experience intentionally small. The setup contains information that changes infrequently, while the main screen focuses on the values that change throughout the day.
Parents enter how much formula has already been consumed and how many feeds are likely to remain. FeedCount then estimates how much formula may still remain today and suggests how that amount could be split across future bottles.
The goal is not to prescribe a feeding plan. The goal is to reduce repeated mental calculations and support a practical daily decision.
Setup
- Birth date
- Sex
- Current weight
- Formula energy density
- Saved bottle sizes
Daily use
- Formula consumed today
- Feeds left today
- Remaining formula estimate
- Suggested bottle split
Stable information belongs in setup. Changing information belongs on the main screen.
Product and technical decisions
Keeping the system intentionally lightweight
The technical choices followed the product scope. FeedCount did not need accounts, a backend, or sync to answer the core question. The MVP could stay local, fast, and simple.
Those decisions were not only engineering shortcuts. They helped protect the product from expanding into another full baby platform.
localStorage
- No account creation
- Local setup storage
- Fast first use
PWA
- Accessible from the phone home screen
- No app-store distribution
- Lightweight deployment
Static deployment
- No backend infrastructure
- Simple Netlify hosting
- Low maintenance overhead
Mobile-first UI
- Designed for short sessions
- Useful during daily care routines
- Focused on quick input and output
The architecture stayed small because the product question was small.
Building with constraints
Constraints shaped the product architecture
FeedCount was built as a solo project with no budget, limited development time, and short, unpredictable working sessions.
Those constraints were not separate from the product work. They influenced the scope, the platform choice, the data model, and the decision to keep the first version intentionally local and lightweight.
I also wanted the first version to become useful quickly. This was not a speculative concept; it was solving a real daily problem I was already experiencing myself.
The result is not a full feeding platform. It is a focused tool for one repeated daily decision.
Constraints
- Solo project
- No budget
- Limited development time
- Short and unpredictable working sessions
- Need for rapid validation
Decisions
- Narrow MVP scope
- PWA instead of native app
- localStorage instead of backend
- No accounts or sync
- Incremental development
The constraints helped keep the product honest.
Post-MVP iteration
Improving clarity without expanding the scope
After launch, the focus shifted from defining the MVP to improving the experience inside the same narrow scope.
One early iteration was moving current weight from Settings to the main screen. Weight directly affects the daily estimate, so keeping it hidden in setup made the calculation feel less responsive. Moving it closer to the daily workflow made the relationship between input and output clearer.
I also maintain a GitHub backlog for future improvements, including an epic focused on refining the hierarchy and interaction clarity of the main screen.
First challenge
- Define the narrowest useful product
- Keep tracking out of scope
- Launch a usable MVP
Current challenge
- Improve hierarchy
- Clarify interactions
- Avoid unnecessary feature expansion
The second challenge is improving the experience without expanding it.
Reflection
Tracking data is not the same as supporting a decision
FeedCount started as a practical personal problem, but the product work was mostly about definition and restraint. The most important decisions were not only what to build, but what to leave out.
Discovery changed the problem definition. Scope reduction created most of the product value. Post-MVP work is now about making the experience clearer without turning the product into something larger than it needs to be.
Product quality is not always about adding features. Sometimes it is about making one decision easier.
Outcome
A live MVP with a clear product scope
FeedCount is now a live mobile-first PWA with a public GitHub repository, static deployment, local setup storage, and a maintained product backlog.
It is intentionally small, but complete enough to demonstrate the full product loop: identify a repeated decision, define the smallest useful solution, build the MVP, launch it, and continue improving the experience.
Delivered
- Live PWA
- Public GitHub repository
- Static Netlify deployment
- Local setup storage
Demonstrated
- Product discovery
- Scope definition
- UX design
- Frontend implementation
- Post-MVP iteration
FeedCount became an exercise in defining the smallest product that could solve a repeated daily decision.
FeedCount is intentionally small, but that is the main point. It shows how a product can create value by narrowing the problem, reducing unnecessary scope, and making one repeated decision easier.