DEV Community: Sam Dreams Maker

Building a Freemium Model for Digital Content: Lessons Learned

Sam Dreams Maker — Fri, 03 Apr 2026 09:12:47 +0000

Freemium is deceptively simple: give something away for free, charge for the premium stuff. In practice, it's one of the hardest business models to get right — especially for digital content platforms.

I've spent the past year building and iterating on a freemium model for a creative writing platform. Here's what I learned about pricing, conversion, and the psychology of free.

The Freemium Trap

The most common mistake is giving away too much. If your free tier is "good enough," nobody upgrades. If it's too restrictive, nobody signs up.

The sweet spot: free users should hit a natural ceiling, not an artificial wall.

Bad example: "You can only create 3 documents." This feels punitive.

Good example: "Free users get unlimited writing, but export to EPUB requires a subscription." The value is clear — you're paying for a capability, not removing a restriction.

What We Tried (and What Worked)

Attempt 1: Feature Gating

Our first approach was classic feature gating. Free users got a basic editor; paid users got collaboration, export, and marketplace access.

Result: Low conversion (< 1%). Free users never experienced the features they'd be paying for, so they had no reason to upgrade.

Attempt 2: Usage Limits

We switched to usage-based limits — free users could create up to 5 projects, paid users got unlimited.

Result: Better (2.5% conversion), but users gamed it by finishing projects and deleting old ones. Also created anxiety about "wasting" a project slot on experiments.

Attempt 3: Value-Based Tiers

What finally worked was aligning tiers with user intent:

Free tier: Write, organize, and draft — everything a writer needs to create
Creator tier: Export, publish, and sell — everything a writer needs to distribute
Pro tier: Analytics, collaboration, and priority support — everything a team needs

This maps to a natural user journey: start writing for free, upgrade when you're ready to publish.

Result: 4.8% conversion rate, with most upgrades happening organically when users finished their first major project.

Key Principles I'd Follow Again

1. Let Free Users Fall in Love First

The writing experience on TaleForge is identical for free and paid users. No watermarks, no nag screens, no degraded experience. We want free users to write 50,000 words and think "this is amazing" before they ever see a paywall.

The moment a user creates significant content on your platform, switching costs are real. That's not lock-in — it's earned loyalty.

2. Make the Upgrade Moment Obvious

Don't hide premium features. Show them, let users click on them, and display a gentle upgrade prompt at the point of action. When someone clicks "Export to EPUB" and sees what the output looks like before paying, they convert at 3x the rate of someone who sees a pricing page.

3. Annual Plans Need a Real Discount

The standard advice is "offer 20% off for annual billing." In practice, we found that 40% off annual dramatically increased commitment without hurting revenue, because annual subscribers churn at 1/5 the rate of monthly subscribers.

Do the math: a $10/month user who churns after 4 months = $40. A $72/year user who stays = $72. Annual wins even at heavy discounts.

4. A Marketplace Changes Everything

The most powerful conversion lever we found wasn't a feature — it was a marketplace. When writers can sell their work on TaleForge's marketplace, the platform becomes a revenue source, not a cost. The subscription pays for itself with the first sale.

This flips the psychology entirely. You're not asking "do you want to pay for features?" You're asking "do you want to make money?"

Revenue Metrics That Matter

Forget vanity metrics. Track these:

Activation rate: What percentage of signups create their first project within 7 days?
Engagement depth: How much content do free users create before upgrading?
Time to upgrade: How long between signup and first payment?
Net revenue retention: Are existing customers spending more over time?

Our data showed that users who wrote more than 10,000 words in their first month converted at 12x the rate of casual users. So we optimized for engagement, not conversion — and conversion followed.

The Content Platform Challenge

Content platforms face a unique tension: your users' content IS your value. If free users create great content and share it publicly, they're marketing your platform for free. If you gate that behind a paywall, you lose the viral loop.

Our solution: free users can publish publicly. Paid users can sell. Everyone wins — free users get distribution, paid users get monetization, and the platform gets content and commerce.

What I'd Do Differently

Launch with fewer tiers. We started with 4 tiers and confused everyone. Two is ideal for launch (Free + Paid), expand later.
Build the upgrade flow before launch. We added payments 3 months in. By then, users had expectations about what was free.
Talk to churned users. Our best insights came from people who cancelled, not people who stayed.

Bottom Line

Freemium works for content platforms when:

Free users can create real value without friction
The upgrade path aligns with the user's growing ambitions
Premium features unlock distribution and monetization, not just convenience

The model isn't about converting free users into paying ones. It's about building something so useful that paying becomes the obvious next step.

Building a freemium product? I'd love to compare notes — drop your experience in the comments.

How to Organize a 100K-Word Novel: Chapter Management Tips

Sam Dreams Maker — Fri, 03 Apr 2026 09:11:49 +0000

Writing a novel is a marathon. At 100,000 words, you're looking at roughly 30-40 chapters, dozens of character arcs, and enough plot threads to lose yourself in. I've learned the hard way that without solid chapter management, a long-form project can collapse under its own weight.

Here's what actually works.

Why Chapter Management Matters

Most writers don't abandon novels because they run out of ideas. They abandon them because they lose track of where things are. That subplot you planted in chapter 7? You forgot about it by chapter 22. The character who was in Paris in chapter 12? Somehow she's in Tokyo two chapters later with no travel scene.

