Example execution pack
This is a saved public example of an Edge Arena execution pack. It shows the same structure a user receives after a run, using the prompt: “Build me a small SaaS that solves a specific scheduling pain for independent restaurants.”
Saved example artifact • Your own pack will reflect your goal, launchpad, and constraints
Executing:
ShiftSwap for Independent Restaurants
Use this pack like a working document — review, validate, then execute.
SMS-first shift-swap MVP for independent restaurants.
Selected from 13 ideas • Winner score 82
A focused SMS-first shift-swap product for independent restaurants. Staff text a single number to request a swap, the system finds eligible coworkers, asks the manager for approval, and updates the schedule.
If you execute consistently, you could have a usable MVP in ~6 weeks.
boltStart here - first steps
Have a working SMS prototype that can route a real swap end-to-end inside 5 business days.
Stand up Twilio Programmable SMS with an inbound webhook to a Next.js API route.
1 day
Hard-code two roles (server, busser) and a 5-row schedule table in Postgres.
1 day
Implement the manager approval reply parser ("YES" / "NO" + shift ID).
1–2 days
Why This Won
01. Execution Plan
Get a real swap routed end-to-end via SMS for one hand-rolled fake restaurant before involving any pilots.
- 1.Stand up Twilio Programmable SMS with an inbound webhook to a Next.js API route.
- 2.Hard-code two roles (server, busser) and a 5-row schedule table in Postgres.
- 3.Implement the manager approval reply parser ("YES" / "NO" + shift ID).
- 4.Run 3 fake swaps end-to-end with the operator playing both staff and manager.
A working SMS round-trip handling at least one swap and one decline, with logs that prove it.
Twilio toll-free verification takes 5-7 business days - start the verification on day 1 or the launch slips by a week.
Skip the dashboard entirely in weeks 1-2 - every minute spent on UI before SMS is solid is a minute thrown away.
Onboard a single real restaurant from the operator's network, in person, and observe the first real swap inside 48 hours.
- 1.Pick a restaurant the operator personally knows; visit in person to set up.
- 2.Import the current week's schedule from a CSV pasted from the owner's spreadsheet.
- 3.Send the staff group a welcome text with the example swap text.
- 4.Stay in physical or phone proximity for the first 48 hours.
A real shift gets swapped through the system inside 48 hours, with the owner watching it happen.
The first real swap will surface 5-8 small bugs that did not appear in the fake-restaurant test - budget two days of bug-fix time in this phase.
Resist adding features in this phase - every "while you're here" feature request from the owner extends the timeline by a week.
Add 2 more pilots and convert 2 of 3 to paid $79/month plans within 6 weeks of code start.
- 1.Onboard pilots 2 and 3 one week apart to spread out the bug-fix bursts.
- 2.Run a 10-minute Friday owner call with each pilot for 6 weeks.
- 3.Send a one-page conversion offer in week 6 with the Stripe link inline.
- 4.Convert at least 2 of 3 to paid plans; let the third churn without saving.
2 Paying customers at $79/month, $158 MRR, and a 4-restaurant operational playbook.
A 100% conversion target is wrong here - accepting one churn keeps the product honest about who the right customer is.
Do not lower price to save a pilot. A $30/mo customer in restaurants is more expensive to support than a $79/mo one.
02. Validation Signals
Hourly restaurant turnover at 75%+ since 2022 (BLS JOLTS data)
High turnover directly drives swap volume - the pain scales linearly with the macro signal.
Limitation: BLS turnover is industry-wide; verify that independent full-service restaurants (vs chains) show the same pattern in your target metro.
Active r/restaurateur threads describing 3-6 hours/week spent on swap coordination
Operator-level descriptions of the exact pain in their own words validate both the problem and the size of the time-cost.
Limitation: Reddit threads are anecdotal - schedule 5 owner interviews before sizing the offer.
Independent-restaurant scheduling pain is well-documented in operator forums and trade press. The unknown is willingness to pay $79/mo in cash vs continuing to use a group text - verify with at least 5 paid pilots before scaling.
03. Core Strategy
MVP Architecture
Twilio SMS webhook -> Next.js API route -> Postgres (Neon) -> manager approval reply via SMS -> Postgres update + staff SMS confirmation. No mobile app, no Slack integration, no payroll integration in MVP.
Tech Stack
Next.js 16 + Postgres (Neon) + Drizzle ORM + Twilio Programmable SMS + Stripe Billing. Deploy on Vercel; weekday-only on-call coverage for Twilio webhook failures.
Scope Boundary
MVP supports: staff requesting a swap by SMS, the system finding eligible coworkers (same role + opposite availability), manager approving by SMS, and updated schedule. Out of scope: time-off requests, payroll, schedule generation, mobile app, Spanish localization.
Build Timeline
Week 1: Twilio inbound + outbound SMS routing. Week 2: eligibility engine + manager approval flow. Week 3: schedule import (CSV) + Stripe billing. Week 4: first real pilot onboarded, initial swap observations, bug-fix sprint. Week 5: pilots 2 and 3 onboarded, Friday owner calls begin. Week 6: conversion push, Stripe paid plans activated, signed contracts from 2 of 3 pilots.
First User Strategy
Start with 3 restaurants the operator personally knows. Onboard each in person with the owner present, observe the first real swap inside 48 hours, and personally text every staff member to confirm receipt. Skip self-serve onboarding entirely in the first month.
04. Risks & Operator Advice
Twilio SMS deliverability or toll-free verification delays
SMS that arrives 30 seconds late during a Friday dinner shift functionally does not arrive - and the toll-free verification process can stall the launch by 5-7 days.
Mitigation: Start Twilio toll-free verification on day 1 of the build, before any code is written. Add a fallback short-code carrier (Telnyx) as a paid optional for restaurants with deliverability issues.
A single-workflow product is too narrow to hold a $79/mo subscription long-term
Owners may churn after a few months once the swap pain is solved - single-workflow tools have a known retention ceiling.
Mitigation: After 5 paid customers, add the second-most-requested workflow (time-off request routing). Resist adding it earlier - narrow scope is the entire MVP advantage.
05. Immediate Next Steps
A 6-week MVP that doesn't have a pilot identified in week 0 turns into a 10-week MVP - owner buy-in is the launch dependency.
Verification takes 5-7 business days and is the single most common timeline-killer for SMS MVPs.
Real billing from day one filters out tire-kickers, which is critical at 3-pilot scale where every minute counts.
Weekly owner contact at pilot stage is non-negotiable - it surfaces churn risk before it becomes a cancellation email.
06. Supporting Evidence
Claims
Demand
Hourly restaurant turnover at 75%+ has been sustained for 3+ years (BLS JOLTS, 2022-2025).
Pricing
Competing tools (7shifts, Homebase) start at $149+/month per location for the all-in-one product.
Behavior
Restaurant manager forums report 3-6 hours/week spent on swap coordination across 30+ self-reported threads.
Evidence
Industry data
BLS Job Openings and Labor Turnover Survey (JOLTS), 2022-2025, accommodation and food services.
Product pricing
Public pricing pages for 7shifts, Homebase, and HotSchedules as of May 2026.
Forum observation
R/restaurateur, r/KitchenConfidential threads on shift swaps from 2024-2025.
System Provenance
AI-generated plan, stress-tested by competing agents for feasibility. May contain assumptions, inaccuracies, or incomplete context. Outcomes may vary—use your judgment.