Hidden Spoon

The problem we kept seeing

A small restaurant can be memorable and still disappear when discovery is shaped by ad spend. I wanted to try a simpler rule: let a place earn attention through the owner’s story and the people who actually visited.

The product

Hidden Spoon is a story-first local discovery app for independent restaurants.

A merchant can explain why they cook, what they make, and what their neighborhood means to them. A neighbor can browse a warm Feed, switch to a map, open the full Store Story, and leave a visit note with private receipt or payment proof.

The product’s signature is the Spoon Signal. It puts three things beside each other:

• the owner’s reason for cooking;
• the signature dish; and
• the visit signal from the community.

A receipt upload is labelled Proof submitted · Not verified until a separate moderation step confirms a visit. The proof file is private: it is not shown in the public feed or to the merchant. That distinction is the trust promise, not a hidden score.

Try the demo

The public link opens straight into an English DemoMode with fictional data, so a judge can use the whole product immediately.

From Discover, choose Take the tour, then open Mina’s store story. The tour introduces fair discovery, private proof, owner control, the Feed, the Store Detail, and the illustrated Seoul/New York map. It needs no account, camera permission, real receipt, or API key.

The data is synthetic on purpose. It keeps the judging path repeatable and makes it clear that we are showing a product idea, not passing fictional reviews off as real restaurant activity.

How it is built

The client is Flutter and Dart. Supabase provides the production-shaped backend: Auth, PostgreSQL/PostGIS, Row Level Security, private Storage, safe discovery projections, and Edge Functions for protected writes.

The public build uses local DemoMode for the judged journey. The repository also contains the guarded Story Studio path: a merchant’s source is kept separate from the public story, the server fixes the model and validates structured output, quotas and idempotency run before provider dispatch, and publication requires the owner’s approval. The optional GPT-5.6 provider route and AI gates are disabled in this public link, so an accidentally shared demo URL cannot create uncontrolled spend.

The current release is covered by 88 passing Flutter tests, clean static analysis, Supabase regression cases, a secret scan, and a GitHub Pages build.

Where Codex helped

Codex was part of the build from the first screen to the release check. I used it to iterate on the Flutter experience, review the Supabase policies, design failure-path tests, check the English flow on narrow screens, and keep the release notes honest. Product policy, privacy boundaries, and every public claim were still reviewed by a person.

What was hardest

The hard part was making trust visible without pretending that an uploaded image is automatically true. Submission, moderation, and public status are separate states in both the database and the UI. We also kept fictional directions inside the demo instead of quietly sending a judge to a made-up address.

The result is a small prototype with a clear contract: stories earn attention, proof earns trust, and neither can be bought.

What comes next

With a small pilot of real owners, we would add moderator tools, verified payment integrations where legally appropriate, native-speaker localization, and a short, prepaid Story Studio window with revocable access. Those are next steps—not claims about the synthetic public demo.

Built With

• dart
• flutter
• github-actions
• openai-codex
• postgis
• postgresql
• supabase