Chapter management isn't just organizational busywork — it's what keeps your story coherent at scale.

The Three Pillars of Novel Organization

1. Chapter Outlining (Before You Write)

You don't need a rigid outline, but you need waypoints. I use a loose structure:

Chapter number and working title — "Ch. 14: The Betrayal" is easier to navigate than "Chapter 14"
POV character (if multi-POV)
Scene goal — What changes by the end of this chapter?
Plot threads touched — Which storylines advance here?

This takes maybe 5 minutes per chapter and saves hours of rewriting later.

2. Progress Tracking (While You Write)

For a 100K-word novel, I break it into milestones:

Milestone	Word Count	What Happens
Act 1 End	~25,000	Inciting incident resolved, stakes clear
Midpoint	~50,000	Major reversal or revelation
Act 2 End	~75,000	Dark moment, all seems lost
Climax	~90,000	Final confrontation
Resolution	~100,000	Wrap-up

Tracking word count per chapter also reveals pacing issues. If your chapters average 2,500 words but one clocks in at 6,000, it probably needs splitting.

3. Chapter Reordering (After You Write)

This is where most tools fail you. You write chapter 8, then realize it works better as chapter 5. In a single Word document, that means cutting and pasting 3,000 words and hoping you didn't break any transitions.

Drag-and-drop chapter reordering is a game-changer. Tools like TaleForge handle this natively — each chapter is its own unit that you can move around without risking the rest of your manuscript. It sounds simple, but it fundamentally changes how you edit.

Practical Tips for Managing 30+ Chapters

Use Color Coding or Status Tags

Mark each chapter's status:

🔴 Not started
🟡 First draft
🟢 Revised
🔵 Final

This gives you a bird's-eye view of your novel's completeness without reading a single word.

Keep a Chapter Log

Maintain a simple spreadsheet or notes document:

Ch 1 — "The Letter" — 2,340 words — POV: Sarah — Status: Revised
Ch 2 — "Old Friends" — 3,100 words — POV: Marcus — Status: Draft
Ch 3 — "The Map" — 2,780 words — POV: Sarah — Status: Draft

This becomes your control panel. When your editor asks "which chapters still need work?" you can answer in seconds.

Write Chapters Out of Order

Here's a controversial take: you don't have to write linearly. If you're stuck on chapter 12, skip to chapter 15 where you know what happens. Writing out of order keeps momentum alive.

The catch? You need a tool that supports this without making a mess of your manuscript structure. I use TaleForge's chapter management for this — it lets me work on any chapter independently while maintaining the overall structure.

Scene Breaks Within Chapters

Long chapters often contain multiple scenes. Mark scene breaks clearly (I use *** or ---) and note the purpose of each scene. A chapter with three scenes should have three mini-goals that ladder up to the chapter's overall purpose.

Common Mistakes at the 100K Scale

Writing everything in one file. Your computer will slow down, your scrollbar becomes useless, and finding anything takes forever. Use a tool designed for long-form writing.

No backups. At 100,000 words, losing your manuscript is losing months of work. Cloud-based writing platforms handle this automatically. Local files need manual backup discipline.

Ignoring pacing data. If you're not tracking word counts per chapter, you're guessing at pacing. Data doesn't replace instinct, but it informs it.

Never restructuring. Your first chapter order is almost never your best chapter order. Be willing to move things around — and use tools that make it painless.

The Right Tool Matters

You can manage a 100K novel in Google Docs, but it's like using a butter knife to carve wood. Purpose-built writing tools like TaleForge offer chapter-level organization, word count tracking, and drag-and-drop reordering out of the box.

The best chapter management system is one you'll actually use. Start simple, stay consistent, and your novel won't outgrow your organizational system.

What tools and methods do you use to manage long-form writing projects? Drop your approach in the comments.

Building a Screenplay Editor: Lessons from TaleForge's Next.js Architecture

Sam Dreams Maker — Fri, 03 Apr 2026 09:02:16 +0000

Screenplay formatting is surprisingly complex. Every element — sluglines, action, dialogue, parentheticals — has strict industry standards. Here's what we learned building TaleForge's screenplay editor with Next.js.

The Challenge

Screenplays follow the Courier 12pt standard with precise margins:

Scene headings: ALL CAPS, left-aligned
Action: left-aligned, present tense
Character names: centered, ALL CAPS
Dialogue: centered, narrower margins
Parentheticals: centered, in parentheses

Most web editors treat text as a single format. Screenplays need context-aware formatting.

Architecture Decisions

1. TipTap as the Editor Core

We chose TipTap for its extensibility. Custom nodes for each screenplay element:

const SceneHeading = Node.create({
  name: 'sceneHeading',
  group: 'block',
  content: 'text*',
  // Auto-uppercase, left margin
  parseHTML() {
    return [{ tag: 'div[data-type="scene-heading"]' }]
  },
})

2. Auto-Detection

When a user types INT. or EXT., we auto-detect it as a scene heading. After pressing Enter on a character name, the next block becomes dialogue.

3. PWA for Offline Writing

Writers need to write anywhere. TaleForge uses service workers to cache the entire editor:

