Useful software.
Thoughtfully
built.

The problem

Notes need to survive more than a page refresh. They also need to stay private, be easy to find, and be recoverable after deletion.

What I built

• Markdown writing, preview and split view; optional Vim keys, undo/redo, in-note search and exact Markdown downloads.
• Editable checklists with color, pinning and labels; an account-free browser-only editor example.
• Stable ID wiki links, explicit broken/ambiguous targets, saved backlinks and linked-note pages across active/archive notes.
• A bounded graph with label/title filters, neighbourhood focus, fit/zoom/pan and equivalent keyboard/list navigation.
• Search across titles, bodies, labels, and checklist items.
• Real PostgreSQL transactions, account isolation and revision checks that preserve conflicting drafts.
• Private recovery keys, session revocation, JSON export and account deletion.
• Restore from trash, confirmed permanent deletion, and retryable save errors that preserve edits.

What I checked

Actual PostgreSQL rollback, duplicate-signup races, cross-account isolation, concurrent revisions, quotas and backup restoration. The browser journey uses real login cookies and saved notes. It checks Vim, retained undo, failed-save recovery, safe Markdown and exact exports, plus stable links across renames/trash/restoration, two-account isolation and graph/keyboard/phone behavior. Editor and graph failures are exercised explicitly.

Current boundaries

Free bounded preview with billing closed. Graphs draw up to 500 nodes / 1,000 edges; current accounts support 250 notes. Durable revision history and source-bundle imports are planned. No email recovery or end-to-end encryption is claimed.

The problem

Quick notes should work without an account. Browser storage is useful, but people still need a way to back up and transfer their data.

What I built

• Feature modules and native DOM events rather than a UI framework.
• Search, labels, checklists, pinning, archive, and trash.
• JSON backup/export that includes archived and deleted notes.
• Validated, additive import with duplicate detection and storage-failure rollback.

What I check

Store operations, checklist editing, backup roundtrips, malformed imports, duplicate IDs, and partial storage failures.

The embedded demo uses this browser's localStorage. Its data stays on this device.

The problem

A queue does not truly limit concurrency if every queued job creates another waiting goroutine. Slow stream clients can also stall all workers.

What I built

• A fixed number of workers reading directly from a bounded channel.
• Batch IDs, progress endpoints, queue metrics, and all-or-nothing admission with retry responses.
• Buffered SSE clients, heartbeats, request cancellation, and slow-client disconnection.
• Bounded batch history and graceful shutdown that drains accepted work.

What I check

Exact admission counts, invalid inputs, queue saturation, worker bounds, shutdown, and slow stream handling with Go's race detector.

Retained engineering study; replacement under review. This is an in-memory simulation, not a production webhook delivery service. It does not make outbound requests or persist jobs.

The problem

A transcript needs traceability to the recording, clear correction history, portable exports and a reliable way to recover failed processing.

What I built

• Inspected uploads, confirmed quotes and bounded on-demand Whisper processing.
• Timestamp player, segment search, separate corrections and source-quoted optional DeepSeek review.
• Markdown/JSON/SRT/VTT bundles with stable segment IDs, hashes and provenance for future workspace imports.
• Transactional credit holds, idempotent jobs, private recovery, retention cleanup, owner reports and a pause switch.
• Compatible local CPU CLI with private ASR checkpoints and atomic complete exports.

What I checked

Actual generated speech through local CPU and cloud GPU recognition, real DeepSeek review, and browser upload/correction/export. SQLite accounting, isolation, failed work, source validation and Paddle lifecycle cases have automated tests; payment APIs are mocked.

Current boundaries

English uploads up to 64 MiB / 60 minutes; the bounded free sample processes the first 30 seconds. Paid packs await merchant/website approval and real payment tests. Hosted URL imports, speaker diarization and Noteweld integration are not implemented. AI notes and scholarly metadata candidates do not verify facts.

The problem

Books and technical PDFs need usable, editable files for a reader's own tools. Successful extraction also needs traceability to the original pages.

What I built

• A FastAPI book/range inspector with confirmed quotes, bounded MinerU GPU sections and a cheaper text-only route.
• A persistent SQLite job/credit ledger with serialized writes, reserve/settle/release accounting, duplicate suppression and session-owned downloads.
• Source-linked review, saved correction history, selective reprocessing and portable Markdown/image exports with manifests and original engine output.
• Owner-only activity and billing reports, admission budgets, a pause switch and encrypted financial backups; commercial purchases stay disabled pending seller activation.

What I checked

A complete 1,000-page synthetic PDF across 50 cloud text sections, a real MinerU selection, public trial/edit/export and session isolation. Automated tests cover credits, partial failures, recovery, bounds and source-aware exports; payment-provider checks are mocked.

Current boundaries

The public free sample is one selected page. Book processing is implemented up to 64 MiB / 1,000 PDF pages; real credit purchases await seller activation. Source links and issue flags do not certify accuracy; specialized symbols and complex layouts need source review.