Why Another Cooking App?
I did not set out to build a cooking app.
I set out to solve a problem I had. Every time I wanted to cook something decent, I ended up on a recipe site drowning in ads, life stories and pop-ups asking for my email.
I just wanted to cook dinner.
Chef's Kiss is what I started building instead. It has not launched. There is nothing to use yet, and no date. This is a note on what I am building and why, written while it is still being built.
The premise is simple. A cooking app with no ads and no distractions. Recipes that work, ingredients you can actually get hold of, and an interface that does not insult your intelligence.
That is the intent. Whether it lands is a different question, and not one I can answer yet.
What a Cooking App Would Have to Get Right
Free recipe sites have a business model problem. They need volume. Millions of visitors. Ad impressions. Affiliate links to kitchen gadgets nobody needs.
That model forces compromises, and you can see every one of them on the page.
The alternative is a small audience paying directly. Fewer readers, and no advertisers to answer to. That changes what you build.
Here is what I think it has to mean in practice:
No Ads
Open a recipe. Cook. Nothing else on the page. No banner for meal kits, no video that starts playing while you are elbow deep in dough.
No Life Stories
No scrolling past 800 words about someone's grandmother's kitchen in Tuscany. Ingredients first. Method second. Done.
Offline First
It is being built as a PWA, a progressive web app. It runs in the browser and is designed to keep working when the connection drops. No app store, no update prompts, no permissions to grant.
You are cooking in a kitchen with dodgy WiFi. The page should still work.
Curated, Not Infinite
Not 50,000 recipes. A smaller set that has actually been cooked and tested, with clear instructions and realistic timings.
Quality over quantity. Easy to say, slow to do, and the main reason this is taking a while.
Why I Am Building It as a PWA
I could build a native app. iOS and Android, App Store and Google Play.
I decided not to.
PWAs make more sense for this. Here is the reasoning.
No App Store Gatekeeping
Apple and Google take a cut of everything sold through their stores, control the update cycle, and reject apps for reasons that are not always obvious.
A web app avoids all three. It also means whatever I finish can go in front of people the day it is ready, rather than the week after a review queue clears.
Instant Updates
Native apps need approval for every update. That takes days, sometimes weeks.
A PWA updates when I deploy. A bug fix is live in ten minutes. That matters most while a thing is still half built, which is exactly where this is.
Works Everywhere
One codebase across phone, tablet and laptop. Start a recipe on a phone, finish it on a tablet propped up in the kitchen.
Same account, same state, and no separate builds for one person to maintain.
Offline by Default
PWAs can cache content locally. Native apps can do this too, and most do not bother.
The plan is that every recipe you open is cached, along with your list and your saved favourites, so the kitchen is never the place it stops working.
Because cooking happens in kitchens, not in coffee shops with perfect 5G.
The Tech Behind It
Building it this way meant technical choices that favour the experience over growth.
Stack
Next.js on the front end. Fast, good for search, well suited to PWAs.
Supabase for the back end: auth, database and storage in one place, which keeps the number of moving parts down when it is one person building.
Stripe is wired in for whenever it does launch. Nothing is switched on.
Caching Strategy
Recipe pages cache after the first view. Images optimised and lazy loaded. Lists sync when online and keep working when not.
Service workers do that work. The browser does the heavy lifting, which is the whole argument for the web here.
Recipe Structure
Recipes are structured data with JSON-LD markup, so a search engine knows what it is looking at.
More importantly, structured data leaves the door open for what I want later. Meal planning. Ingredient substitutions. Nutrition.
The foundation is the part worth getting right early. Most of the rest can be rewritten.
No Tracking
No Google Analytics. No Facebook pixel. No tracking cookies.
Plausible for basic traffic counts, and nothing beyond that. No consent banner to build, and one less thing to maintain.
Who It Is Being Built For
Chef's Kiss is not for everyone, and it is not trying to be.
The person I have in mind:
- Cooks regularly, not just at Christmas
- Wants recipes that work the first time
- Would rather pay for a clean tool than put up with a free cluttered one
- Does not need 10,000 options to choose between
- Values their own attention
If free recipe sites work fine for you, use them. They work for a lot of people and that is not a criticism.
This is for the people who find that experience exhausting. I do not know yet how many of those there are.
What Exists and What Does Not
Browsing, saving favourites, shopping lists and offline mode are the core, and they are what I have been working on first.
They are not finished, and none of it is public. When there is something worth looking at, I will say so here.
Meal Planning
Plan a week of dinners, get one combined shopping list, waste less food. Not built.
Smart Substitutions
Out of buttermilk, and the app suggests an alternative with the quantity adjusted. Not built.
Voice Mode
Hands-free reading while you cook, so you are not prodding a phone with floury fingers. Not built.
Community Recipes
Curated contributions from people who actually cook, rather than open submissions. An idea, not a plan.
None of it is urgent. The core has to be good before any of that is worth starting.
Why Build It This Way
The internet taught us everything should be free. That was never true. It was just billed to someone else.
Free means you are the product. Your attention, your data, your email address passed on to a meal kit company.
Paid means you are the customer, and the person building it answers to you instead of to advertisers.
That is the model I want for this one. I am not putting a number on it here, because nothing is on sale, and I would rather commit to that when it is real.
The bar is that it covers what it costs to run and funds the work to keep improving it. It is not going to make anyone rich.
That is fine. Marvanova does not need Chef's Kiss to be huge. It needs it to be good.
Building in Public
I am writing about this while it is unfinished because that is the honest version. Most build stories get written afterwards, once the ending is already known.
There is nothing to visit yet. No link, nothing to try. When that changes, it will be here on the blog.
If you are building something similar, the PWA decisions above are the ones I would think hardest about. They are the ones that are difficult to reverse later.
And if you have questions about building PWAs, or about how any of this is put together, email me at hello@marvanova.com.
Let's build better tools.