Using Claude to Clone Confluence in 16 Minutes

About the author: I'm Charles Sieg, a cloud architect and platform engineer who builds apps, services, and infrastructure for Fortune 1000 clients through Vantalect. If your organization is rethinking its software strategy in the age of AI-assisted engineering, let's talk.

Day three. Another SaaS subscription, another Single Serving Application.

I've now replaced Harvest (time tracking) and Trello (project management) with AI-generated clones. Today's target: Confluence, Atlassian's knowledge management and wiki platform.

Claude Opus 4.6 built a fully functional Confluence clone in 16 minutes, consuming 106,000 tokens. That's the fastest build yet, down from 18 minutes for Harvest and 19 for Trello. The pattern holds: requirements in, working application out, no human intervention needed.

The Setup

Same process as the previous clones. I had Claude generate a requirements document and a technical design document, then handed them back with the build prompt. Claude ran in Claude Code, I walked away, and came back to a running application on port 3033.

What It Built

A single-user knowledge base with a rich text editor, hierarchical page organization, version history, full-text search, and a command palette. The core of what makes Confluence useful for personal documentation and note-taking, minus the enterprise overhead.

The screenshot shows a clean, Confluence-inspired layout with a collapsible page tree on the left, breadcrumb navigation at the top, a comprehensive formatting toolbar, and a WYSIWYG editor powered by TipTap (built on ProseMirror). The "Saved" indicator in the top right confirms auto-save is working; every edit persists after 800ms of inactivity.

The Rich Text Editor

Time tracking and Kanban boards are CRUD-heavy but UI-simple. A knowledge base lives or dies by its editor.

Claude chose TipTap, an open-source rich text framework built on ProseMirror. This is the same engine that powers the editors in Notion, GitBook, and other modern writing tools. The toolbar supports:

• Text formatting: Bold, italic, underline, strikethrough, highlight
• Headings: H1, H2, H3
• Lists: Bullet, ordered, task/checkbox
• Block elements: Blockquotes, code blocks with syntax highlighting, horizontal rules
• Embeds: Images (via URL), links, tables (resizable)
• History: Undo/redo

The editor auto-saves with an 800ms debounce. Every keystroke resets a timer, and when you stop typing for 800 milliseconds, the content persists to the API. A status indicator shows "Unsaved changes," "Saving...," or "Saved" so you always know the state. Confluence uses the same pattern, and it works well for a writing tool.

Hierarchical Pages

The page tree is the defining feature that separates a knowledge base from a note-taking app. Pages can nest to arbitrary depth: a "Parent Page" contains a "Child Page" which can contain grandchildren, and so on. The sidebar renders this as a collapsible tree with expand/collapse toggles, and breadcrumb navigation at the top of the editor shows the full ancestor path with clickable links.

The API returns a flat list of all pages, and the tree structure is built entirely on the client side. This keeps the API simple (one endpoint, one query, no recursive joins) while giving the frontend full control over rendering the hierarchy. The tree construction runs in O(n) time: one pass to index pages by ID, one pass to attach children to parents.

When you delete a page, its children become orphans (promoted to root level) rather than being cascade-deleted. In a knowledge base, deleting a category must preserve the content inside it. Confluence follows the same approach with its "move to trash" behavior.

Architecture

Claude went with a leaner stack than the previous clones:

┌─────────────────────────────────────────────┐
│                 Browser (SPA)               │
│  React 18 + Vite + TipTap (ProseMirror)    │
└──────────────────┬──────────────────────────┘
                   │ HTTP (port 3033)
