VibeletsSmall idea. Real app.
What you will build
Turn spreadsheet expertise into a simple service shop. Watch services, prices and Stripe test checkout become a working app.
Give customers a clear service, price and way to pay.
01 · SEE THE PROBLEM
When one quick favour becomes a small business
George keeps getting spreadsheet questions. Lily helps him turn that expertise into clearly priced services.
02 · WATCH THE BUILD
Build a service shop with Stripe checkout
See the real storefront build, product selection and a verified sandbox purchase. No real money moves.
03 · REMIX THE VIBELET
Sheet Rescue
A Stripe sandbox demo: choose a service and try the test checkout without moving real money. No spreadsheet work, appointment or delivery is included. Remix this vibelet and connect your own Stripe account before accepting real payments.
Prompts you can start with
Initial prompt
Build Sheet Rescue, a polished mobile-first service storefront for George's spreadsheet help. The three intended service names are Formula Fix, Spreadsheet Check and Team Tune-up; the actual products, descriptions and one-time EUR prices must come only from the owner's selected Stripe products, never hardcoded or simulated. Use the native Stripe connector in Products and services mode, not paid vibelet access. This demo is SANDBOX ONLY: clearly label Test mode / no real money, and disable purchasing if runtime status is not sandbox. Create a real draft with an honest missing-connection/catalog state while I complete Stripe setup; request the real Configure Stripe connection UI using requiredConnections=["stripe"]. Once connected, read stripe.status and stripe.listProducts, render the real selected services and formatted prices, and let a visitor deliberately buy one service through stripe.createCheckout. Use a stable idempotency key for each unresolved purchase and keep orderId in memory. Let the trusted Vibelets host show its Continue to Stripe Checkout link; never collect card details, embed Checkout, open the returned URL yourself, invent products, or mark payment successful from a return URL. Show the real buyer-scoped order using stripe.getOrder and a Check payment status button, with pending/paid/cancelled-or-expired/refunded states honestly. No customer contact details, public order collection or secret data in generated HTML; no iframe localStorage or sessionStorage. Do not imply buying a service books a meeting, uploads a spreadsheet or completes any work. Include a short how-it-works section and fictional-demo notice. Use warm cream, dark teal and mint, friendly typography and three spacious service cards with accessible 44px controls and no horizontal scrolling. No AI, email, other integrations, subscription, shopping cart or inventory. Make sensible choices and build the draft now.
Refinement
Improve the working Sheet Rescue shop without changing the Stripe products, prices or real payment flow. Add an accessible service-detail panel and an FAQ explaining that each purchase is a one-time service purchase, scheduling and fulfilment happen separately, and this public example uses Stripe test mode. Make the current order panel easy to find on phones, show its actual service title, formatted total and verified status, and distinguish payment pending from payment confirmed. Only a paid stripe.getOrder result may show confirmation. While a known order is pending, check at most every five seconds for up to one minute, then stop and retain a manual Check payment status action. Reuse the same idempotency key after uncertain responses; a second purchase needs an explicit new Buy action after the previous order is resolved. Add a Reopen pending checkout action that reuses that key and relies on the trusted host link. Keep the sandbox-only purchase guard and avoid iframe web storage. A remix must show a clear missing-connection state until its owner selects their own Stripe products; never carry the original owner's merchant selection or payment results into the copy. Keep customer-facing wording simple: say Continue to Stripe Checkout, without host/iframe/SDK implementation details. When starting a genuinely new purchase after a resolved order, clear the previous order ID before requesting the new checkout so checking status cannot accidentally confirm the old order. Stop the pending-order timer when the order resolves or the page is disposed. Fix the browser test plan too: its first missing-state assertion uses exact text that is only a prefix of the actual message. For purchase tests declare an explicit synthetic browserTests.stripe fixture with salesType products and test products, never actual owner IDs or data. Use the isolated mockStripe paid action and the actual Check payment status button to test pending-to-paid UI; label these as isolated tests, not evidence of a real Stripe sandbox purchase. Use accessible roles and substring assertions when a message has additional explanatory text.