Status:      Archived
            Period:      2020-2021
            Technology:  React, TypeScript, Fastify, Stripe, Docker, Caddy, Postmark
            Source Code: Limited, on request
          

Screenshot

The public homepage introducing Mysli Write, its design language, and the principles behind the product.

Introduction

Mysli Write was a privacy-focused writing platform designed for people working on long-form and structured content: books, journals, podcast scripts, research notes, and personal writing.

More than a text editor, it was an attempt to build a complete writing environment around a simple idea: writers should own their work, understand where it is stored, and be able to focus on writing rather than software.

The project evolved into a full SaaS platform including a writing client, authentication system, API server, payment infrastructure, deployment tooling, and supporting services. While no longer actively maintained, it remains one of the most ambitious product-focused projects I’ve built.

Vision

Mysli Write was built around a clear product belief: writing software should be calm, transparent, and respectful of its users.

The project emphasized:

• Privacy and data ownership
• Minimal distractions
• Open and understandable data structures
• Long-form writing workflows
• Simple organization of projects and documents

The goal was not merely to create another browser-based editor, but to build a complete environment for managing writing projects from first draft to finished manuscript.

Architecture

The system was split into multiple independently deployable services:

• Client — Main writing application
• Server — Fastify API and persistence layer
• Auth — Authentication, accounts, profile management, and payments
• Homepage — Gatsby-powered marketing website
• Proxy — Caddy reverse proxy and routing layer
• Manage — Internal administration tools
• Database Seed Layer — Plans, legal pages, localization, and initial data

This separation allowed individual services to evolve independently while keeping responsibilities clearly defined.

Filesystem as a Database

One of the most unusual architectural decisions was the storage model.

Instead of using a traditional relational database, Mysli stored users, projects, documents, notes, media, and supporting data directly on the filesystem using a structured directory hierarchy.

Objects were identified through hierarchical FIDs such as:

client::project::document

These identifiers mapped directly to filesystem locations.

This approach offered several benefits:

• Human-readable data
• Simple backups
• Easy portability
• Direct inspection of stored content
• Reduced operational complexity

The tradeoff was that responsibilities normally handled by a database—validation, consistency, ownership checks, and data integrity—had to be implemented within the application itself.

While unconventional, it reflected one of the project’s core ideas: user data should remain understandable and portable.

Technical Overview

The entire platform was designed around containerized deployment, allowing all services to be built, tested, and deployed independently.

Writing Experience

The writing client was the heart of the platform.

Rather than overwhelming users with controls and menus, the interface was designed around keeping the editor itself central while placing organizational tools around it.

Features included:

• Project management
• Documents and notes
• Footnotes
• Media attachments
• Todo lists
• Writing statistics
• Recent documents
• Zen mode
• Custom typography enhancements

The editor included custom handling for:

• Ellipses
• Em dashes
• Guillemets
• Copyright symbols
• Interrobangs
• Footnote support

These small details reflected the project’s focus on writing rather than generic content editing.

Synchronization

The synchronization model was intentionally simple.

Client-side changes updated application state immediately and were then queued for synchronization with the server.

A background process periodically flushed pending updates, creating an experience that felt responsive and immediate without requiring the complexity of a fully offline-first architecture.

The result was a lightweight synchronization model that balanced simplicity with usability.

Authentication & Payments

Mysli Write included a complete account lifecycle.

Features included:

• User registration
• Login and session management
• Account confirmation
• Password recovery
• Email changes
• Soft account deletion
• Subscription management
• Stripe customer management
• Payment methods
• Premium account activation
• Transactional email delivery

One of the lessons from this project was realizing how much infrastructure exists around a product beyond its primary feature set.

The editor itself was only one piece of a much larger ecosystem.

Engineering Challenges

One of the largest challenges was maintaining simplicity while the product surface continued to grow.

What began as a writing application gradually expanded to include:

• User accounts
• Payments
• Subscriptions
• Media uploads
• Synchronization
• Localization
• Deployment automation
• Legal pages
• Marketing infrastructure

Maintaining a coherent architecture while preserving a calm writing experience required continuous attention to separation of concerns and product focus.

The filesystem persistence layer introduced additional complexity, requiring custom handling for validation, ownership checks, schema enforcement, and lifecycle management.

Development Tooling

The project included a surprisingly complete development and deployment ecosystem.

Features included:

• Docker-based local development
• Independent service builds
• GitLab CI/CD pipelines
• Automated image deployment
• Environment-specific configuration
• Local development scripts
• Reverse proxy routing

Supporting materials included:

• API request documentation
• Planning documents
• Localization files
• Legal content
• Subscription plans
• Visual assets
• Database structure documentation

Taken together, these components made the project feel much closer to a real SaaS product than a typical side project.

Real-World Usage

The deployment architecture was designed for production use.

The platform supported:

• Free and premium accounts
• Project and document limits
• Media attachments
• Subscription billing
• Hosted deployment

At its peak, the project represented a complete end-to-end product rather than a prototype or technical experiment.

Outcome

Development reached the point where the platform supported writing, projects, notes, media attachments, account management, subscriptions, payments, deployment automation, and production hosting.

The project was ultimately paused not because of technical limitations, but because the next challenges became operational: acquiring users, providing support, managing infrastructure costs, and turning the product into a sustainable business.

In many ways, the engineering challenges had largely been solved. The remaining work was business execution.

Reflection

Looking back, Mysli Write taught me that building a product extends far beyond writing code.

The editor itself was only one piece of a much larger system involving authentication, billing, deployment, legal requirements, support workflows, infrastructure, and operational concerns.

The project reinforced an idea that continues to influence my work today: successful products emerge when engineering, user experience, product thinking, and business realities are considered together rather than in isolation.

More than anything, Mysli Write remains a reminder that building software and building a product are two very different challenges.