// sw.js - Cache screenplay editor assets
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open('taleforge-v1').then(cache => 
      cache.addAll(['/editor', '/fonts/courier.woff2'])
    )
  )
})

4. Prisma for Data

Each screenplay is stored with structured scene data:

model Screenplay {
  id        String   @id @default(cuid())
  title     String
  scenes    Scene[]
  author    User     @relation(fields: [authorId])
  authorId  String
}

Results

TaleForge now offers a free screenplay editor that:

Auto-formats as you type
Works offline as a PWA
Supports 10 languages
Includes a marketplace for publishing

The full platform also includes book and manga editors — making it possible to adapt a screenplay into a novel or graphic novel, all in one tool.

Try it free at tale-forge.com

Have you built rich text editors with custom formatting? What challenges did you face? Share in the comments!

5 Free Tools Every Manga Creator Needs in 2026

Sam Dreams Maker — Fri, 03 Apr 2026 09:02:13 +0000

Creating manga used to require expensive desktop software and years of training. In 2026, browser-based tools have changed everything.

1. TaleForge — Write & Create Manga in One Platform

TaleForge is a free creative writing platform that includes a dedicated manga/webtoon creator. What makes it unique is combining story writing with visual creation:

Panel layout system — drag and drop to design your pages
Integrated story editor — write your script alongside your panels
Built-in marketplace — publish and potentially sell your manga
Offline PWA — create manga even without internet
10 languages — including Japanese, Korean, and Chinese

Unlike standalone drawing tools, TaleForge understands that manga creation is storytelling first.

2. MediBang Paint

Great free drawing app with manga-specific brushes and tones. Desktop-only, no integrated publishing.

3. Canva

Useful for simple panel layouts, but lacks manga-specific features. Good for promotional materials.

4. Krita

Powerful open-source painting tool. Excellent for digital art but requires learning curve and has no publishing pipeline.

5. GIMP

The free Photoshop alternative. Can be used for manga with add-ons, but not purpose-built for it.

The Verdict

If you want an all-in-one manga creation experience — from writing your story to publishing it — TaleForge is the most complete free option. Start at tale-forge.com.

What tools do you use for manga creation? Let me know in the comments! 👇

Free Manga Creator Tools: How to Make Comics in Your Browser

Sam Dreams Maker — Fri, 03 Apr 2026 00:58:37 +0000

Want to create manga or webcomics but don't want to spend $50+ on software? Here are the best free browser-based tools.

The Challenge

Creating manga traditionally requires:

Expensive software (Clip Studio Paint ~$50, Photoshop ~$23/mo)
A drawing tablet (~$50-300)
Years of practice

But what if you just want to lay out panels, add speech bubbles, and tell your story? Not everyone needs professional illustration tools.

Browser-Based Manga Tools

1. TaleForge Manga Editor

TaleForge has a dedicated manga/webtoon editor built into its writing platform.

What you get:

Page templates (grids, L-shapes, diagonal splits, full bleed)
Drag-and-drop panel layouts
Speech bubbles with multiple styles (speech, thought, shout, whisper, narrator)
Webtoon vertical format with episode management
Built-in reader for your finished work
Export to PDF, PNG, or ZIP

Best for: Story-focused manga creators who want to plan panels and dialogue before (or instead of) detailed illustration.

Price: Premium feature (free trial available)

2. MediBang Paint

A full-featured drawing app available in the browser, on desktop, and mobile.

What you get:

1000+ free tones and brushes
Comic panel tools
Cloud storage and collaboration
Multi-page management

Best for: Artists who want to draw and illustrate digitally.

Price: Free (with ads)

3. Canva

Not specifically designed for comics, but surprisingly capable for simple panel layouts.

What you get:

Drag-and-drop layout builder
Text overlays and speech bubble shapes
Templates to start from
Easy export

Best for: Quick, simple comics without complex panel layouts.

Price: Free tier available

4. Pixton

A comic creation tool focused on characters and scenes.

What you get:

Pre-made character models
Scene backgrounds
Panel layouts
Dialogue bubbles

Best for: Beginners who want to make comics without any drawing skill.

Price: Free tier, premium plans available

Webtoon vs. Traditional Manga Format

Traditional manga:

Read right-to-left (Japanese style) or left-to-right (Western)
Fixed page sizes with panel grids
Printed format (tankōbon volumes)

Webtoon:

Vertical scroll format
Optimized for mobile reading
Published as episodes
Full-color typically

If you're starting out, webtoon format is more accessible — there's no complex page layout to worry about, and the vertical scroll format is natural for phone readers.

TaleForge supports both formats, letting you switch between traditional manga pages and webtoon vertical strips within the same project.

Getting Started: Your First Page

Plan your story — Even one page needs a beginning, middle, and end
Sketch a thumbnail — Rough layout of which panels go where
Choose a tool — Based on whether you want to draw or focus on story/layout
Create your panels — Start with a simple 4-panel layout
Add dialogue — Write speech bubbles
Share it — Post on your platform of choice

The hardest part is starting. Don't aim for perfection on your first page — aim for completion. You can always improve your next one.

Where to Publish

LINE Webtoon — Largest webtoon platform, competitive but huge audience
Tapas — Good for indie creators, monetization options
TaleForge Marketplace — Publish with built-in monetization
Instagram — Great for single-page comics
Twitter/X — Comic artists build huge followings here

