How We Built a Browser-Based Note App

MNMNOTE (Minimal Note) is a markdown note app that lives in a browser tab, stores notes locally on your own device, and works fully offline. We are a small team of enthusiasts who started building it in 2025. This post is the build-in-public version of that story: the friction problem that started it, the traps we hit, and the architecture that survived contact with real notes.

The whole thing began as a corporate-laptop workaround. We could not install Obsidian on a locked-down work machine; antivirus refused. We opened a browser tab, saved a note straight into the browser's own storage, and watched it persist across reloads with nothing installed and no server in the loop. Fourteen months later, by May 2026, there were forty-eight finished build phases, a real editor that round-trips markdown, and a small number of strangers using it. The browser's storage and offline capabilities grew up at exactly the right time. The browser, in 2026, is finally a real operating system.

The problem we had

The problem was prosaic. A work laptop refused to install anything we wanted. A note app you cannot open in a tab is an app you cannot use during the hours when you actually have time to write — the commute home, the long lunch, the half-hour between standups. The browser became the only environment we could trust on a machine we did not own.

It is a universal problem. A great many people write on machines they do not control: locked-down corporate laptops, library terminals, borrowed devices, a Chromebook in a classroom. The corporate laptop is the most common piece of computing hardware in working life, and it is the least cooperative. Steph Ango, the chief executive of Obsidian, put the long version of this idea in one sentence: "In the fullness of time, the files you create are more important than the tools you use to create them." ¹ If the file matters, the friction to write the file should not.

What we tried first

We tried the obvious things first. A markdown file in a Google Doc, which is not actually a markdown file. A folder of .md files in Dropbox, which broke wiki-links. A self-hosted Joplin instance, which required a server somebody had to maintain. None of them were one tab away. Every one was a project.

Joplin was the most serious attempt. We spent a weekend wiring up the server, paid for a small VPS, and ran the desktop client on every device we owned. It worked. Then the work laptop refused to install the client. Then the VPS bill arrived. Every solution required the user to be the system administrator. None met the local-first test Martin Kleppmann and the Ink & Switch team named in 2019: "No spinners: your work at your fingertips." ² In their words, in local-first software "we treat the copy of the data on your local device — your laptop, tablet, or phone — as the primary copy" ². In 2026 that is finally a feasible claim, because the browser is finally a real operating system. The wider shift back to the device is a story of its own — we walked through it in Software Is Quietly Moving Back to Your Device.

Why we built MNMNOTE

MNMNOTE began as the smallest possible answer to one question: what would a note app look like if the browser was the entire computer? No install. No account. No server. Notes stored locally, on your own device. Markdown in, markdown out. The first version, in March 2025, was a single page with a text box and a save button. It fit in 200 lines.

We made every choice on the smallest budget we could imagine. One editor that round-trips markdown faithfully, so what you type and what gets saved are the same document. Storage that lives in the browser, so notes never have to leave the device. Editorial typography, so a note reads like a printed page. Nothing else — no plugin marketplace, no settings maze, no account wall.

The result, after a few weeks, was a single browser tab that could open a note, render it as a clean magazine page, and save it locally without phoning any server. Behind it: a domain, a small backend for the optional sharing layer, and a hosting tier. Nothing else.

What we learned about storing notes in the browser

Browser storage is more capable than most people give it credit for. The modern browser can hold a large amount of structured data on your own device, search it quickly, and keep it through reloads and offline sessions — no server in the loop. Caniuse put support for that local-storage capability at 97.27% of global browser usage as of 23 September 2026 ³. The capability is wide. The traps are particular.

The first trap is the way writes are grouped. Saving notes on the device is not the same as saving rows to a SQL database: a save can quietly finish and a new one begin between two steps if you are not careful, so two writes you meant to land together can split apart. The fix is to keep each save tight and self-contained. We still got it wrong the first three times. Two weekends, gone.

The second trap is quotas. The web.dev guidance from Pete LePage, last updated 23 September 2024 ⁴, is the rule worth memorizing: in Chrome, "an origin can use up to 60% of the total disk space"; in Firefox, "an eTLD+1 group may use up to 2GB"; in Safari, the browser "appears to allow about 1GB," with "a seven-day cap on all script writable storage" outside installed apps ⁴. For a notes app this is huge. For a Safari user who never installs the app to the home screen, it is a deadline. The fix is to ask the browser to make storage persistent and to offer an honest, visible prompt to install.

The third trap is performance assumptions. Independent benchmarks on Chrome 128 show a small write to on-device storage at roughly 0.17 ms, and a bulk read of one hundred documents at 4.99 ms — near-equivalent to an in-memory database (3.59 ms) ⁵. The lesson is that on-device storage is fast enough for a notes app's working set. The wrong move is to put it on the hot path of every keystroke. Read when a note opens, write on a short debounce, save in batches. Done that way, it disappears.

What we learned about the editor

The hardest single decision was the writing surface. A markdown-first app needs an editor where what you see and what gets saved are the same document — not a rich-text canvas that exports markdown as an afterthought. Get this wrong and you spend the rest of the project translating between two formats that never quite agree.

The surface we built treats every keystroke as a small, replayable change rather than text sitting in a single variable somewhere. That sounds academic until you try to add real-time collaboration later: the change-based design is exactly what makes conflict-free merging possible, and exactly the wrong shape if you assume "the editor has the text in a variable." There is no variable. Two months of our early code were the wrong answer to the wrong question.

