Where stories trade
A reading marketplace that gives independent authors a fair way to publish and get paid, and gives readers a calmer way to find stories worth their time.
New authors publish into a void: no fan base, no marketing budget, and no clear view of how their earnings are calculated. Readers have the mirror problem, scrolling past the same mainstream titles while niche genres stay buried behind paywalls placed before the first chapter.
Storade was designed as a two-sided marketplace where discovery, feedback and revenue all happen in the open.
Without an existing audience or marketing knowledge, good work simply stays unread.
Authors can't see how a split is calculated, and readers have no light-touch way to support them.
Niche titles are overshadowed, and there is no reliable signal for when a followed author publishes.
Build one product that serves two opposing users without either side feeling like the compromise.
I started with competitor research across existing serialized-reading platforms, looking specifically at how each one handles promotion, payment and author-to-reader communication. I then spoke with readers and aspiring authors about where those systems break down in practice.
The findings split cleanly into two target groups. Every feature that made it into the product traces back to a need or pain point below.
Authors and readers share an account, a library and a navigation model. Rather than building two apps, I mapped both journeys onto a single flow and marked the points where the interface changes perspective: publishing tools appear for authors, following and support tools appear for readers.
The full flowchart covers account creation, genre onboarding, browsing, reading, publishing, monetisation and settings, including every error and empty state.
Every screen was wireframed in greyscale for both platforms before any colour was applied. Mobile carried the reading experience; desktop carried browsing, publishing and account management. Feedback from this stage was applied to the structure rather than to individual screens, which kept the two platforms from drifting apart.
In a world where stories hold more value than words, Storade is a space where writers and readers connect, exchange inspiration, and embark on journeys through text. We are more than just a marketplace for books, we are a community of stories where everyone can share and discover something new.
Our S logo is more than just a letter; it symbolizes the flow of narratives, derived from the base of a book, representing the evolution of ideas as they travel from the writer's pen to the reader's eyes.
The mark holds at icon scale without the wordmark, staying legible next to system apps.
Open Sans across the whole product, in three weights, on a blue-to-navy scale that keeps long-form text comfortable in both light and dark reading modes. Navigation, buttons, chips and dropdowns were built as variant sets, so a change to a component propagated to every screen instead of being repainted by hand.
Mobile first, then the responsive web build. The four flows below are the ones that carry the product: getting in, reading, publishing, and keeping up with authors.
Readers can preview the marketplace before signing up. Picking three favourite genres seeds recommendations immediately, so the home screen is never empty on first open.
A novel page leads with free chapters, ratings and genre tags before it asks for anything. Text size, weight and night mode are adjustable from inside the chapter, so the reading screen adapts instead of forcing a settings detour.
The publishing flow separates the creative decisions from the commercial ones. Story details come first, then publishing mode, payment and rights, then upload. Nothing about money is hidden behind a second screen.
Night mode was designed as its own set of tokens rather than a filter over the light theme, so cover art keeps its contrast and body text stays soft enough for long sessions.
On the web the tab bar becomes a persistent header, and the extra width goes to browsing and to the author's chapter management, where seeing many rows at once genuinely helps.
Development received the file with named components, documented states and spacing taken from the system rather than measured off individual screens. Working through implementation questions with the team is also where several details were simplified: anything that needed a paragraph of explanation to build usually needed a paragraph of explanation to use.
The biggest takeaway was learning how to balance user needs, business requirements, and technical constraints while keeping the experience clear and consistent. It also improved how I structure design decisions and communicate them with the team.