The tools are free. The platforms are free. The only investment is your time and creativity. Start making comics. 🎨

The Best Wattpad Alternatives for Writers in 2026

Sam Dreams Maker — Fri, 03 Apr 2026 00:47:51 +0000

Looking for alternatives to Wattpad? Whether you've outgrown the platform, want more control over your work, or just want to explore what else is out there, here are the best options in 2026.

Why Writers Leave Wattpad

Wattpad pioneered social reading, but several issues push writers to look elsewhere:

Algorithm changes that buried established writers' work
Limited monetization — Wattpad Paid Stories has strict requirements
Mature content restrictions that affected many genres
No export options — your work lives on Wattpad's servers
Ad-heavy reading experience for free users

If any of these resonate, here are platforms worth exploring.

1. Royal Road

Best for: Fantasy, LitRPG, progression fantasy

Royal Road is the go-to for web fiction, especially in the fantasy genre. The community is engaged, the ranking system drives discovery, and readers actually leave detailed reviews.

Pros: Strong community, good discovery, free to use, reader engagement

Cons: Very genre-specific (fantasy dominates), no built-in monetization, basic editor

2. TaleForge

Best for: Multi-format writers (novels + manga + screenplays)

TaleForge takes a different approach — instead of being primarily a reading platform, it's a writing platform with publishing built in. The editor is significantly more capable than Wattpad's, with chapter management, word count goals, and export to EPUB/DOCX/PDF.

What makes it unique is the manga/webtoon editor and screenplay editor — if you work across formats, you won't find this combination elsewhere.

Pros: Professional-grade editor, manga + screenplay support, EPUB export, marketplace, 10 languages, offline mode

Cons: Smaller reader community (newer platform), manga/screenplay editors require premium

3. Tapas

Best for: Webcomics and short-form fiction

Tapas is strong in the webcomic space and has a growing fiction section. Their ad-revenue sharing and tipping system gives writers more monetization options than Wattpad.

Pros: Good monetization, mobile-first design, comic + fiction

Cons: Smaller audience than Wattpad, content guidelines can be strict

4. Scribble Hub

Best for: Web novels, translated fiction

Scribble Hub is popular with web novel writers and has a strong community of readers who follow serialized fiction. Less restrictive content policies than Wattpad.

Pros: Active community, less censorship, good tagging system

Cons: Niche audience, basic writing tools, no built-in monetization

5. Archive of Our Own (AO3)

Best for: Fan fiction

If you write fan fiction, AO3 is unmatched. The tagging system is incredibly detailed, the community is passionate, and there are no ads or algorithms — just chronological posting.

Pros: Best tagging system anywhere, no ads, passionate community, non-profit

Cons: Fan fiction only (no original fiction monetization), no writing tools

6. Kindle Vella

Best for: Serialized fiction with monetization

Amazon's answer to web fiction. Readers buy tokens to unlock episodes. The Amazon ecosystem means potential visibility, but discovery is challenging.

Pros: Amazon's reach, real monetization via tokens, professional platform

Cons: Difficult discovery, Amazon exclusivity requirements, US-only

Comparison Table

Platform	Editor Quality	Monetization	Export	Community Size
Wattpad	Basic	Limited	❌	Massive
Royal Road	Basic	Patreon links	❌	Large (fantasy)
TaleForge	Advanced	Marketplace	✅	Growing
Tapas	Basic	Ads + tips	❌	Medium
Scribble Hub	Basic	❌	❌	Medium
AO3	Basic	❌	✅	Large (fanfic)
Kindle Vella	Basic	Tokens	❌	Large

The Verdict

There's no single "best" alternative — it depends on what you write and what you need. If you want the biggest audience, Wattpad is still hard to beat. If you want better tools and control, TaleForge or Scrivener make more sense. If you write fantasy web fiction, Royal Road is home.

The good news: most of these platforms are free to try. Test a few, see where your work gets traction, and go from there.

How to Write a Screenplay: A Developer's Guide to Fountain Format

Sam Dreams Maker — Fri, 03 Apr 2026 00:47:50 +0000

If you're a developer who's ever thought about writing a screenplay, you'll love Fountain. It's like Markdown, but for screenplays.

What is Fountain?

Fountain is a plain-text markup syntax for screenwriting. Just like Markdown lets you write formatted documents in plain text, Fountain lets you write properly formatted screenplays.

Here's what it looks like:

INT. COFFEE SHOP - DAY

SARAH sits at a corner table, laptop open, typing furiously. Her coffee grows cold.

JAMES (30s, disheveled) approaches with two fresh cups.

JAMES
I brought reinforcements.

SARAH
(not looking up)
I'm in the zone. Come back in an hour.

JAMES
You said that two hours ago.

Sarah finally looks up. She sees the coffee. Smiles.

SARAH
Okay, maybe a five-minute break.

That's it. No special software needed. The formatting rules are intuitive:

Scene headings: Start with INT. or EXT.
Action: Regular paragraphs
Character names: ALL CAPS on their own line
Dialogue: Lines following a character name
Parentheticals: Text in (parentheses) between character and dialogue

Why Developers Love Fountain

