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)?
By purchasing this prompt, you agree to our terms of service
CLAUDE-4-8-OPUS
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
- Reviews for this prompt (1)
