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 16 hours ago
