Building Juzi Book House: An Online Novel Platform with SvelteKit, Supabase, and Stripe

Where the Idea Came From

I love reading online fiction. If you have ever fallen down a rabbit hole on Webnovel or Royal Road at midnight, you know exactly what I mean — you tell yourself one more chapter and suddenly it is 2 AM. Those platforms proved something important: readers will happily pay for good serialized stories, and writers can build real careers publishing one chapter at a time.

But I kept noticing a problem. Most of these platforms take a huge cut from authors, offer almost no control over how their work is presented, and treat writers more like content suppliers than creative partners. I thought: what if someone built a platform that actually put authors first? That question turned into Juzi Book House.

What the Platform Actually Does

Before I get into how I built it, here is what Juzi Book House looks like from a user's perspective:

• One account, two roles: You can be a reader and an author at the same time. There is no separate login — just a toggle in your dashboard that switches between reading mode and writing mode.
• Subscription membership: Readers pay a monthly or annual fee to unlock premium chapters, skip ads, and get early access to new releases. Authors earn a share of that pool based on how many pages their readers consume.
• Chapter comments: Every chapter has a comment section where readers can react in real time. An author posting a new chapter on Saturday morning can watch the comments roll in live — it is surprisingly motivating.
• Virtual gifts: Readers can send gifts (think digital roses, gold coins, that kind of thing) directly to authors as a tip. It is a small gesture but authors tell me it means a lot.
• Author CMS: Writers get a full dashboard for managing their novels — chapter editor, scheduling, analytics, and earnings all in one place. No third-party tools needed.

Picking the Right Tech Stack

A novel platform has two very different performance requirements. For readers, pages need to load instantly and scroll smoothly through thousands of words. For authors, the CMS needs to feel responsive and save drafts without losing work. I needed a stack that handled both well.

SvelteKit for the Frontend

I chose SvelteKit and I am really glad I did. Reading a chapter is an inherently quiet, focused activity — the last thing you want is a JavaScript-heavy page fighting for CPU time while someone is trying to lose themselves in a story. SvelteKit compiles to lean output and the server-side rendering means the first paint happens before any JS even runs. On a mid-range Android phone on a 4G connection, chapters load under a second.

The reactivity system also made the comment section and gift animations feel alive without a lot of extra code. When someone sends a gift, a little animation fires and the author's balance ticks up in real time — that kind of polish matters more than it sounds.

Supabase for the Backend

Supabase did a lot of heavy lifting here. I was able to replace what would have been three separate services — authentication, database, and real-time messaging — with a single integration.

• Auth with roles: Authors and readers share the same login system but get completely different dashboards. Row-Level Security means the database itself enforces who can see what — authors can only edit their own novels, and free-tier readers cannot query the body of a premium chapter no matter what.
• PostgreSQL for data integrity: Relational data fits this project perfectly. A chapter belongs to a novel, a comment belongs to a chapter, a gift has a sender and a recipient. These relationships need to be rock solid.
• Real-time subscriptions: When a reader posts a comment, everyone else on that chapter page sees it appear instantly. No polling, no refresh — it just shows up. This one feature generates more positive feedback from users than almost anything else.

Stripe for Payments

I was not going to build my own payment processing. Full stop. Stripe Connect handles subscriptions, one-time gift purchases, and author payouts. The compliance stuff — tax forms, identity checks, international transfers — Stripe deals with all of that so I do not have to.

The gift flow in particular would have been painful to build from scratch. A reader buys credits, spends them on a gift, the platform takes a small cut, and the author gets the rest deposited to their bank account on a weekly schedule. Stripe makes that whole chain straightforward.

The Author Dashboard: Getting the Details Right

The CMS was the feature I spent the most time on, and honestly the one I am most proud of. Authors told me that on other platforms, managing their work felt like fighting the software. I wanted the opposite experience.