Version control friendly — it's plain text, so git diff actually works
Editor agnostic — write in VS Code, Vim, whatever
Portable — no proprietary file formats
Convertible — tools exist to convert Fountain to PDF, HTML, Final Draft

Tools for Fountain

TaleForge — web-based screenplay editor with Fountain export, plus storyboard view for visualizing scenes
Highland — Mac app by John August (co-creator of Fountain)
WriterSolo — free desktop app
Afterwriting — open-source, runs in the browser

A Complete Example

Here's a short scene that demonstrates most Fountain elements:

Title: The Debug
Author: Your Name
Draft date: 2026-04-03

====

FADE IN:

INT. STARTUP OFFICE - NIGHT

A single desk lamp illuminates MAYA (20s), surrounded by energy drink cans and sticky notes. Three monitors glow with code.

MAYA
(muttering)
It's always a semicolon. Always.

Her phone BUZZES. She ignores it. It buzzes again.

ALEX (O.S.)
(through phone speaker)
Maya, go home. The deploy can wait.

MAYA
The deploy cannot wait. We launch tomorrow.

She types. A test suite runs. Red. All red.

MAYA (CONT'D)
No. No, no, no.

She pulls up the diff. Stares. Then slowly smiles.

MAYA (CONT'D)
It WAS a semicolon.

> FADE TO BLACK.

THE END

Industry Standard Formatting

When you export Fountain to PDF, it automatically follows industry formatting:

12pt Courier font
1.5" left margin for dialogue
Scene numbers can be auto-generated
Page breaks follow standard rules
One page ≈ one minute of screen time

This is the same format Hollywood uses. A script written in Fountain and exported to PDF is indistinguishable from one written in Final Draft ($250 software).

Getting Started

If you want to try writing a screenplay:

Start with a concept — what's your story about in one sentence?
Write a beat sheet — major plot points in order
Open any text editor and start writing in Fountain format
Use TaleForge's screenplay editor for real-time formatted preview

The barrier to entry for screenwriting has never been lower. You don't need expensive software, industry connections, or a film degree. You need a story and a text editor.

Happy writing. 🎬

Making a Writing App Work Offline: Service Workers and Cache Strategies

Sam Dreams Maker — Fri, 03 Apr 2026 00:15:19 +0000

Writers write everywhere — coffee shops with flaky wifi, airplanes, parks. A writing app that requires an internet connection is failing its users. Here's how I made TaleForge work offline.

The Requirements

The editor must work without internet
Changes must sync when connectivity returns
No data loss — ever
The user shouldn't have to think about any of this

Service Worker Strategy

I use a cache-first strategy for static assets (JS, CSS, images) and a network-first strategy for API calls.

// service-worker.js (simplified)
self.addEventListener('fetch', (event) => {
  const url = new URL(event.request.url);

  if (url.pathname.startsWith('/api/')) {
    // Network first for API calls
    event.respondWith(
      fetch(event.request)
        .catch(() => caches.match(event.request))
    );
  } else {
    // Cache first for static assets
    event.respondWith(
      caches.match(event.request)
        .then(cached => cached || fetch(event.request))
    );
  }
});

The Sync Problem

When a writer is offline and making edits, those changes need to be queued and synced later. I use IndexedDB as a local write-ahead log:

Every edit is saved to IndexedDB immediately (instant feedback)
A sync queue tracks pending changes
When online, the queue flushes in order
Conflicts are resolved by timestamp (last-write-wins)

Last-write-wins isn't perfect for collaborative editing, but for a single-author tool it's the right tradeoff — simple, predictable, and never loses the most recent work.

Auto-Save

The editor auto-saves every 30 seconds and on every significant pause (2 seconds of no typing). This is more aggressive than most writing tools, but data loss anxiety is real. Writers who've lost work to a crash never fully trust an app again.

The save indicator shows three states:

✓ Saved (green)
● Saving... (amber)
⚠ Offline — saved locally (gray)

That third state is crucial. The user needs to know their work is safe even without internet.

PWA Installation

TaleForge is installable as a PWA. The manifest.json defines:

{
  "name": "TaleForge",
  "short_name": "TaleForge",
  "start_url": "/dashboard",
  "display": "standalone",
  "background_color": "#0a0a0a",
  "theme_color": "#7c3aed"
}

When installed, it launches like a native app — no browser chrome, no URL bar. Writers get a clean, focused environment.

Cache Invalidation

The hardest problem in computer science, applied to a writing app.

Static assets use content-hashed filenames (Next.js does this automatically). When code changes, the hash changes, and the service worker fetches the new version.

For the editor itself, I version the service worker. Each deploy bumps the version, which triggers the activate event, which clears old caches:

const CACHE_VERSION = 'v2';

self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then(keys => 
      Promise.all(
        keys
          .filter(key => key !== CACHE_VERSION)
          .map(key => caches.delete(key))
      )
    )
  );
});

Results

Average time-to-interactive on repeat visits: ~800ms (cache-first)
Offline editor latency: indistinguishable from online
Data loss incidents since launch: 0

The best infrastructure is invisible. Writers using TaleForge don't know about service workers, IndexedDB, or sync queues. They just know their writing is always there when they open the app.

TaleForge — write anywhere, even offline

Building a Marketplace for Self-Published Authors: Architecture Decisions

