Project note, August 2026: This post documents the design of Seasoned Pan, a small WordPress nutrition toolkit built around a real family need.
The first user for Seasoned Pan was never an abstract persona.
It was my mother.
She wanted a practical way to keep an eye on calories and protein without adopting another subscription, learning a complicated fitness platform, or being treated like a data-entry clerk every time she ate the same breakfast.
That constraint made the product better. It also exposed that I was trying to build two different things.
Two Front Doors
The private need was a food diary: save familiar foods, combine them into recipes, log a serving, compare the day against a goal, and see a simple weekly trend.
The public need came from a different direction. If I wrote about nutrition or recipes, I wanted calculators and plain-language reference material that I could cite without pretending to be a dietitian.
Trying to force both experiences into one interface made each one worse. The useful architecture was one calculation engine with two front doors:
- Public, stateless calculators for calorie needs, macro splits, and recipe nutrition.
- A private diary using normal WordPress accounts for foods, recipes, goals, and history.
The arithmetic does not care which interface requested it. Building that logic once made both products easier to test and kept their presentation appropriately different.
WordPress Was Already The Account System
My first instinct was to imagine a separate application with its own users, sessions, database, and administration. That was unnecessary.
WordPress already had authenticated users and a database. Reusing those facilities removed an entire class of software that would otherwise need to be secured and maintained.
Every diary query is scoped to the current user on the server. A saved food belongs to one account. A log entry snapshots its nutrition values when it is created, so changing a recipe tomorrow does not rewrite what someone ate last Tuesday.
Those are quiet decisions, but they are the ones that make personal data trustworthy.
Familiar Meals Should Be Cheap To Record
The daily loop needed to reward repetition rather than punish it.
A food is entered once. A recipe combines foods into a reusable meal. Logging a serving copies the relevant values into the day. The weekly view then turns seven isolated totals into a visible pattern.
There is no attempt to turn eating into a game. The interface answers a few ordinary questions: What have I logged? How close am I to my goal? What has the week looked like?
That restraint is intentional. Software for a family member does not get to hide behind engagement metrics. If it is irritating, confusing, or slow, I will hear about it directly.
The Broader Lesson
Seasoned Pan became buildable when I stopped thinking of it as a generic nutrition platform.
It is a small tool for a known person, plus a public reference surface that shares the same tested engine. The first use case provides discipline. The shared core provides leverage. WordPress supplies the boring infrastructure.
That is enough architecture for the actual problem, which is usually a better target than enough architecture for every possible future.