Case study · Spec project · 2026
Frasco began as a weekly dinner concept, not a request for a polished set of pages. Before designing the website, I worked through the offer, unit pricing, menu rotation, delivery radius, returnable packaging, customer acquisition, and the evidence the owner would need to improve the service. The site became the public face of one coherent operating model.
The plan defined Frasco as a solo-operated weekly dinner service: one cook, one Sunday route, three household sizes, and a returnable packaging loop. That immediately shaped what the website had to explain, what the order flow had to collect, and which promises the business could reliably keep.
The early plan put 24 dishes on the menu every week. Prep time, ingredient overlap, and delivery capacity exposed the strain. The better model keeps 24 dishes in the catalog but makes eight orderable each week. That reduces operational risk and creates a natural reason for customers to return when favorites come back into rotation.
The familiar alternative Frasco has to beat.
Clear value without sounding like meal prep.
Twenty-four catalog dishes, eight live each week.
System thinking
Diet, gluten, dairy, egg, soy, nuts, sesame, oil-free, cuisine, and spice level all have real populations on both sides. If a filter cannot meaningfully split the menu, it does not ship. That rule turns the interface into product proof.
Live and returning states give the business a retention hook without pretending everything is available all the time.
Solo and Dos ship in glass jars, Familia in stainless trays, and first orders can stay fiber-only when returns would be a burden.
Short declarative sentences, concrete nouns, prices where prices matter, and no wellness language.
A JSON catalog drives filters, prices, household formats, live states, nutrition, and crawler-visible structured data.
Beyond the build
A useful launch plan does more than publish pages. It connects the offer to the places local customers already look, gives outreach a specific destination, and turns site activity into decisions an owner can act on. For Frasco, the same menu and service logic can support acquisition, retention, and reporting without creating a second content system to maintain.
Build neighborhood and delivery-area pages around real service boundaries, keep Google Business Profile details consistent, and add Organization, Product, and FAQ structured data so search engines understand what can be ordered and where.
Give apartment managers, coworking spaces, gyms, parent groups, and local employers a tailored landing page or referral code instead of sending everyone to a generic homepage. Each partnership can answer the right questions and be measured separately.
Use “returning next week” dish states, back-in-rotation email alerts, jar-return reminders, and post-delivery feedback prompts to create reasons to come back that are tied to the actual operating model.
Track menu views, filter use, order-starts, completed orders, household size, referral source, delivery zone, and repeat behavior. A concise monthly report should show what changed, why it matters, and the next test—not bury the owner in pageview charts.
Image direction
A spec project has no kitchen shoot, so the photography had to be directed as a system: 85mm, eye-level through glass for jars, a high angle for trays, pale grey-green background, and composition rules that came from each recipe.
Outcome
Frasco became a six-page static prototype built from the business model: shared menu data, household-size pricing, structured product information, accessible interactions, reduced-motion support, and one disciplined image system. Just as importantly, the build leaves clear paths for local search, partner outreach, email retention, conversion tracking, and owner-friendly reporting.
Bring the rough version: pricing questions, a messy menu, packaging constraints, local delivery logic, or a site that has to explain the business and take action on day one.
hola@josefina.dev