Sam Dreams Maker — Fri, 03 Apr 2026 00:15:18 +0000

Most writing platforms treat publishing as an afterthought. Write your story, export a file, figure out distribution yourself. I wanted TaleForge to close that loop — write, publish, and sell in one place.

The Marketplace Model

The marketplace needed to support several publishing models:

Free publications (exposure-focused)
Paid publications (fixed price via Stripe)
Freemium (first N chapters free, rest behind paywall)
Tips (readers can tip authors they appreciate)

The freemium model turned out to be the most popular. It mirrors how web novel platforms like Royal Road and Tapas work: hook readers with free chapters, convert them on quality.

Stripe Integration

Payments run through Stripe Connect (Custom accounts). Each author is a connected account. When a reader buys a book:

Payment goes to the platform's Stripe account
Platform takes a cut (15%)
Rest is transferred to the author's connected account

The webhook handling was surprisingly tricky. Stripe sends events to your webhook URL, but if your domain redirects (e.g., example.com → www.example.com), the webhook gets a 307 redirect and fails silently. Lesson learned: always use the canonical URL.

// Webhook route - must return 200 quickly
export async function POST(req: Request) {
  const body = await req.text();
  const sig = req.headers.get('stripe-signature')!;

  const event = stripe.webhooks.constructEvent(
    body, sig, process.env.STRIPE_WEBHOOK_SECRET!
  );

  switch (event.type) {
    case 'checkout.session.completed':
      await handlePurchase(event.data.object);
      break;
    case 'customer.subscription.created':
      await handleSubscription(event.data.object);
      break;
  }

  return new Response('OK', { status: 200 });
}

The Discovery Problem

A marketplace is useless if readers can't find stories. I built several discovery mechanisms:

Search: Full-text search across titles, descriptions, and author names. Autocomplete suggestions as you type. Advanced filters by genre, length, rating, language, and price.

Discovery pages: Curated sections — trending (based on recent reads/purchases), new releases, top-rated, completed works, and staff picks.

Personalized recommendations: Based on reading history and genre preferences. Nothing fancy — collaborative filtering would be overkill at this scale. Simple "readers who liked X also liked Y" logic.

Genre browsing: 15+ genre categories with chip-style filters.

Publication Workflow

The publish flow needed to be simple but flexible:

Author marks a project as "ready to publish"
Sets metadata: description, genre, tags, cover image, pricing
Cover editor with cropping (2:3 ratio for book covers) and templates
Preview how it looks in the marketplace
Publish — immediately live

Updates sync automatically. Edit a chapter → the published version updates. No re-publishing needed.

What Worked

Freemium model: Higher conversion than fixed pricing. Readers who sample 3+ chapters buy at ~20% rate.
Cover editor: Authors without design skills can create decent covers. The 2:3 crop ratio and templates help a lot.
Reading progress: Saving where readers left off increases return visits.

What Didn't

Social features before content: I built reviews, reading lists, and follow systems before there was enough content to make them useful. Social features need critical mass.
Too many export formats: Supporting EPUB, DOCX, PDF, Fountain, manga PDF, webtoon PDF, and ZIP was technically fun but most users only need 1-2 formats.

Open Source?

The codebase isn't open source (yet), but I've shared the technical architecture freely. If you're building something similar, the key insight is: treat the marketplace as a first-class feature, not a bolt-on. Your data model, your editor, your export pipeline — they should all be designed with publishing in mind from the start.

Check it out at tale-forge.com — the book editor is free.

TaleForge by Dreams-Makers Studio

Internationalization in Next.js 16: Lessons From Supporting 10 Languages

Sam Dreams Maker — Fri, 03 Apr 2026 00:13:41 +0000

When I decided to support 10 languages in TaleForge from day one, I knew it would be work. I didn't know it would be this much work. Here's everything I learned.

The Setup

Stack: Next.js 16 App Router + next-intl. Why next-intl? It plays nicely with server components, supports namespaced messages, and handles pluralization rules per locale.

Languages supported: English, French, Spanish, German, Portuguese, Italian, Japanese, Chinese, Arabic, Hebrew.

Yes, that includes two RTL (right-to-left) languages. Yes, that was painful.

Message Organization

With 10 pages, dozens of components, and modals/forms everywhere, I quickly had hundreds of translation keys. Organization was critical.

I settled on one JSON file per locale with nested namespaces:

{
  "nav": {
    "home": "Home",
    "pricing": "Pricing",
    "blog": "Blog"
  },
  "landing": {
    "hero": {
      "title": "Stop fighting with tools to write your book",
      "subtitle": "A writing platform that works the way you think"
    }
  },
  "editor": {
    "save": "Save",
    "wordCount": "{count, plural, =0 {No words} one {1 word} other {# words}}"
  }
}

The namespace convention: page.section.key. This makes it easy to find keys and keeps related translations together.

The 1,326 Keys Problem

At last count, TaleForge has 1,326 translation keys across 10 locales. That's 13,260 individual translations.

How do you manage this without going insane?

