A recipe app in one prompt, and three tries at a URL
Founder, Newly
The recipe app is the first app most people build, because everyone already has the data: forty tabs, a screenshots album called food, a notes app with ingredients pasted in and the method lost. The good version does three things. It takes a link and turns it into ingredients and steps, it finds what you can cook from what is in the fridge, and it rescales servings. We asked for exactly that in 182 characters, in Newly’s classic builder, just after midnight on 20 September 2026, and had screens for all three about seven minutes later. The one we could actually test, the paste-a-link import, failed three different ways, and the reasons it failed are the most useful thing on this page. A second session the same day got a recipe in by hand, after two more fixes and five typings of the same pancakes, and reached every screen the first had not. It sits with the other app examples built and recorded the same way, and like them, nothing here has been tidied.
Key Takeaways
- One prompt, four screens, seven minutes, no questions. A 182-character prompt produced a recipe list, an Add Recipe sheet, a fridge search and a detail screen with servings scaling, with a working preview about 7 minutes after send and not one question asked in six prompts.
- The URL import never saved a recipe. Three attempts on one AllRecipes page, three different failures: an error at about 15 seconds, another at about 12, then a spinner that was still going after 60.
- “Paste a link” became a free proxy, not AI. The generated scraper fetched pages through api.allorigins.win, which answered Error code: 522; the fix put corsproxy.io in front of it, which answers HTTP 401 without an API key.
- Saving was broken underneath, and the empty state hid it. The on-device SQLite the first prompt chose throws SharedArrayBuffer is not defined in the web preview; we typed one recipe five times and spent two more prompts before a card appeared, and the fix left the app with two storage engines.
The brief
Everyone has the data. That is why the recipe app is the most-built first app: you do not have to invent anything, you have to stop losing it. The good version does three things, and we asked for exactly those three: paste a link and keep the recipe with its ingredients and steps, search what we have saved by what is in the fridge, and change the number of servings.
Everything else, meal plans, timers, nutrition, was left out on purpose. A recipe management app is only worth building when it is smaller than the recipe manager app you could buy, not bigger. Our internal brief did want ten mock recipes and a shopping list built from a recipe, so there would be something to search. The first session’s three prompts never got there; a second session got the shopping list with one more prompt, and the ten recipes never arrived at all, we typed one by hand, five times. That matters further down.
Read this part before you build anything. If all you want is the best recipe saver app you can get today, buy one. The paid recipe managers have spent years on the import, they run it on servers, and they sync between your phone and your partner’s. Build when the fridge search is the point, when the recipes have to live inside something bigger, a meal planner and grocery list app or a home inventory app that already knows what is in the cupboard, or when you want the data to be yours. And read the import section first, because that is where this build did not get there.
The map
Search by ingredients is a matching rule, not a search box
Every pitch for a recipe app by ingredients says the same thing, search by what you have, and every first build treats it as a text field. What it actually is: each recipe carries a list of ingredients, the fridge is a set of ticked items, and a recipe is makeable when every ingredient it needs is ticked. The rows that matter are the near misses. Tick things in and out below and watch which recipes turn on.
A recipe is makeable when every ingredient it needs is ticked. One short is a near miss, and it is the row worth putting first, because it is one thing to buy on the way home. A text search that returns recipes containing the word you typed gets neither of these right: it ranks a recipe that merely mentions garlic above one you could cook tonight.
How it got built
The Fridge tab came out of the first prompt, with a field reading Type an ingredient, press Enter... and an empty state. It returned its first result in the second session, once one recipe was in by hand: eggs found Buttermilk Pancakes with a 1 of 1 match badge, a substring match on ingredient names that counts how many of the typed ingredients the recipe contains.
Read the session that built it ↓The session
Two sessions: one build error, three tries at a link, five tries at a save
What follows is two sessions on 20 September 2026, 00:09 to 00:34 and then 10:56 to 13:52 with a pause for a dropped connection, in the order they happened. The prompts are what we typed, not a tidied version. The app you see is what came back.
Make a recipe app. I want to paste a link to a recipe and have it saved with ingredients and steps, search my recipes by what I have in the fridge, and change the number of servings.
It did not ask anything. Within 25 seconds the header changed from Untitled / Draft to CookSync / Draft: it named the app, unasked. The plan card had one line, 1. Build CookSync recipe app frontend. Then it read its own instruction files, an OpenAPI spec and a native UI guide, thought for 17 seconds, and started installing packages: Installing: expo-sqlite, expo-clipboard. That is the storage decision, an on-device SQLite database, made in the first minute with no question about accounts or a backend, even though the first file it read was the spec for one.
Then it broke its own preview
At 00:13, while files were still landing, the phone went red. The new recipes screen imported a package that had not been installed:
Unable to resolve module expo-image from /expo-project/app/(tabs)/(recipes)/index.tsx: expo-image could not be found within the project or in these directories:
node_modules
> 13 | import { Image } from 'expo-image';
| ^What the user sees
We did nothing, and that turned out to be right. Two minutes later the log showed Typecheck, then Installing: expo-image. It found its own missing import through the typecheck, not from the error on the phone. It then deleted the template’s home tab, four rows with a red bin icon, to make room for the two new tabs, and went looking for a gradient package with a shell command. The preview re-bundled and the error was gone by 00:17, with no click on Retry and no prompt from us. If the phone goes red mid-build, wait for the turn to end before you type.
What one prompt actually produced
The build finished at 00:17, about seven minutes after send: 9 actions from the planner, 51 from the frontend agent, and one stretch of 163 seconds of thinking. Its closing line:
Closing summary, verbatim
CookSync is built. You can now paste a recipe URL (AllRecipes, Food Network, NYT Cooking, etc.) to auto-import ingredients and steps, search your saved recipes by what's in your fridge, and scale servings up or down on any recipe detail screen.
On the phone: a dark theme with an orange accent, a header reading My Recipes with an orange plus, a chef-hat icon over No recipes yet, the line Your saved recipes will appear here. Paste a link to import one instantly., an orange button reading Add your first recipe, and a floating pill tab bar with two tabs, Recipes and Fridge. Four screens were written: the list, an Add Recipe sheet, the fridge search, and a recipe detail screen with servings scaling at app/recipe/[id].tsx. Three of them we could open. The fourth needs a saved recipe, and we did not get one until the second session, thirteen hours later.
And the parts we did not ask for
A name, CookSync, and a project slug, cook-sync-app-oclnsf. A dark theme with an orange accent. A Manual tab on the Add Recipe sheet, which we had not mentioned and which turned out to be the only way a recipe ever did get in. A deleted home tab. And a helper line under the import button, Works with AllRecipes, Food Network, NYT Cooking, and most recipe sites., which nothing in the session had tested.
None of it is wrong, exactly. It filled the gaps we left, and it filled them plausibly. The one that cost us was a gap it did not fill: sample data. It shipped empty, so the list, the fridge search and the servings scaling could not be seen working in this session. The import is the next section, and the way in by hand is the one after.
The URL import, three times
At 00:19 the preview took clicks. Add your first recipe opened an Add Recipe sheet: a segmented control, From URL and Manual, a field labelled RECIPE URL with the placeholder https://www.allrecipes.com/recipe/..., and an orange Import Recipe button. We pasted a real page, the AllRecipes best chocolate chip cookies recipe, and pressed it. The button became a spinner reading Importing... for about 15 seconds, then a box appeared above it: Couldn't reach this URL. Check your connection and try again. Nothing was saved. A second press did the same and reset the field.
Our connection was fine, so we opened utils/recipe-scraper.ts in the code view, 204 lines. The paste-a-link feature is not an AI extraction. scrapeRecipe(url) fetches the page through a free public CORS proxy, https://api.allorigins.win/get?url=..., takes the returned HTML, looks for a JSON-LD block whose @type is Recipe, reads name, description, image, recipeYield, totalTime or cookTime, recipeIngredient and recipeInstructions, parses the ingredient lines with regular expressions, and falls back to the page’s Open Graph title and image with 4 servings and no ingredients. Every network failure in the catch block becomes the exact sentence we had just read on the phone.
From a shell on the same Mac, the proxy answered Error code: 522 for the AllRecipes page and for a BBC Good Food page too. That code is Cloudflare timing out on the proxy’s own origin: the free proxy was down. Fetching AllRecipes directly with a generic User-Agent returned HTTP 402, so the site blocks non-browser clients as well. Two reasons this import could never be relied on as generated, and neither of them is a bug in the parsing.
I pasted https://www.allrecipes.com/recipe/10813/best-chocolate-chip-cookies/ and it says Couldn't reach this URL. Check your connection and try again. My internet is fine. Please fix the import so it actually works.
Under a minute later it was done: one read, two edits, a lint. It told us the scraper “now tries three different CORS proxies in sequence”, corsproxy.io first, described as most reliable, then allorigins.win, then thingproxy as a last resort, and to give that AllRecipes link another try. We did, at 00:25. Importing... for about 12 seconds, then a new box: Couldn't import this recipe. The site may be blocking imports, then a dash, then try copying the recipe manually. Still nothing saved.
What the user sees
We probed the three from the shell at 00:27. corsproxy.io answered HTTP 401 for every site, with {"error":"A valid API key is required. Get one at https://console.corsproxy.io/"}. allorigins.win answered Error code: 522. thingproxy.freeboard.io did not answer at all. So after the fix the import still could not work for any site, and the new error text pointed at the recipe site rather than at a chain of free proxies that was down or paywalled. That is the paragraph to remember: the confident fix and the confident error message were wrong in the same direction.
It still fails, now it says the site may be blocking imports. corsproxy.io says a valid API key is required, allorigins gives error 522 and thingproxy does not answer. Can you make the import work without free proxies?
About two minutes: Installing: react-native-webview, a new components/RecipeScraper.tsx, five edits to the Add Recipe screen. It said the import “now uses a hidden WebView that loads the actual recipe page in a real browser context”, with no proxies and no CORS issues, and that AllRecipes “(and any other recipe site with JSON-LD schema) will work”. We gave the link another try at 00:31. The button sat on Importing... for more than 60 seconds, no error, no result. A hidden WebView cannot read a cross-origin page from the web preview, so the injected script never reports back. Whether it works on a phone we cannot say from this session; it would need a device build, which is the publishing section below. Three prompts, one recipe site, zero recipes imported.
The fridge tab
The other tab worked as far as it could. Fridge shows a search field with the placeholder Type an ingredient, press Enter... and an empty state reading What's in your fridge? over Add ingredients above to find matching recipes. The large title, What's in my fridge?, is drawn on top of the search field, a transparent-header overlap we have seen on another build from the same week. With no recipes stored there was nothing for it to match. The next morning it turned out the overlap was worse than it looked: the title took the taps, so the field could not be focused at all in the web preview until the sixth prompt.
Session 2: a recipe in by hand, thirteen hours later
We came back at 10:56 the same day with one goal: get a recipe in through the Manual tab and reach the screens the first session never saw, the detail, the servings control, a fridge search with a result and the shopping list. The URL import was not touched. Two things had changed overnight. The project opened on a (home) route showing Your app is currently building... above the tab bar, the deleted template tab still being the start route after a restart, with the app itself behind Recipes. And the app was light rather than dark: app.json has userInterfaceStyle set to automatic, so it follows the Mac.
- 10:58The Manual tab is a full form: TITLE *, DESCRIPTION, IMAGE URL, SERVINGS pre-filled 4, COOK TIME (MIN), INGREDIENTS rows of quantity, unit and name with a dashed + Add ingredient, STEPS with + Add step, and an orange Save Recipe button. We typed Buttermilk Pancakes, four ingredients, cook time 20. Typing worked in every field.
- 11:02The Mac’s internet dropped mid-form. We paused.
- 13:25Back to a modal over a dimmed workspace: Session disconnected. This session was disconnected after 10 minutes of inactivity. Reload the page to start a new one. We pressed Reload. The half-filled form was gone.
- 13:26Typed it all again. At step three the preview re-mounted on its own: the sheet snapped back to From URL and the form was empty. No error, no toast, nothing in the chat.
- 13:28Third entry, as fast as we could type: title, description, cook time 20, four ingredients, three steps.
- 13:30Save Recipe. The sheet went back to From URL with every field empty, no toast, no error, and My Recipes still read No recipes yet. We opened
utils/database.ts, 195 lines: it callsSQLite.openDatabaseSync("cooksync.db")with no platform check, and nothing in it handles the web build.
I filled in the Manual form and pressed Save Recipe. The form went blank and My Recipes still says No recipes yet, so nothing was saved. Please fix saving so a manually entered recipe shows up in the list in the preview.
Closing text, verbatim
Saving now calls router.back() to dismiss the modal, which triggers the recipes list to reload via useFocusEffect. Your manually entered recipe will show up immediately after pressing Save.
It had read a failed write as a stale list and changed only the navigation. So:
- 13:34The preview came back on the (home) placeholder without the tab bar; Reload preview in the right rail restored it. Recipes: still No recipes yet.
- 13:37Fourth entry of the same recipe.
- 13:38Save Recipe. This time the sheet stayed put and a pink box appeared between the steps and the button.
SharedArrayBuffer is not defined
What the user sees
That one line is the whole story of the empty list. expo-sqlite on web needs SharedArrayBuffer, which browsers only expose to pages served with cross-origin isolation headers, and the preview is not served with them. Every save since the first session had thrown this; the sheet had simply caught it and cleared the form. The on-device database the first prompt chose in its first minute had never been able to save anything in the browser.
Now when I press Save Recipe it says SharedArrayBuffer is not defined and nothing is saved. Please make saving work in the web preview.
It installed @react-native-async-storage/async-storage and wrote a new utils/database.web.ts. Its closing text said saving “should now work in the web preview” because “the .web.ts suffix makes Metro automatically use the AsyncStorage implementation on web instead of the SQLite one that requires SharedArrayBuffer.” Read that twice. The fix is a fork: the browser build now stores recipes in AsyncStorage, the phone build keeps SQLite, and nothing moves between them. A recipe saved in the preview will not be on the phone, and one saved on the phone will not be in the preview.
- 13:44Fifth entry of the same recipe.
- 13:46Save Recipe. The sheet closed by itself and My Recipes showed one card: Buttermilk Pancakes, a chef-hat placeholder, 20m, a people icon and 4. The card is drawn under the My Recipes title, the same header overlap as the fridge.
- 13:45Tapped the card. A detail screen: back arrow, title, share icon; an orange block where the image would be; pills reading 20 min and 4 servings; the description; a Servings card with minus, the number 4, and plus; Ingredients with quantities in orange; Instructions below the fold.
- 13:46Plus twice. Servings 6, and the list rescaled to 225 g plain flour, 3 whole eggs, 450 ml milk, 1 ½ tbsp caster sugar. The 4 servings pill under the title did not change.
- 13:47Bottom of the screen: Instructions 1 to 3 as typed, and no shopping-list control anywhere. Fridge: the title took every tap; three tries put no text in the field.
Two things. On the Fridge tab I cannot tap into the ingredient box because the What's in my fridge title sits on top of it, please fix that. And add a button on the recipe screen that turns the ingredients into a shopping list I can tick off.
It said “Both fixes are live”, that the ingredient input on the Fridge tab “is now fully tappable”, and that the recipe screen “has a shopping cart button in the header that opens a checkable shopping list.” This time all of it was true:
- 13:50Fridge: the title now sits above the field. Typed eggs, pressed Enter: an orange chip eggs ×, 1 recipe found, and the pancakes card with a green 1 of 1 match badge. Tapped it: the detail screen now has a cart icon beside the share icon, and the servings were back at 4. The scale is not stored.
- 13:51The cart: a Buttermilk Pancakes list reading 0 of 4 items with Check all. Ticked flour and milk: both struck through, 2 of 4 items, and a Clear all link appeared. The list uses the base quantities for 4 servings, not the 6 we had scaled to.
- 13:52Every screen the brief asked for, reached. Stopped inside the box.
What the session cost
Six Build prompts across two sessions. Three bought an import that still does not import, two bought a save that works in the browser and not on the phone, one bought the fridge fix and the shopping list. The plan balance is read per batch rather than per build: it fell by 7 across the five-build first batch, by 4 across session 2’s two projects, and rose by one overnight with nothing sent, so we cannot price this app to the credit. The build error cost nothing but three minutes of nerve; the five typings of one recipe cost twenty. Run again, we would spend the second prompt on ten sample recipes and a storage choice that works in the browser, and take the import to a backend before typing anything else about it.
The numbers
What the session produced, against what it was asked for
Four numbers from the log, then the brief line by line. The second table is the one to read before you type your own prompt: it shows where a first build stops on its own.
| Asked for | What arrived | Seen working? |
|---|---|---|
| Paste a link, keep the recipe with ingredients and steps | An Add Recipe sheet with a From URL tab, then a proxy scraper, then a chain of three proxies, then a hidden WebView | No. Three attempts on one AllRecipes page, three different failures, nothing saved |
| My saved recipes | A My Recipes list with an empty state, an Add your first recipe button, and a Manual tab on the sheet that could not save in the web preview until session 2 | One card, Buttermilk Pancakes, 20m, 4, after two more prompts and five typings of the same recipe. Every earlier save threw SharedArrayBuffer is not defined |
| Search by what is in the fridge | A Fridge tab with a field reading Type an ingredient, press Enter... under a title that took the taps | Yes, in session 2: eggs returned 1 recipe found with a 1 of 1 match badge, once the sixth prompt moved the title off the field |
| Change the number of servings | A Servings card with minus and plus on the recipe detail screen, app/recipe/[id].tsx | Yes, in session 2: plus twice took 4 to 6 and rescaled 150 g to 225 g and 1 tbsp to 1 ½ tbsp. The 4 servings pill did not change and the scale resets when you leave |
| Ten mock recipes (our internal brief, not typed) | Not built | No. One recipe, typed by hand, five times |
| Shopping list from a recipe (internal brief, not typed) | Built by the sixth prompt: a cart icon on the recipe screen and a tickable list with Check all and Clear all | Yes, in session 2: 2 of 4 items after ticking flour and milk. It uses the base quantities, not the scaled ones |
| Nothing, it added these itself | The name CookSync, an orange accent on a theme that follows the Mac's light or dark setting, a Manual entry tab, on-device SQLite, a clipboard package | Yes, all of it, in the first seven minutes |
The money is smaller than the time. The classic builder starts at $25 a month, and this whole session fits inside one evening of it. Getting the app onto a phone that is not yours adds an Apple Developer Program membership at $99 a year and, for Android, a one-time $25 Google Play registration, both from the builder’s own publishing guide, linked in the sources. What the session did not buy was the import, and no amount of credits spent on the same approach would have.
The catches
Four things nobody mentions until you hit them
Paste a link is a server, not a feature
A phone app cannot simply fetch a recipe page. In the web preview the browser refuses the cross-origin request unless something in the middle allows it, which is why the first build reached for a free public proxy, and why the second build reached for three. Free proxies are somebody else’s server with somebody else’s uptime: on one evening we saw a 522, a 401 asking for an API key, and silence. Recipe sites, for their part, answer non-browser clients with a 402. The shape that works is a fetch from your own backend, sending a browser User-Agent, reading the schema.org Recipe JSON-LD that most recipe sites publish, and handing the app a clean list of ingredients and steps. Newly’s classic builder ships a backend of its own, Liquid Backend, and its own publishing guide expects you to deploy it before you submit; in three prompts the agent never proposed using it. The extraction the brief imagined, sending the page to a model and getting ingredients and steps back, is a backend job too. This page stops short of it; adding AI features to your app is where that part is written up.
It ships empty, and empty hides bugs
Three of the four features we asked for could not be judged in the first session, not because they were broken but because there was nothing in the database. An empty recipe list looks fine. A fridge search with no recipes returns nothing and looks fine. Servings scaling on a screen you cannot open looks fine. Worse, the empty list hid that saving itself did not work: the first Save Recipe cleared the form with no message, and it took a prompt that quoted the error before anything real was fixed. Put sample data in the first prompt: ten recipes you actually cook, two of them with awkward units, one with a step list longer than a screen. Every bug the fridge search, the scaling and the save have will show up in those ten before it shows up in front of anyone else.
The preview is a browser, and the database it chose is not
The first prompt picked expo-sqlite in its first minute without asking, and nothing in utils/database.ts checks the platform: it opens the database and expects it to work. In a browser it cannot. Expo’s own docs say web support for the package is in alpha, needs Metro configured for wasm files, and needs HTTP headers that allow SharedArrayBuffer, the Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy headers; the preview is not served with them. So every save threw SharedArrayBuffer is not defined, and the first version of the sheet swallowed the error and cleared the form. The prompt that fixed it did so with a fork, AsyncStorage for the browser and SQLite for the phone, which means two engines, two schemas and one app, and a recipe that exists on exactly one side. Whether the preview’s recipe survives a reload we did not test. The preview also reloads on its own: twice in this session, once mid-form, with no message, taking the half-typed recipe with it, and ten idle minutes end the workspace with a Session disconnected modal. If you test in the browser, ask for a storage choice that works in both places in the first prompt, and keep long entries in a note you can paste.
The web preview cannot judge a WebView, so publishing is part of testing
The third version of the import loads the recipe page in a hidden WebView, and in a browser that WebView cannot report back across origins, so the spinner never stops and never fails. The only way to know whether the fix works is a real build on a real phone. In the builder that is Launch then Deploy: the panel asks Where do you want to deploy? with iOS targets Simulator, TestFlight and App Store, and Android targets Simulator, APK, AAB and Play Store. Before it builds anything it scores the project. Ours read 91% with 1 issue blocking App Store, 1 blocking · 1 recommended · 9 passed, and the blocker was Apple Credentials, with a Fix with AI button that reads Uses 1 prompt. We pressed neither that nor Build.
From there the route is the builder’s own guide: an Apple Developer Program membership at $99 a year, connect the Apple account, a build of typically 5 to 15 minutes that lands in App Store Connect, install it through TestFlight on a real iPhone, complete the listing with screenshots, description, privacy policy URL and age rating, then Apple review of typically 1 to 3 days. Do the TestFlight step with the AllRecipes link in your hand, and type the pancakes again: on a phone the app stores in SQLite, not the AsyncStorage the preview used, so the recipe saved in the browser will not be there. If the hidden WebView works on a device, that is where you find out; if it does not, you have spent $99 learning what the first catch already said.
Checklist
Before you hand it to anyone
Seven checks, every one of them something these two sessions ran into.
- Put ten real recipes in before you judge anything. This build shipped with none, and it took a second session, two prompts and five typings of one recipe before the list, the fridge search and the servings control were seen working.
- Test the URL import on a phone build, not in the web preview. The hidden WebView version sat on Importing... for over a minute in the browser and cannot be judged there.
- Do not ship a free CORS proxy. Three of them failed on the same evening, with a 522, a 401 and no answer at all, and the error text blamed the recipe site. Move the fetch to a backend.
- Pick one storage engine. The fix that made saving work in the preview left the web build on AsyncStorage and the phone on SQLite, so a recipe saved in one place does not exist in the other, and with no accounts a lost phone takes its recipes with it.
- Check the headers on every screen. The Fridge title took the taps until the sixth prompt, and the saved card still draws under the My Recipes title.
- Expect the preview to reload under you. It re-mounted twice in one session with no message, wiping a half-typed form both times, and ten idle minutes end the workspace with a Session disconnected modal.
- Know where the app starts after a restart. The deleted template tab is still the first route, so the preview opens on a Your app is currently building... placeholder until Recipes is tapped.
FAQ
The questions that come up every time
You can build the screen in one prompt; making it work is a second job. Our build produced an Add Recipe sheet with a From URL tab and an Import Recipe button in about seven minutes, but under it was a client-side scraper fetching pages through a free public CORS proxy, api.allorigins.win, which answered Error code: 522 the evening we tested it. The follow-up fix chained three free proxies (corsproxy.io wants an API key and returns HTTP 401, allorigins gave 522, thingproxy did not answer), and a third prompt swapped in a hidden WebView that cannot read a cross-origin page from the web preview at all. On one AllRecipes page, across three attempts, no recipe was ever saved. The import that works is a fetch from your own backend, with a browser User-Agent, parsing the schema.org Recipe JSON-LD that most recipe sites publish.
Sources
- App Store submission guide, docs.newly.app
Apple Developer Program at $99 a year, a build of 5 to 15 minutes into App Store Connect, TestFlight, Apple review of 1 to 3 days, Google Play at $25 once. The page now redirects to its legacy path; it describes the classic builder this session ran on. Read 20 September 2026.
- The AllRecipes page we pasted three times
Best Chocolate Chip Cookies. A direct fetch without a browser returned HTTP 402 on 20 September 2026, so the site blocks non-browser clients on top of everything the proxies got wrong.
- schema.org: Recipe
The JSON-LD type the generated scraper looks for, and the properties it reads: recipeIngredient, recipeInstructions, recipeYield, totalTime, cookTime.
- Cloudflare: Error 522
What the free proxy's Error code: 522 means: Cloudflare timed out contacting the origin web server. The proxy, not the recipe site, was unreachable.
- MDN: Cross-Origin Resource Sharing (CORS)
Why a fetch from the web preview to a recipe site needs a proxy in the first place, and why the answer is a server of your own rather than somebody else's free one.
- Expo SDK 54: SQLite, web platform notes
Why every save failed in the web preview. Web support is in alpha and may be unstable, and using expo-sqlite on web needs Metro configured for wasm files plus HTTP headers that allow SharedArrayBuffer, the Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy headers, which the preview does not send. Read 20 September 2026.
Nothing on this page was re-run after the session. The proxies were checked once, from one Mac, between 00:23 and 00:27 on the date given, and a free proxy that was down then may be up as you read this. That is rather the point. None of the sites named here is affiliated with the builder.
Bring ten recipes and one evening
The list, the fridge and the servings screen are one paragraph of plain English, and the import is a backend decision you can make before you type. Copy the first prompt, add ten recipes you actually cook and the words sample data, and start at the fridge. If the import matters more to you than the search, you will know by the second prompt, and you will have spent an evening finding out. Newly keeps the other builds recorded this way in one place.