The other half is that the document is honest markdown all the way down. Every document the editor holds has a plain-markdown form — there is no proprietary save format to escape from later. Steph Ango's file-over-app argument has a concrete realisation here: the document the user can read in any editor today is the document they will own in a decade.

What we got wrong

We got most of the early decisions wrong, in the small ways that compound. We shipped a real-time sync feature in month three that nobody used and had to rip out in month eight. We spent a week on a feature-flag system before we had any users to flag. We underestimated typography by an order of magnitude.

The sync feature was the worst. Nobody had asked for it. We built it because every cloud note app has sync, so we assumed ours should too. We wired up a backend, a session model, conflict resolution. None of it shipped to anyone. We removed it, and the code dropped out of the project like it had never been there. Build the local layer first; decide on sync later — when the use case demands it, not when the announcement does. (Cross-device sync remains a later decision, not a v1 promise.)

The deeper mistake was harder to see. For the first eight months we treated the project as a stack of technology choices: pick the right tools and the right patterns and a product will emerge. It does not work that way. Paul Graham, in October 2015, wrote: "If you simply manage to write in spoken language, you'll be ahead of 95% of writers." ⁶

We had been writing in committee-meeting English.

We rewrote the whole product copy in one weekend. The product had not changed. The voice had.

We also posted MNMNOTE on Hacker News too soon, and it went nowhere. The Show HN guidelines are explicit: "Show HN is for something you've made that other people can play with." ⁷ Our early version was a thing people could play with for thirty seconds, then close. The reaction was correct.

What's next

What's next is the boring part — the part where products either survive or do not. One feature is in flight: faster shared-note loading. One format is in alpha: an embedded drawing canvas. No plans to raise money, hire, or post on Product Hunt this year. The list of things we are not doing is longer.

The shape of the road is visible because other people have already walked it. Takuya Matsuyama, who runs Inkdrop solo from Japan, wrote in his Inkdrop 4 announcement: "I am a freelance developer based in Japan, running this project for 3 years alone." ⁸ That post drew 533 points on Hacker News on 5 June 2019 ⁹. Obsidian's Show HN, posted by Erica Xu on 27 May 2020, drew 1,087 points and described Obsidian as "a powerful front-end for your knowledge, like an IDE for your notes." ¹⁰ As of a 2023 Fast Company report, Obsidian estimated approximately one million users, with a Discord of more than 110,000 members ¹¹. The path is slow, and the path is real. mnmnote.com is one more attempt at the same shape.

Frequently asked questions

These are the questions we get most often from readers of r/SideProject, Indie Hackers, and the rare Hacker News commenter. The answers are the honest version — what we would say over a coffee. None of them is a pitch.

Why store notes in the browser instead of a server?

Because a server is the friction. The moment notes live on someone else's machine you need an account, a connection, and a company that stays in business. Storing notes locally on your own device means the app opens instantly, works fully offline, and keeps your notes even if our servers vanish. A notes app's working set is small enough that on-device storage is plenty fast ⁵. The choice is structural, not aesthetic.

Why build a custom editor instead of a plain text box?

Because a markdown-first app needs the editor and the saved file to be the same document, not two formats kept loosely in sync. A plain text box gives you raw markdown but no live preview; a generic rich-text canvas gives you a preview but treats markdown as a lossy export. The writing surface we built keeps what you see and what gets saved identical, which is the load-bearing feature of a markdown app.

How long did it take to build?

About fourteen months. The first version (a text box plus a save button) shipped in three weekends. As of May 2026, the version described here — live markdown editing, on-device persistence, sharing, and an installable offline app — stood at forty-eight finished build phases. Patrick McKenzie's rule applies: a small software business can be run on a few hours a week ¹².

Will MNMNOTE ever sync across devices?

The architectural path for it is open. Today the app works locally on your own device, and any note you choose to send can be shared end-to-end encrypted. Turning live cross-device sync on is a product decision about timing, not a question of whether it is possible.

How is MNMNOTE different from Obsidian?

Obsidian is a desktop app with an excellent plugin ecosystem and, on a 2023 estimate, approximately one million users ¹¹. MNMNOTE is a browser tab with no plugin ecosystem and a small user base. Shared ground: markdown and wiki-links. Difference: install friction. If Obsidian works for you, keep it.

What does the app actually do?

Notes are stored locally on your own device in open Markdown, it works fully offline, and any note you choose to send can be shared end-to-end encrypted — no account required. mnmnote.com opens in a browser tab with nothing to install.

A small declaration

The note app we needed exists now. Steph Ango writes that "style is a set of constraints that you stick to" ¹³, and after fourteen months ours are visible. It lives in a browser tab, and we are no longer embarrassed to point at it. If it works for you, mnmnote.com is one tab away.

References

Grouped by tier per blog-writing-guide §7. Inline citations: ¹, ², ³–⁵, ⁶–¹³.

Tier 1 — Academic / primary research

Tier 2 — Mainstream press / verifiable journalism

Tier 3 — Industry blog / vendor research

Tier 4 — Personal site / editorial voice

Tier 5 — Community / viral precedents

Tier 6 — Standards / official docs / library sources

JSON-LD

FAQPage

Article