Project Brief Builder
Turn a rough idea into a clear, decision-ready brief: the problem, the users, the MVP scope, and what is out.
Sign in to use this tool. New accounts get 10 free credits.
Sign inNew to this? Read the guide.
What it produces
Real output from this tool, not a mock-up.
What went in
- Your idea
- A shared shopping list app for households that actually handles the bit where two people are in different supermarkets at the same time.
- Who it is for
- Couples and shared households doing a mix of a big weekly shop and top-up trips. Not families with complex meal planning.
- What problem it solves
- Existing shared lists do not handle two people shopping simultaneously, so you end up with two bags of the same thing. They also do not know which shop you are in.
- What the first version must do
- Shared real-time list. Live indicator showing someone else is shopping. Claim an item. Tag items by shop so the list filters to where you are.
- Constraints
- Two of us, both part time, no budget. iOS first. We would rather avoid accounts, a shared link would be better.
- What people use today instead
- WhatsApp messages, Apple Reminders shared lists, Google Keep, and phoning each other from the aisle.
The brief
One-line summary A shared shopping list for two-person households that shows who is shopping right now and lets you claim items so you don't both come home with milk. The problem Shared lists exist already, but none of them handle the actual failure mode: two people in two different shops at the same time, both grabbing the same stuff, with no idea what the other has already picked up. On top of that, most lists are flat, so when you're in the little corner shop for a top-up you're still looking at entries for things only the big supermarket stocks. The result is duplicate purchases, wasted money, and a lot of "wait, did you get milk" phone calls from the aisle. This is a narrow, well-understood annoyance for couples and shared households doing a mix of a big weekly shop and quick top-ups. It's worth building because the fix is simple (presence plus claiming plus shop tags) and nobody's bothered to do just that. Users and the job to be done Couples and shared households, two people, no kids' meal-planning complexity. The job: let both of us shop off one list, at different shops, possibly at the same time, without duplicating items or buying things the shop I'm in doesn't sell. This is not a meal-planning tool, not a recipe tool, not a family-with-many-members tool. Goals and success metrics Success is simple: duplicate purchases go to roughly zero for the households using it, and people stop needing the "did you get X" phone call. The single most important metric is duplicate-buy incidents per week per household, self-reported or inferred from claim data, trending toward zero after the first couple of weeks of use. A secondary signal worth watching is whether both people in the household actually open the app during a shop, since the whole idea only works if both sides are live. MVP scope Must-have for v1: - Shared list, real-time sync between two people - Live presence indicator showing someone else is actively shopping - Claim an item (marks it as being got, visible to the other person instantly) - Tag items by shop, list filters to the shop you're currently in - Shared access via a link, no account creation required - iOS only Out of scope for v1: - Android - More than two people per household - Meal planning, recipes, or auto-generated lists - Barcode scanning or price tracking - Store-specific catalogs or aisle mapping - Notifications/push alerts beyond in-app presence (assumption, see open questions) - Multiple households or list sharing beyond one pair - Offline conflict resolution beyond basic last-write-wins Constraints Two people building it, both part time, no budget. iOS first, so likely Swift/SwiftUI native rather than cross-platform, which also keeps things simple for a small team. No accounts: shared link access, which means you need some lightweight identity per device (probably a device-generated ID stored locally) to know who claimed what and who's "live." No backend budget for anything heavy, so a hosted real-time service (Firebase, Supabase, or similar) makes more sense than rolling your own server. Timeline isn't stated, so treat this as ongoing part-time work rather than a fixed deadline (assumption). Differentiation Right now people use WhatsApp, Apple Reminders shared lists, Google Keep, or just phone calls. All of these are static lists with no idea where you are or whether someone else is already shopping. None of them solve the actual moment of friction, which is real-time overlap between two shoppers. This app's whole reason to exist is those two features: presence (someone else is shopping right now) and claiming (this item is already being got), plus shop-based filtering so the list itself is context-aware. That's a small, specific improvement, not a bigger version of the same tool.
Open questions
- Assumption: no push notifications in v1, presence and claims only show when the app is open. Confirm if that's acceptable or if at least a claim notification is needed.
- Assumption: identity is handled via a device-local ID tied to the shared link, not a real login. Need to decide how this behaves if someone reinstalls the app or switches phones.
- Assumption: real-time backend will be a hosted service like Firebase or Supabase rather than custom infrastructure. Worth confirming given the no-budget constraint and free-tier limits.
- Open decision: what happens if both people claim the same item within a second of each other, how should the conflict resolve and be shown.
- Open decision: how does someone add a new shop tag, is it freeform text or a fixed list, and who decides which shop filters are available.
- Open decision: no stated timeline, worth agreeing on a rough target for a usable version given both people are part time.
- Open question: does "claim" auto-remove the item from the list, or does it stay visible as claimed until the shop is actually finished.
When to use it
Use this to turn an idea you have been describing badly into something a collaborator could act on. It defines the problem, the users, what the first version must do and, most usefully, what is deliberately out, then lists the questions you still need to answer.