PromptBase
Upgrade
Close icon
General
Home
Marketplace
Create
Hire
Login
Chat
Sell
Explore

Prompt Details

Model
(claude-4-8-opus)
Token size
828
Example input
[RAW_IDEA]: A photo-sharing app where friends can only see each photo for 24 hours [BUILDER_TARGET]: Bubble [CONSTRAINTS]: free tier only, no paid APIs, ship in a weekend
Example output
── SPEC COMPONENT 01 ──────────────────────────────────────── TYPE: Core Function COMPONENT: Ephemeral Photo Post DETAIL: A user uploads a photo that becomes visible to their friends and auto-expires 24 hours after posting. Expiry is enforced on read, not by deletion. CONFIDENCE: 95% BASIS: 2 signals (photo-sharing + 24h visibility both stated) BUILDER ACTION: In Bubble, create a Photo data type with a created_date and a computed "expires_at = created_date +(days)1". On the feed, filter with a constraint expires_at > Current date/time. Store images in Bubble's built-in file storage (free-tier friendly). ───────────────────────────────────────────────────────────── ── SPEC COMPONENT 02 ──────────────────────────────────────── TYPE: User Flow COMPONENT: Post → Friend Feed → Auto-Vanish DETAIL: User selects a photo, posts it, and it appears in friends' feeds until the 24h window closes, after which it no longer renders. CONFIDENCE: 80% BASIS: 2 signals (sharing to friends + time-limited view) BUILDER ACTION: Build an Uploader page and a Feed page. Feed uses a repeating group with the expires_at constraint from 01. No scheduled workflows needed — read-time filtering keeps you on the free tier. ───────────────────────────────────────────────────────────── ── SPEC COMPONENT 03 ──────────────────────────────────────── TYPE: Data Model COMPONENT: User / Photo / Friendship DETAIL: Three types: User, Photo (owner, image, created_date), and Friendship linking two Users. CONFIDENCE: 85% BASIS: known platform behavior + "friends" signal BUILDER ACTION: Create these three Bubble data types. Model Friendship as a type with fields user_a and user_b (both User) to keep queries simple. ───────────────────────────────────────────────────────────── ── SPEC COMPONENT 04 ──────────────────────────────────────── TYPE: User Roles COMPONENT: Standard User Only DETAIL: Every account is a peer user; no admin/moderator tier. CONFIDENCE: 60% BASIS: 0 signals — no roles mentioned in idea BUILDER ACTION: Use Bubble's default user type, no role field. FLAGGED AS ASSUMPTION — see Log A01. If moderation is wanted, this is a decision gate before build. ───────────────────────────────────────────────────────────── ── SPEC COMPONENT 05 ──────────────────────────────────────── TYPE: Edge Case COMPONENT: Friend Request / Acceptance DETAIL: How two users become "friends" so photos are scoped correctly. CONFIDENCE: 55% BASIS: 1 weak signal ("friends" implies a graph, mechanism unstated) BUILDER ACTION: Build a request→accept flow writing Friendship rows on accept. FLAGGED AS ASSUMPTION — see Log A02. Decision gate: mutual-accept vs. one-way follow changes the whole data model. ───────────────────────────────────────────────────────────── ── SPEC COMPONENT 06 ──────────────────────────────────────── TYPE: Edge Case COMPONENT: Storage Growth of Expired Photos DETAIL: Photos hidden after 24h still occupy free-tier storage and can hit Bubble's storage cap. CONFIDENCE: 75% BASIS: known platform behavior (free-tier storage limits) BUILDER ACTION: Read-time hiding alone will eventually exhaust free storage. Since scheduled cleanup workflows and paid tiers are OUT under your constraints, this is a stated limitation: manual periodic cleanup only. See Log A03. ───────────────────────────────────────────────────────────── ── SPEC COMPONENT 07 ──────────────────────────────────────── TYPE: Edge Case COMPONENT: Timezone Consistency DETAIL: Expiry must use a single clock so a photo doesn't linger or vanish early across timezones. CONFIDENCE: 70% BASIS: known platform behavior BUILDER ACTION: Rely on Bubble's server-side Current date/time (UTC) for both created_date and the feed constraint. Do not use device time. ───────────────────────────────────────────────────────────── ── SPEC COMPONENT 08 ──────────────────────────────────────── TYPE: Edge Case COMPONENT: Empty Feed State DETAIL: When all a user's friend photos have expired, the feed is blank. CONFIDENCE: 65% BASIS: 0 direct signals — inferred from ephemeral design BUILDER ACTION: Add a "nothing to see right now" group shown when the repeating group count is 0. FLAGGED AS ASSUMPTION — see Log A04. ───────────────────────────────────────────────────────────── ── SPEC COMPONENT 09 ──────────────────────────────────────── TYPE: Edge Case COMPONENT: Photo Upload Size / Format DETAIL: Large images slow uploads and eat storage on the free tier. CONFIDENCE: 70% BASIS: known platform behavior BUILDER ACTION: Constrain uploads with Bubble's file uploader max-size setting and accept common formats only (jpg/png). No external compression API — that would violate the no-paid-API constraint. ───────────────────────────────────────────────────────────── ── SPEC COMPONENT 10 ──────────────────────────────────────── TYPE: Scope Item COMPONENT: Weekend-Shippable Cut DETAIL: Feature set trimmed to what one person can build in a weekend on free tier. CONFIDENCE: 90% BASIS: 2 signals (ship-in-a-weekend + free-tier both stated) BUILDER ACTION: Ship 01–03 + basic friend flow first. Defer notifications, comments, and likes — none are in the idea and all add weekend risk. ───────────────────────────────────────────────────────────── ── SPEC COMPONENT 11 ──────────────────────────────────────── TYPE: Scope Item COMPONENT: No Push Notifications DETAIL: Real-time "new photo" alerts are excluded. CONFIDENCE: 80% BASIS: known platform behavior (push needs paid add-ons) BUILDER ACTION: Exclude push. Native push on Bubble typically needs a paid plugin/service — rejected under your no-paid-API constraint. ───────────────────────────────────────────────────────────── ASSUMPTIONS LOG ASSUMPTION 01 — Idea names no roles. Assumed single standard-user tier, no admin. 60%. ASSUMPTION 02 — Idea says "friends" but not how friendship forms. Assumed request→accept. 55%. ASSUMPTION 03 — Idea gives no cleanup mechanism. Assumed manual cleanup since automated/paid options are constrained out. 75%. ASSUMPTION 04 — Empty-feed behavior unstated. Assumed a friendly empty state. 65%. SCOPE FENCE IN: ephemeral 24h photo posts / friend feed / friend request-accept / basic upload OUT: comments / likes / push notifications / automated expired-photo deletion / DMs BUILDER NOTE: Biggest risk for Bubble is free-tier storage exhaustion from expired photos with no automated cleanup allowed. Fallback: cap upload size, cap history shown, and do manual periodic cleanup — all free-tier compliant. ◆ SIGNAL SCREEN: 11 components; 4 below the 70% threshold (04, 05, 08 plus 06 at boundary); flagged 04/05/08; the one decision gate to answer first — is friendship mutual-accept or one-way follow (05)?
🌀 Claude

App Idea To Buildable Nocode Spec

Add to Cart
Instant accessInstant access
Usage rightsCommercial use
Money-back guaranteeMoney‑back
By purchasing this prompt, you agree to our terms of service
CLAUDE-4-8-OPUS
Tested icon
Guide icon
4 examples icon
Free credits icon
Turn any one-line app idea into a numbered, buildable spec for your no-code or AI app builder. Outputs 10–12 SPEC COMPONENTS (core functions, user flow, data model, roles, edge cases) each with a confidence score and builder-specific action, plus an ASSUMPTIONS LOG, a SCOPE FENCE, and a one-line SIGNAL SCREEN. Every unstated decision is flagged, not silently made. Honors your constraints as hard limits and rejects anything that breaks them. Three variable slots.
...more
Added 3 weeks ago
Report
  • Reviews for this prompt (1)
Browse Marketplace