This one started with a habit I did not realize I had built.
Markdown has quietly become the default output of a lot of AI tools. You ask Claude to help you research a topic, document a system, or structure your thinking and what comes back is a markdown file. You did not ask for markdown specifically. That is just how it arrives.
It is not just research output either. With tools like Claude, Cursor, and others making markdown central to how they handle context and documentation, MD files have become the norm across a lot of workflows. Skills.md files, design.md files, README files, guidelines, briefs. If you work with AI tools regularly, you are reading and editing markdown regularly whether you think of it that way or not.
The problem is where most people end up opening those files.
I was using Sublime Text. It is a great code editor and I use it for a lot of things, but reading and editing a long markdown document in a plain text editor is a different experience entirely. There is no rendered preview. You are reading raw syntax. Hash symbols for titles, asterisks for bold, brackets and parentheses for links. On a short file that is manageable. On a long research document or a detailed design guideline, after an hour your eyes are done. You are mentally translating syntax into formatting the whole time and it adds up.
The other problem is editing. If you want to add a heading in markdown you have to know the syntax. If you want to bold something, same thing. There are no toolbar shortcuts, no formatting buttons, nothing to help you move faster. You either know the syntax or you stop and look it up. For a designer writing documentation that should be the last thing on your mind.
So I built something specifically for this.
This is part of a series
I am documenting how I use AI in my actual day to day workflow. Not theory, not overviews. Specific tools I built, the problems they solve, and the thinking that went into each one.
The first was QuickApply, a Chrome extension that fills job application forms in one click. This is the second. The third is a coffee menu app with personalization options.
The throughline across all of them is the same. AI moves fast. Clear thinking about the problem is still what makes the output useful.
The problem I was actually solving
When I started planning this I wrote down what was frustrating me specifically, not just that the experience felt off.
Opening a long markdown file in a code editor like Sublime Text means reading raw syntax for as long as you are in that file. No preview, no rendered formatting, no visual hierarchy. Just text and symbols. When the document is a quick reference that is fine. When it is a ten section research document or a detailed set of design guidelines, it becomes a real problem. You spend mental energy parsing syntax instead of engaging with the content.
The same friction comes up with structured files like SKILL.md or DESIGN.md, the kind of documentation that AI tools use to store context, rules, and guidelines. These files are meant to be read carefully, updated regularly, and referenced often. A plain text editor is not built for that kind of work and after a while you feel it.
Editing was the second issue. Making changes to a markdown file without knowing the syntax slows you down. Adding a heading, creating a table, formatting a link. In a code editor you are doing all of that from memory. There is no toolbar, no shortcut, nothing to help you format quickly. For a designer working on documentation that friction is constant.
The second issue was privacy. A lot of what I am working with is research in progress. Design guidelines for products I am building. Competitive analysis. Documentation that is not finished. I did not want to be uploading that to platforms I did not fully understand or control. I wanted the files to stay local.
Those two things together, the uncomfortable editing experience and the need to keep files on my own machine, defined exactly what I needed to build.
What I planned before writing anything
I wrote out the feature list as a set of needs, not a set of features. The distinction matters because it keeps you from building things that sound good but do not solve the actual problem.
What I needed was:
A way to see the markdown and the rendered output at the same time, side by side, so I could edit on the left and see the result on the right without scrolling back and forth or switching between tabs.
Synchronized scrolling between the two panels. If I am reading a section in the preview I want the editor to be on the same section. If I am editing I want the preview to follow. I did not want to manage two scroll positions at once.
A file history so I could quickly get back to documents I had opened before without hunting for them or keeping a separate folder open.
The ability to export the edited document directly from the app. No copying, no pasting. You edit it, you export it, you are done.
Light and dark mode because I work at different times of day and under different conditions. Dark mode at night is not a nice-to-have, it is just more comfortable for extended sessions.
And the whole thing needed to be local. No uploads, no cloud sync, no account. The files stay on my machine. The app runs in the browser. Nothing goes anywhere.
What Focus.MD does
The app is a single self-contained HTML file. You open it in Chrome and it runs entirely in your browser. There is nothing to install, no server, no login.
Split panel editor
The left panel is a plain text editor where you write or paste markdown. The right panel renders it in real time. Both panels scroll in sync so you always know where you are in the document.
File history
Every file you open gets added to a sidebar history. You can get back to any previous document with one click without having to navigate your file system again.
Export
When you are done editing you export the file directly from the app. It saves back as a markdown file to your downloads folder. No copying, no intermediate steps.
Light and dark mode
The toggle is in the toolbar. Your preference saves so it stays set between sessions.
Local only
Nothing in the app makes any network request. It does not know what files you have opened. It does not send anything anywhere. Everything lives in your browser’s local storage and in the files on your own machine.
Why the file structure matters
The first version of Focus.MD came back as a single HTML file with all the CSS and JavaScript inside it. It worked. You could open it in a browser and everything ran. But I was not happy with it.
A single file is fine for a quick prototype or a tool you are never going to touch again. It is not a good foundation for something you plan to improve over time. When your styles, your logic, and your markup are all in one file, every change is harder than it needs to be. You are searching through hundreds of lines to find the thing you want to edit. Adding a feature means deciding where in that file it goes. The bigger it gets the more fragile it becomes.
I pushed back on that and had it restructured into separate files. HTML for the structure, CSS for the styles, JavaScript for the logic. Each concern in its own place.
This is one of the things I think is important to understand about working with AI to build tools. The first output is not always the right structure, even if it works. Knowing what good looks like, and being able to say this is not how I want it organized, is part of the skill. AI will produce a working single file because that is the path of least resistance. Asking for something more maintainable requires you to know why it matters.
The separated structure also makes the privacy guarantee easier to verify. Each file has a clear, single responsibility. There is no server, no backend, nothing that could be making network requests buried inside a large combined file.
What I caught in review
The first version had the toolbar sitting above the global navigation and the document title. That sounds like a small detail but it is a significant UX problem. The tools you use to edit a document need to be close to the editing area. When they are separated by a navigation bar and a title, the relationship between the controls and the content they affect is broken. The proximity was wrong and you felt it immediately when trying to use the app. I flagged it and had the toolbar moved into the editing area where it belongs.
That introduced the next problem. Once the toolbar was inside the editing area, there were too many tools in a single row and the toolbar was overflowing. Some tools were getting cut off and were not accessible at all. A toolbar that hides its own controls is not a toolbar, it is just clutter.
The fix was not to remove tools but to group them by familiarity. Formatting tools together, insert tools together, document actions together. Grouping related controls with visual separation between groups makes the toolbar feel shorter even when the total number of tools stays the same. It is how every well-designed editor handles this problem and it is the kind of decision that requires knowing what you are looking at, not just accepting what was generated.
The synchronized scrolling was wrong on the first pass. The sync was position-based, matching pixel scroll values between the two panels. That works until the content in the two panels has different heights, which markdown almost always produces because rendered text wraps and reflows differently than raw text. I caught it during testing on a longer document and specified a content-percentage based sync approach instead, which maps your position relative to the total scrollable height in each panel.
The file history was not persisting between sessions on the first version. It was storing in memory rather than in localStorage so every time you closed the tab the history was gone. I caught it the first time I closed and reopened the app and specified the fix.
How I use it now
Every time Claude generates a markdown research document I open it in Focus.MD. I read it in the preview panel, make edits or notes in the editor panel, and export when I am done. The file history means I can come back to any document without thinking about where I saved it.
For design guidelines I write directly in the editor, with the preview live on the right. Being able to see the formatted output while I write changes how I write. I make decisions about structure in real time rather than guessing how it will look.
The dark mode is on by default for me. Extended reading and editing sessions are just easier on the eyes without the bright background.
One small thing worth mentioning
Not every decision in a tool has to be about efficiency.
Every new file you create in Focus.MD gets an auto-generated name. Not “Untitled Document 1.” Something made up, a little absurd, occasionally funny. You will never stare at a blank file with no name again.
It is a small detail. It does not make the tool faster or more powerful. But it gives it a little personality and that matters. Good tools are not just functional, they are enjoyable to use. If you are going to open something regularly it should not feel sterile.
That one feature gets more comments than anything else whenever I show the app to someone.
Download Focus.MD
You can download Focus.MD below. It is a single HTML file. Open it in Chrome, drag in a markdown file, and start working. The README file inside the download covers everything you need to know.
[Download Focus.MD]
What is next
The next tool is a coffee menu app with personalization options. A different kind of problem, same approach — identify the friction, plan it clearly, build it with AI, and share the full story.
I post each one at ronaldrosales.com and link to it on LinkedIn. If you want to follow along, that is the best place to do it.