The dashboard lives at /dashboard/* and only authors can access it. Here is what it includes:

• Novel management: Create a novel, upload a cover, write a synopsis, tag it by genre. Set which chapters are free and which require a subscription — you can mix and match per novel.
• Chapter editor: A clean rich-text editor with auto-save. You can write a draft, preview it exactly as readers will see it, then schedule it to publish at a specific time. No more pasting from Google Docs and fixing broken formatting.
• Drag-and-drop ordering: Reorder chapters by dragging them. If you realize chapter 12 flows better before chapter 11, just move it. Reader progress tracking updates automatically.
• Analytics: See how many readers started each chapter, how many finished, and where they dropped off. It sounds simple but authors use this to figure out which scenes are landing and which are losing people.
• Earnings: A live view of your subscription revenue share and gift income, with a history of past payouts. No mystery about where your money comes from.

How Premium Content Gating Works

This was the trickiest technical piece to get right. Each novel has a free chapter threshold — maybe the first 20 chapters are free, everything after that requires a subscription. The question is: how do you enforce that without relying purely on the frontend?

The answer is Supabase Row-Level Security. The RLS policy on the chapters table checks whether the requesting user has an active subscription before returning the chapter body. A free reader gets the metadata — title, word count, chapter number — but the actual text comes back empty. Even if someone digs through the network requests, there is nothing to intercept because the server never sent it.

When a reader subscribes via Stripe, a webhook fires and updates their subscription status in Supabase within seconds. The access change is instant — no refresh required, the chapter just unlocks in place.

The Gift System Under the Hood

Here is the full flow of a gift from tap to payout:

1. A reader buys a bundle of gift credits through a Stripe one-time payment. Credits land in their wallet immediately on payment confirmation.
2. They tap the gift button on a chapter and pick a gift. Credits are deducted from their wallet and added to the author's balance in the same PostgreSQL transaction — so there is no way to spend credits twice.
3. Every Friday, the platform settles all author balances via Stripe Connect transfers. Authors see the deposit in their bank account within a couple of business days.

The atomic transaction part matters more than it sounds. If the debit from the reader's wallet and the credit to the author's balance were two separate operations, a crash between them could either lose credits or create credits out of thin air. Doing both in one transaction means it is all-or-nothing.

Problems I Hit and How I Solved Them

Long Chapters Were Killing Mobile Performance

Some of our authors write long chapters — 8,000 to 10,000 words is not unusual in the fantasy genre. Dumping all of that into the DOM at once caused noticeable jank on phones, especially mid-range Android devices.

The fix was virtual scrolling: only the paragraphs actually visible in the viewport get rendered. As you scroll down, new paragraphs are added to the bottom and old ones are removed from the top. Memory usage stays flat no matter how long the chapter is. It took about a week to implement properly but the smoothness improvement was immediately obvious.

Webhooks Are Unreliable in the Real World

Stripe sends webhooks when subscriptions change, but webhooks get dropped. Network blips, server restarts, deployment windows — any of these can cause a webhook to miss. If a subscription cancels and the webhook is lost, the reader keeps access they should not have.

I handle this two ways. First, every incoming webhook is logged with an idempotency key, so if Stripe retries a failed delivery I do not double-process it. Second, a nightly job fetches the current subscription state for all users directly from Stripe's API and reconciles anything that got out of sync. Belt and suspenders.

Paying Authors Internationally

Tax compliance for creator payouts is a surprisingly deep rabbit hole. US-based authors need 1099 forms. Canadian authors have different rules. European authors have their own. I was not going to build a tax compliance engine.

Stripe Connect handles all of it. Authors onboard through Stripe's own identity verification flow and provide their tax information directly to Stripe. The platform never sees or stores any of that — we just trigger the payouts and Stripe deals with the rest.

How Things Look Six Months In

Juzi Book House launched in early 2026 and the early numbers are genuinely encouraging:

• 120+ authors actively publishing, ranging from hobbyists to people treating it as a serious side income
• 2,500+ reader accounts, with about a third on a paid subscription
• $15,000+ in gift revenue distributed to authors in the first quarter alone
• 72% chapter read-through rate — readers who start a chapter finish it. The industry average is closer to 45%.
• Sub-0.8 second load times for chapter pages on 4G, which is what most of our mobile readers are on

What Surprised Me Along the Way

Authors care more about the CMS than the reader-facing features

I expected readers to drive most of the feedback. Instead, authors were the most vocal early users. When they told me the chapter editor felt good to use, engagement went up. When something broke in the dashboard, they noticed immediately. The lesson: without good authors, you have no content, and without good content, you have no readers. Make the author experience your top priority.

Real-time comments change how stories feel

This one genuinely surprised me. Authors told me that seeing comments appear while they were still online after posting a chapter felt completely different from checking comments the next day. It created this live, communal moment around a new release. Several authors said it is the main reason they have stuck with the platform — that immediate feedback loop is addictive in the best way.

The paywall position matters enormously

In the early version I put the subscription wall too early — chapters 10 and beyond were locked. Readers bounced before they were invested. I pushed the free threshold out to chapter 20, which gives readers enough time to genuinely care about the characters. Subscription conversions roughly doubled. The principle: let them fall in love with the story first, then ask them to pay.

Things I Would Do Differently

• Offline reading from day one. Most of our readers are on mobile and commute on transit where connections drop. Service worker caching for downloaded chapters is on the roadmap but I wish it had been there at launch.
• A recommendation engine sooner. Right now discovery is mostly browse-by-genre. A simple collaborative filter — readers who liked X also liked Y — would increase how many novels each reader samples.
• i18n from the start. We have readers from several countries and retroactively adding internationalization support is painful. If you think you might have an international audience, bake i18n in before you write your first component.

Takeaways If You Are Building Something Similar

A few things I would tell anyone starting a creator platform:

• Put your creators first, always. They are your supply side. Without them you have nothing to offer readers. Every product decision should ask: does this make creators more successful?
• Use Stripe Connect for any platform paying multiple parties. The compliance burden of handling creator payouts yourself is enormous. Stripe does it better than you will.
• Enforce access control at the database level. A frontend paywall is a suggestion. RLS is a lock. Gate premium content in the database, not just in your UI.
• Invest in reading performance. Fast scrolling and fast loads are table stakes for a reading platform. Users will not consciously notice when it is good, but they will immediately leave when it is bad.
• Make the tip/gift experience feel personal. The money is secondary — it is the acknowledgment that matters. An animation, a notification, a public thank-you note in the comments from the author. These small moments drive far more gifting than the amount of money involved would suggest.

Building Juzi Book House was one of the most enjoyable projects I have worked on because the domain is genuinely interesting to me. Good stories deserve good platforms. I think we are building one.