Extract keys as you build. Never hardcode strings, even "just for now." Future you will forget.
Batch translations by feature. When building the manga editor, I wrote all English strings first, then translated the entire batch. Context helps — translating strings in isolation leads to weird results.
Use ICU message format. {count, plural, one {1 project} other {# projects}} handles pluralization correctly across languages. Japanese doesn't have plural forms. Arabic has six. ICU handles it.
Audit regularly. I built a script that checks for missing keys across locales. Run it in CI. Missing translations should break the build.

RTL Support

Arabic and Hebrew read right-to-left. This affects:

Text direction (obviously)
Layout direction (sidebars swap sides)
Icon direction (arrows flip)
Number formatting
Calendar direction

The CSS approach: use logical properties everywhere.

/* Don't do this */
.sidebar { margin-left: 20px; }

/* Do this */
.sidebar { margin-inline-start: 20px; }

Logical properties (margin-inline-start, padding-inline-end, border-block-start) automatically flip in RTL mode. If you're starting a new project, use them exclusively. The browser support is excellent.

For the dir attribute, I set it on the <html> tag based on the current locale:

const rtlLocales = ['ar', 'he'];
const dir = rtlLocales.includes(locale) ? 'rtl' : 'ltr';

Date and Number Formatting

Never format dates or numbers manually. Use Intl.DateTimeFormat and Intl.NumberFormat.

// Dates
new Intl.DateTimeFormat('ja', { 
  dateStyle: 'long' 
}).format(date);
// → "2026年4月3日"

// Numbers  
new Intl.NumberFormat('de', {
  style: 'currency',
  currency: 'USD'
}).format(9.99);
// → "9,99 $"

The Intl APIs handle locale-specific formatting rules automatically. Arabic uses Eastern Arabic numerals (٠١٢٣). Japanese dates use year-month-day. German uses comma for decimals. Don't reinvent this.

Dynamic Content

Static UI text is straightforward. Dynamic content — user-generated stories, comments, reviews — is trickier.

I don't translate user content. The platform UI adapts to the user's language, but stories are displayed in whatever language the author wrote them in. This is a deliberate choice: machine-translating creative writing produces terrible results.

What I do translate: metadata. Genre names, status labels ("Published," "Draft"), system notifications. These come from a fixed set and can be pre-translated.

Performance Considerations

10 locale files × 1,326 keys = a lot of JSON. Loading all of it on every page would be wasteful.

next-intl supports message splitting — only load the messages needed for the current page. With Next.js App Router, each layout or page can specify which namespaces it needs:

export default async function PricingPage() {
  const t = await getTranslations('pricing');
  // Only 'pricing' namespace is loaded
}

This keeps the client bundle lean. The full message files are only used server-side.

Testing

I test i18n with two approaches:

Snapshot tests for critical pages in each locale. This catches layout breaks (German words are notoriously long) and missing translations.
Visual regression for RTL layouts. A sidebar that looks perfect in English might overlap content in Arabic.

The most common bug: hardcoded strings that bypass the translation system. A code review checklist item: "Are there any raw strings in the JSX?"

Lessons Learned

Start with i18n on day one. Retrofitting is 10x harder than building it in.
RTL is not just direction: rtl. It touches layout, icons, animations, and user expectations.
Professional translation > machine translation for user-facing text. But machine translation is fine for a first pass that you refine.
10 languages is probably too many to start with. English + 2-3 major languages would have been more practical. I added Japanese, Chinese, Arabic, and Hebrew because the writing community is global — but maintaining 10 locales is a real cost.

The result: about 40% of TaleForge's traffic comes from non-English speakers. For a writing platform, that's significant.

TaleForge — free creative writing platform supporting 10 languages

Building a Manga Editor in the Browser: Canvas, Panels, and Speech Bubbles

Sam Dreams Maker — Fri, 03 Apr 2026 00:12:59 +0000

Building a browser-based manga editor sounded crazy. Turns out, it was only mostly crazy. Here's how I did it for TaleForge.

Why Build This?

Manga creators have limited tooling options. Professional tools like Clip Studio Paint are expensive and desktop-only. Free alternatives are either too simple or too complex. I wanted something in between — a browser-based editor that handles the unique layout challenges of manga and webtoons.

The Panel System

Manga pages are grids of panels, but not regular grids. Panels overlap, bleed to the edge, vary wildly in size and shape. The first challenge was representing this flexibility.

I went with a template-based approach. Instead of freeform panel drawing (which is powerful but overwhelming for beginners), I offer layout templates:

Standard grid (2×2, 3×2, etc.)
Vertical strips (for webtoons)
L-shaped panels
Diagonal splits
Full bleed (single panel)

Each template defines panel positions as percentage-based coordinates, so they scale to any page size.

interface PanelLayout {
  id: string;
  name: string;
  panels: {
    x: number;      // % from left
    y: number;      // % from top  
    width: number;  // % of page width
    height: number; // % of page height
  }[];
}

Speech Bubbles

Speech bubbles are positioned relative to their parent panel. Each bubble has:

Position (x, y as percentages within the panel)
Text content
Style (speech, thought, shout, whisper, narrator)
Tail direction (pointing to the speaker)

The tricky part was making bubbles draggable within panels while keeping them responsive. I used CSS transforms for positioning and pointer-events management to handle the layering between panels and bubbles.

The Webtoon Format

Traditional manga is read right-to-left in pages. Webtoons are read top-to-bottom in a continuous scroll — a completely different format.

Instead of pages with panel grids, webtoons use vertical sections. Each section is a horizontal strip that can contain an image. Sections are reorderable via drag-and-drop.

The reader component uses IntersectionObserver to:

Lazy-load images as they enter the viewport
Track reading progress (which section is currently visible)
Save the last-read position so readers can resume later

const observer = new IntersectionObserver(
  (entries) => {
    entries.forEach((entry) => {
      if (entry.isIntersecting) {
        // Load image
        const img = entry.target.querySelector('img[data-src]');
        if (img) {
          img.src = img.dataset.src;
        }
        // Track progress
        updateReadingProgress(entry.target.dataset.sectionIndex);
      }
    });
  },
  { rootMargin: '200px' } // Start loading 200px before visible
);

Page Management

A manga project has multiple pages (or episodes for webtoons). The thumbnail strip on the left shows all pages with miniature previews. You can:

Add pages with a layout picker (click "+" and choose a template)
Reorder pages via drag-and-drop
Delete pages with confirmation
Switch between pages instantly

The thumbnail strip was one of those "simple-looking" features that took way longer than expected. Generating accurate thumbnails of canvas content, keeping them in sync when panels change, and making the drag-and-drop feel right — each of these was its own rabbit hole.

Export

Manga pages export as:

PNG/JPG per page (for individual sharing)
PDF (for print-ready output with proper bleed)
Webtoon PDF (continuous vertical format)
ZIP (all pages bundled)

The PDF generation uses the page dimensions and panel coordinates to render at print resolution (300 DPI), not screen resolution.

What I Learned

Canvas is powerful but low-level. For complex interactive graphics, you end up building a mini rendering engine. Consider libraries like Fabric.js or Konva if starting from scratch.
Percentage-based coordinates are your friend. Pixels break when you resize. Percentages scale naturally.
The undo/redo system is critical. Creative tools without undo are unusable. Implement a command pattern early.
Mobile is a different world. Touch targets need to be 44px minimum. Pinch-to-zoom on canvas elements requires custom gesture handling. The manga editor works on tablets but I wouldn't recommend it on phones — the screen is just too small for panel editing.

Try It

The manga/webtoon editor is part of TaleForge (premium feature). If you're building something similar, I'm happy to discuss architecture decisions in the comments.

Part of the TaleForge creative writing platform by Dreams-Makers Studio

How I Built a Creative Writing Platform With 3 Different Editors

Sam Dreams Maker — Fri, 03 Apr 2026 00:12:25 +0000

I spent the last few months building TaleForge, a creative writing platform that supports three completely different types of storytelling. Here's what I learned.

The Problem

Writers don't just write novels. Some write manga. Some write screenplays. But most writing tools only handle one format — usually just plain text with some formatting.

I wanted to build something that handled all three, with each editor purpose-built for its medium.

The Three Editors

1. Book Editor

A rich text editor built with Tiptap for long-form fiction. Chapter management, word count goals, writing streaks, and exports to EPUB, DOCX, and PDF.

The key insight: writers need distraction-free writing, not more features crammed into the toolbar. So the editor is minimal by default, with advanced features accessible but not in your face.

2. Manga & Webtoon Editor

This was the hardest one. A canvas-based panel editor where you can create pages with different layouts, add speech bubbles, and arrange panels.

For webtoons specifically, I added vertical section editing with drag-to-reorder, because webtoons are consumed vertically (think scrolling on your phone).

The reader component uses IntersectionObserver for lazy loading and saves reading progress per episode.

3. Screenplay & Animation Editor

Proper screenplay formatting (scene headings, action, dialogue, parentheticals) with Fountain-compatible export.

Plus a storyboard view where you can visualize scenes as cards and rearrange them.

Technical Decisions

Stack: Next.js 16, Prisma, PostgreSQL (Railway), deployed on Vercel.

Why Next.js 16: App Router with server components made the data-fetching story much cleaner. Server actions for mutations, RSC for reads.

Why Prisma: The type safety is worth the occasional ORM frustration. Having your database schema generate TypeScript types that flow through your entire app catches bugs before they happen.

Internationalization: 10 languages from day one using next-intl. This was a pain to set up but worth it — about 40% of my traffic comes from non-English speakers.

Offline support: Service worker with a cache-first strategy for the editor. Writers don't always have internet, especially when they're writing at a coffee shop or on a plane.

The Marketplace

Writers want readers. So I built a marketplace where you can publish your work, set pricing (free or paid with Stripe), and build a readership.

The freemium model lets authors offer the first N chapters free and gate the rest behind a purchase. This is how most web novel platforms work, and it aligns incentives — readers sample before buying, authors get rewarded for writing compelling hooks.

What I'd Do Differently

Start with one editor, not three. Building three editors simultaneously was ambitious. I should have launched with just the book editor, validated demand, then expanded.
Invest in SEO earlier. I spent months building features without thinking about how people would find the platform. Content marketing and SEO should start on day one.
Talk to users before building. I built what I thought writers wanted. Turns out, what writers actually want is simpler than you'd expect — reliable auto-save, good export, and no vendor lock-in.

Try It

If you're a writer (or want to be), check it out. The book editor is free with up to 3 projects.

I'd love feedback from the dev.to community — especially on the technical architecture. What would you have done differently?

Built by Dreams-Makers Studio