The test

The RapScalYon.surf pitch is a SaaS app in a day: a secure core, installable packs, and a stack interview that proposes which packs you need. The honest way to find out whether that holds is to build a real app on it and keep the log of what breaks. So we did. The app is CarShopper (app.myvehiculos.shop): it watches Facebook Marketplace for used cars in Costa Rica, filters them against what you will accept, and ranks what is left.

By the commit times: the framework, the car pack and a Scoreboard page were in the repository within six minutes on the evening of 7 October. By about half past ten the next morning, after roughly three hours of work, it was reading live Facebook listings and refreshing prices on demand. Everything after that was the normal work of making an app good, done in Claude Code against the same repository, and it is the part worth telling.

What the framework gave us for free

Accounts, row-level security, the multi-factor gate, private file storage, the item-search base pack (profiles, candidates, review) and the email pack were already there. CarShopper is one more pack on top, items-matching-ranking, plus a small worker that fetches listings. We did not write a login, a permission check or a table of users.

What real use broke, and what we did about it

Paying twice for the same listing. The scraper we use charges per listing and has no way to skip ones it has seen. The worker now scans listings cheaply first and fetches full details only for cars it does not already hold. We have not yet measured the saving, so we are not quoting one.

Bring your own key. Checking a listing costs money, so each account can store its own Apify key (kept in Supabase Vault, never readable by the browser) and a monthly ceiling, and the Check button runs as them.

An onboarding checklist and a sidebar that collapses, because a new user needs to know the next step and a phone screen needs the room.

A rounding bug. The price showed as 2,200,001 colones when the seller had typed 2,200,000. We stored US dollars rounded to cents and converted back for display, and the cents leaked into the colones. The fix is to keep the price as typed and show that. Small, but it is the kind of thing a user notices in ten seconds and a demo never shows.

Photos that expire. Facebook image links stop working after about two weeks, so the app now keeps its own copy of each car's first photo in the account's private storage.

The part that is the point: the fix went down into the framework

The user asked a plain question: when a seller changes a price, can I see when and from what? We built a price history for cars. Then we noticed nothing about it was specific to cars, so we moved it into the item-search base pack (version 0.2.0): a history table, one row per price change with the price as the seller typed it, and one function any child pack calls to record a change. The car pack now uses it, its own table is gone, and its 25 existing history rows were carried across. A jobs pack or a real-estate pack gets the same feature by calling that function.

That move took a few minutes, because the base pack, its tests and its rollback are all in one repository. The suites pass (16 of 16), and the change is a migration with a rollback like every other pack change.

What this does and does not show

It shows the loop we want from the framework: build the thing, hit the ordinary problems, and put the general fix in the shared layer so the next app starts further along. It does not show that anyone can do this in a day without help; we built this with Claude Code and a lot of context about the framework. Photos and price history have not yet been seen by a second user, the cost saving is unmeasured, and the hosted database was updated by hand rather than through the installer's validation step. Those are open items in our tracker, not footnotes we are hiding.

If you want to try the same loop on your own idea, the stack interview is the front door.