Positioning
Typdit (“I typed it”) is a rich text editor that opens straight in the browser. For writers it is a page that is ready before they are; for site builders it is an editor that drops into their own pages with a single script tag.
One premise drives it: the editor core is built here, not borrowed. The editor is the heart of the product, and a borrowed heart means no control over performance, over CJK input quality, or over where the thing can go next. ProseMirror, Tiptap, Lexical, Slate and Quill are all deliberately unused; the document model, rendering and input handling are written from scratch.
The service began as a place that recorded and replayed the typing process, and was redefined as a pure editor service in 2026-08. The recording and replay axis was retired in favor of the editing experience and embeddable distribution.
Market and Problem
The document editor market is split at both ends. On one side sit finished services like Notion and Google Docs; on the other sit editor libraries a developer has to assemble. Anyone who wants both “a page to write on right now” and “an editor inside my own site” gives up one of the two every time. Pick the service and it cannot live in your page; pick the library and days disappear into wiring it up.
The second problem is Korean and Japanese. Most web editors treat IME composition as something to patch after the fact, so typing fast still produces duplicated or reverted characters. Composition state has to be handled in the core; wrapping the surface never removes the problem for good.
Core Audience and Personas
- People who write documents daily, meeting notes, weekly reports and specs, written over and over, where the friction of opening the tool matters
- Solo developers and small teams who need an editor inside their own product, teams with no room to assemble and maintain an editor library but who still need writing built in
- Writers working long-form in CJK, Korean and Japanese users who have retyped a sentence because the editor mangled composition input
Value Proposition and Differentiation
- Its own core, text storage is a piece tree (an immutable original buffer plus append buffers in a balanced tree) and history is keyed on stable identity, not position. Undoing a deletion restores the original run segment and redoing an insertion reuses the same block ids, so undo never drifts out of sync with document structure
- Zero friction to the first keystroke, the landing page opens a live demo editor, and sign-in is only requested at the moment of saving. Free accounts autosave up to 20 documents
- One-line embed, a single script tag (
/embed/v1.js) puts the same editor on any page. It works without a key and carries a watermark; a subscription issues a license key pinned to a domain and expiry, and the watermark disappears - Clean paste, formatting pasted from Notion or Word is normalized into the document schema instead of dragging invisible markup along
- Markdown shortcuts and slash commands, headings, lists, quotes, code blocks, images and video without leaving the keyboard
- Skeletons you can use immediately, document templates such as meeting notes and weekly reports, paired with guides on how to write that document type well, both wired directly into the editor
Core User Flow
- Arrival: type into the demo editor on the landing page; the sign-in prompt appears only when saving
- Writing: apply formatting through markdown shortcuts, slash commands or the toolbar, including color, highlight, font and alignment
- Saving: autosave, with 20 documents and 50,000 characters per document on the free tier, unlimited and 500,000 on the subscription
- Attachments: image, video and general file uploads plus YouTube and Vimeo embeds (subscription feature)
- Distribution: issue a license key on the embed page and paste one script tag into your own site
- Subscription: check out from the pricing page through the shared account hub and return to the page you came from
Subscription → embed key → customer-site verification
flowchart LR
Write["Write in the editor"] --> Save["Autosave"]
Save --> DB[("Firestore
documents · embed keys")]
Sub["Plus subscription"] --> Key["Issue embed key
domain · expiry pinned"]
Key --> DB
Site["Customer site
one script tag"] --> Load["Look up key on load"]
DB --> Load
Load --> Ok["Valid → no watermark"]
Load --> Wm["No key · expired → watermark"]Key verification runs through public read rules rather than a separate auth server, and the expiry is pinned to the subscription end date at issue time. Renewing a subscription does not move an already-issued key’s expiry, which keeps the verification path down to a single document read.
Business Model Hypothesis
Monetization runs on a single subscription rail. No per-action deduction and no credit consumption, so the pricing story stays one sentence long.
- Free, 20 documents at 50,000 characters each. Editing features are not gated; only storage volume separates the tiers
- Plus ($5/month, $50/year), unlimited documents, 500,000 characters, file attachments, embed license and priority support. The yearly plan is effectively two months free
- The embed is the growth loop, keyless usage keeps running on other people’s sites with a watermark attached, and that watermark is the inbound path back to a subscription
- Next hypotheses, team licenses and a higher tier priced on embed usage
Checkout goes through the shared family account hub into an external payment provider’s subscription products, and a webhook updates the plan field on the service’s own user record. No new payment infrastructure was built; the existing one was reused.
System Architecture (planning decisions become system structure)
Two product decisions determined the structure.
1. “The editor core has to be ours” → the repository is split into core, view, extensions and React binding packages, and the core carries no DOM dependency so it can be unit tested in Node. The service pages consume vendored copies of those packages, and CI catches any drift between source and vendored copy.
2. “The same editor has to run on other people’s sites” → a bundling step after the web build packs the editor into a single dependency-free script. An embed needs only that one file, and the license check is one public read.
Documents live in a service-scoped Firestore database and attachments in per-user paths in object storage. There is no separate backend API server; only server-authoritative work such as billing and plan updates runs in the shared functions layer.
Technology Choices and Trade-offs
- Writing the editor core, a large up-front cost in exchange for full control of input handling, history and extension points. With a library, IME behavior and paste normalization would have been stuck in someone else’s issue queue
- Piece tree buffer, the original buffer stays immutable and new text only accumulates in append buffers, so editing cost does not scale with document length
- Astro with React islands, landing, templates, docs and guides are prerendered while only the editor hydrates as a client component. Content pages stay fully indexable while the editing surface behaves like an app
- Split theming, the site is light by default and only the editor ships both themes, because the surface you write on and the surface you read have different requirements
- What was dropped, real-time collaboration (roadmap), tables and find/replace (in progress), and adopting an external editor library (excluded on principle)
Operational Automation
- Data files are the pages, templates, guides and docs each have one canonical data file; adding an entry generates the index page, the detail page, structured data and the editor link automatically
- Five locales enforced, Korean, English, Japanese, Simplified and Traditional Chinese are filled in per entry. A missing translation shows up immediately as a blank on that locale’s page
- Embed bundle build, packing the editor into a single script is part of the deployment pipeline, after the web build
- Vendor drift check, CI compares the core packages against the in-service copies so a mismatched pair never ships
- Subscription propagation, the payment webhook updates the user’s plan and the account hub exposes the current subscription period
Current State and Operational Signals
- Status: live. Editor, templates, docs, guides, embed and pricing pages are live across five locales
- Timeline: first launched 2026-02, redefined as an editor service 2026-08
- Infrastructure: Firebase App Hosting (
typdit.com) with a service-scoped Firestore database and object storage - Signals under watch: how often free accounts reach the 20-document ceiling, embed keys issued, and the conversion from template/guide search traffic into the editor
Retrospective and Next Hypotheses
- What worked: keying undo on stable identity rather than position. Undo stays correct after the document structure changes, which is what makes the editor feel trustworthy
- What I would redo: when changing what the service is, retiring old pages and publishing new ones should have moved as one ordered step. Right after the cutover, leftover pages briefly disagreed with search results and internal links
- Next hypotheses: (1) pin IME composition quality with regression fixtures, (2) find/replace and tables, (3) real-time collaboration, (4) team licenses
Comparable Engagements
The capabilities developed solo on Typdit transfer cleanly to other domains.
- Text editor and document model design, anything that has to handle input, selection and history directly on top of contentEditable
- Korean and CJK input quality, fixing web UIs that break on IME composition, at the core rather than the surface
- Embed SDKs and license gating, shipping scripts that run on other people’s sites, with domain and expiry verification and watermark fallback
- Subscription billing integration, the minimum structure that connects an external payment provider to a service’s own plan state through webhooks
- Mixing static content with app pages, running search-facing pages and signed-in app pages inside one site
I prefer engagements where one person carries the work end to end. Reach me via /work-with-me or /contact.