A shared build log for the decisions, proof, feedback, and launch state behind this project.
Build the smallest working version that can earn real feedback from real users.
Advance when someone outside the team can use the product and react to the value.
Share working proof and the tradeoff you need feedback on.
This phase helps followers understand what kind of feedback is useful right now.
Every update stays connected to the project arc, so followers can understand what changed and where feedback would help.
This was the #1 gap for game devs on ShipSignal. You can't build a build-in-public platform for visual work and force people to host their own media. What changed: - Added POST /api/media/upload to receive multipart uploads - Files go to R2 (shipsignal-media bucket) with signed/permanent URLs - Validation on type (PNG/JPEG/GIF/WebP/MP4/WebM) and size (10 MB images, 50 MB video) - The composer already had the UI — it was just calling an endpoint that didn't exist. Fixed. The composer now inserts uploaded media as markdown images or `<video>` tags automatically. One decision I wrestled with: we validate on MIME type AND extension. Strict, but it keeps the R2 bucket clean of malicious uploads. We can relax later if creators hit edge cases. Next: captions, alt text, and maybe a lightweight media gallery per project.
Feedback ask: For your projects, what media workflow matters more: drag-and-drop speed, or strict organization/galleries? What breaks first?
We just closed the biggest pre-launch risk gap: the platform infrastructure underneath the product. Shipped: - analytics_events table + aggregate tables so every signal, launch, and funnel event actually lands somewhere - Cookie consent banner on every page (no more "we use cookies" footnote hiding in /privacy) - Account export (GET /api/users/me/export) and account deletion (DELETE /api/users/me) endpoints - Settings UI for both, plus email notification preferences Why this matters: A build-in-public platform has to be trustworthy before it's viral. If we can't tell creators where their data is or let them leave cleanly, we don't deserve their work. The boring truth is that GDPR/CCPA readiness, analytics storage, and export/delete are day-one table stakes — and we almost shipped without them. Caught it in review. Proof: - 243/251 tests passing - Build green at 7.78 MB worker + 12 client bundles - schema.sql now has analytics and notification_preferences tables
Feedback ask: If you were choosing a platform to build your next project in public, what privacy or data promise would make you actually trust it? What would make you distrust it?
The build-in-public platform is itself built in public. We deployed to getshipsignal.com this afternoon. The landing page is serving all 8 wireframe sections. The app has 10 routes — dashboard, composer, circles, analytics, settings, billing, project pages, feedback, waitlist, auth. The database has 14 tables, D1 at 0.20MB. The worker is 5.9MB, startup time 14ms on Cloudflare's edge. What's live right now: • Public project pages with timeline, feedback islands, circle-gated content • Dashboard with momentum meter, weekly heatmap, project cards, quick-post • Circles with feed tab (circle-scoped updates from all members) • Composer with 5 update types, 3 visibilities, 7 feedback modes, media upload • Audience analytics with 4 metric cards, 12-week chart, top updates table • Settings with custom domain management • Tier 1 upgrade gates (all behind feature flag, off during alpha) • Tier 2 premium features (analytics, media, domains — gates off during alpha) What's gated for post-alpha: project limits (free = 1), circle limits (free = 1), private/circle visibility (free = public only), audience analytics (free = basic blurred preview), custom domains (Maker+). The founding cohort gets everything free while we're in alpha. Flip productGatesEnabled when we hit 50 active builders. Next: R2 media bucket, waitlist share URLs, onboarding flow, launch center/maiden voyage mechanic.
Feedback ask: What's missing from the MVP that would make you actually use this instead of Twitter threads for your next project?
Shipped the circle integration today. When you post an update with Circle visibility, it now scopes to that specific circle — members see it in their feed, non-members see a locked gate card with a join CTA. The whole thing is backed by a new circle_id column on updates with a membership check in the query layer. The nice part: circles went from a dead standalone page to being woven into the composer, the dashboard activity feed, and the public project page. Three surfaces, one data model.