┌──────────────────▼──────────────────────────┐
│              Express Server                  │
│  Serves React build + REST API (/api/*)      │
└──────────────────┬──────────────────────────┘
                   │ SQL (in-process)
┌──────────────────▼──────────────────────────┐
│          SQLite (better-sqlite3)            │
│  2 tables, WAL mode, file-based persistence │
└─────────────────────────────────────────────┘

Claude chose SQLite instead of PostgreSQL. No separate database container. No connection pooling. No TCP connections. The database is a single file on disk, accessed in-process through better-sqlite3's synchronous bindings. For a single-user knowledge base, the entire data layer collapses to a file.

The Docker setup is a single container instead of two:

services:
  app:
    build: .
    ports:
      - "3033:3033"
    volumes:
      - wiki-data:/app/data
    restart: unless-stopped

No database health checks, no depends_on, no separate volume for PostgreSQL data. One container, one volume, one command to start.

Tech Stack

The Smart Decisions

SQLite with WAL mode. Write-Ahead Logging allows concurrent reads while a write is in progress. For a single-user app with frequent auto-saves, this eliminates any possibility of read contention during saves.

Copy-on-write versioning. Every time a page is updated via the API, the backend automatically snapshots the previous title and content into a page_versions table before applying the update. Version history comes at zero cost; no explicit "save version" action needed, no UI complexity. The version history panel lets you browse all prior snapshots and restore with one click.

Debounced auto-save at 800ms. Fast enough that you never lose more than a sentence, slow enough to batch keystrokes into single saves. The status indicator provides continuous feedback without being distracting.

Client-side tree construction. The API returns a flat array. The frontend builds the tree in two passes: index by ID, then attach children. This means the backend never needs recursive queries or nested serialization. Adding, moving, or deleting pages just requires updating parent_id and position fields.

Declarative toolbar. The toolbar buttons are defined as a data array rather than hardcoded JSX. Adding a new formatting option means adding an object to an array rather than modifying component logic. This extensibility pattern keeps the codebase easy to iterate on.

Database Design

Just two tables, the simplest schema of any clone so far:

Three indexes cover the hot paths: parent lookups (idx_pages_parent), timeline queries (idx_pages_updated), and version lookups (idx_versions_page).

The pages table uses ON DELETE SET NULL for the parent foreign key; deleting a parent orphans children rather than cascade-deleting them. The page_versions table uses ON DELETE CASCADE; deleting a page removes its version history, preventing orphaned versions from cluttering the database.

Lines of Code

At 2,100 lines, the Confluence clone is the leanest of the three, roughly a third the size of the Trello clone (6,800 lines) and half the Harvest clone (4,700 lines). A knowledge base is architecturally simpler than time tracking with invoicing or a Kanban board with drag-and-drop. The complexity lives in the TipTap editor, a third-party library doing the heavy lifting.

The CSS at 715 lines covers the full layout, editor styling (ProseMirror content rendering, toolbars, menus), sidebar, version history panel, command palette, and responsive behavior. At roughly half the Trello clone's 1,448 lines, it still delivers a clean, usable interface.

Testing

Claude wrote 24 tests across three layers:

Backend API Tests (10 tests, Jest + Supertest)

• Health endpoint, empty page list, page creation with UUID
• Fetch single page, update page (title + content)
• Version history retrieval after updates
• Child page creation with parent_id
• Search (LIKE matching against title and content)
• Page deletion with 404 verification

The backend tests run against an in-memory SQLite database (:memory:), so they're fast and isolated. No Docker needed.

Frontend Unit Tests (3 tests, Vitest + React Testing Library)

• Sidebar rendering, empty state display, new page button

E2E Tests (11 tests, Playwright)

• App loads with sidebar visible
• Empty state on first launch
• Page creation, title auto-save, child page creation
• Command palette (Cmd+K) with search
• Sidebar filtering
• Page deletion with confirmation dialog
• Toolbar formatting buttons present
• Page navigation

Feature Completeness

Estimated coverage: ~80% of personal Confluence use. The absent features (attachments, templates, macros) are Confluence's enterprise differentiators. For personal knowledge management and documentation, everything I actually use daily is present: the editor, the page hierarchy, search, and version history.

Comparison: All Three Clones

The Confluence clone is the fastest, smallest, and simplest of the three, consistent with the application complexity. A knowledge base is fundamentally a tree of documents with a good editor. Claude recognized this and made appropriately lean choices: SQLite over PostgreSQL, a single container over two, and a 2,100-line codebase that does exactly what's needed.

The trend line continues downward: 18 minutes, 19 minutes, 16 minutes. The models are getting faster at this as I refine the process. The requirements documents are getting more precise, and the build prompts are more focused.

The Bottom Line

Three days, three SaaS replacements. Harvest for time tracking, Trello for project management, Confluence for knowledge management. Each built from a requirements document by Claude Opus 4.6, each running in Docker, each covering 80-97% of the features I actually use.

The Confluence clone demonstrates that AI code generation handles UI-complex applications: a real rich text editor with formatting toolbars, hierarchical navigation, and auto-save. TipTap does the heavy lifting for the editor itself. Claude made the right library choice, integrated it correctly, and built all the surrounding infrastructure (page tree, version history, search, command palette) from scratch.

The complete source code is available on GitHub. Clone the repo, run docker compose up -d, and start writing.

This post was drafted by me and expanded with Claude. The application, the analysis, and the opinions are mine. Claude helped articulate them and built the application, which continues to be a recursive situation.