Story256
A collaborative storytelling app where stories grow one fragment at a time. Built from concept to App Store by ZubiLabs.
- Own product
- [2018]–present
- iOS & Android
- Role: everything
- Status: live
Story256 is a mobile app for collaborative fiction. Users start a story with a short fragment, and other users continue it. Each story can branch: at any fragment, someone can take the narrative in a different direction, so a single opening can grow into a tree of stories. Fragments are limited in length, and each user contributes a small amount per day, which keeps the pace slow and the quality high.
It started as a personal project with a simple question: what would collaborative writing look like if it were designed for phones and for people with five minutes a day? It became the reference product for ZubiLabs because it covers the entire lifecycle of a digital product, not just the code.
Collaborative writing tools exist, but they are built for desktops, long sessions and committed writers. On mobile, the experience is either a forum or a notes app. The product had to solve three things at once: make contributing feel easy and low-stakes, keep stories readable when dozens of people contribute, and find a business model that works for a niche creative app without ads.
On the engineering side, the problem was building all of that as one person: mobile app, backend, payments, stores, monitoring, landing page and launch, with a codebase that could keep evolving after launch.
A React Native app for iOS and Android with a single core loop: read, continue or branch. The daily limit and the fragment length are product decisions, not technical constraints: they make each contribution feel deliberate. Branches are visualised as a tree so readers can follow one path or explore alternatives.
The app is built with Expo and TypeScript, with a Node.js backend on PostgreSQL. Authentication, subscriptions, analytics and crash reporting were in place before the first public build, because a product without measurement cannot be iterated.
Everything. Concept, product design, UX/UI, mobile development, backend, database, authentication, subscriptions, App Store and Google Play publishing, CI with EAS, monitoring with Sentry, landing page on Vercel, DNS, analytics, marketing and launch. This is unusual and it is the point: it shows that ZubiLabs can own a product end to end, not just a slice of it.
Key decisions, and why:
- Expo managed workflow with EAS. One codebase, both stores, over-the-air updates for fixes that do not touch native code. The trade-off is less control over native modules; for this product it never mattered.
- A relational database for a tree-shaped domain. Stories, fragments and branches form a tree, which tempts people towards a document store. PostgreSQL keeps the data consistent and the queries simple, and it is easier to reason about when the model changes.
- RevenueCat for subscriptions. Receipts, renewals, grace periods and cross-platform entitlements are a full-time job. Delegating them lets the app focus on the product.
- Measurement from day one. Sentry and analytics were added before launch, not after the first bug report.
- Branching without confusion. A story with dozens of branches is a graph, not a list. The tree view went through several iterations before readers could follow a path without getting lost.
- Subscriptions across two stores. Restoring purchases, handling a cancelled Android subscription while iOS is active, and testing all of it in sandbox.
- Shipping alone. With one person, the bottleneck is attention. CI with EAS, OTA updates and error monitoring were built early precisely so that releases would not depend on remembering steps.
Story256 is live on the App Store and Google Play.More importantly for ZubiLabs, it is a product that exists, with real users, real payments and real operational problems, built by the same person who will build yours.
- Launch earlier. The first version had features nobody used and lacked the one everybody asked for.
- Measurement is a feature. The first weeks without proper analytics were guesses.
- The store review process is part of the timeline. Plan for it.