The TL;DR is this: in the old days, if I were to build this web app from scratch, it would have cost me around 200 hours, spread over 1 or 2 months, going slow, back and forth. And it probably wouldn’t have ended up as complete as this one.

With Claude, I did it all in a little over 30 hours, spread across 3 days of super hyper focus (I don’t recommend it; I almost got sick doing it). In the end, this produced a project with roughly 130 pull requests. A total of 18 thousand lines of code (test coverage around 70%). It was all done in Ruby on Rails 8 and JavaScript (HotWire/Stimulus).

There are several advantages to this particular app: it’s a very well-known and well-documented scope. There are hundreds of text editors of all types and complexities. Surely every LLM has been trained with tons of material on this. So when I ask it to search by filename, it already knows to reach for something like the Levenshtein algorithm for fuzzy matching, for example.

Searching and listing images in a grid, uploading to S3, find and replace, HTML preview, etc. All of this is super well documented and trivial to do. Even without LLMs, any intern would find it in the first Google link and on Stack Overflow. So I’d say more than 90% of the scope was easy. An app with a less well-known scope — say, a scientific application — would have been much harder. So this example of mine is only slightly above a Hello World: repeating a well-known scope that already exists.

Unlike what I did in my first Vibe Coding article, this time I won’t comment commit by commit; there are more than 130! We’d be here all week. Instead, I’ll comment on a few themes that catch my attention and that might be relevant to other projects.

Choose Your LLM Plans Carefully

Over those 3 days, I was interrupted by Claude Code about 2 or 3 times and had to use something else for 2 or 3 hours. That’s because it has some daily token limit and tells me to stop after I use too many tokens.

I’m using the Max Plan (5x Pro), which I think costs around USD 100, meaning around USD 6 a day. In this case it was cheap, because 3 days would only cost USD 18.

But during one of those breaks, I switched to using Claude Opus via OpenRouter, and that was WAY more expensive. Outside the Claude Code exclusive Max plan, the per-token cost is absurdly higher. In about 2 or 3 hours, it already burned through more than USD 100 (equivalent to the whole monthly subscription!)

So, in total, by using the Max plan outside its bounds, I ended up spending more than USD 120. But if I had just stopped to rest between the daily limits, I would have spent one extra day (wouldn’t have gotten sick 😅) and wouldn’t have gone much beyond USD 20. So you need to research the plans for each platform carefully before jumping in without thinking, like I did. 😂

As I’ve said over and over: when in doubt, use Claude Code with the Max plan.

Choose Your Architecture Carefully

When I started coding (every time I say “I coded”, read it as “I vibe coded”, of course), the start was very fast. I decided only a few technical things: I wanted it to be Ruby on Rails 8, I wanted it to use Tailwind CSS, I wanted it to use no database and implement everything based on the filesystem, I wanted it to have no authentication, since it would be self-hosted for my use only.

The first 10 commits took a little over an hour and a half. I kept adding features bit by bit to give “shape” to the editor, and at this point I already had a minimal, good-looking editor, with a dark theme, that edited and displayed an HTML preview. Not bad for a prototype.

As I said in the other article, this would be one of the “it already works” milestones.

But of course, there are still more than 120 commits to really work, and nearly 30 hours to reach the “really works” stage.

I kept adding various small features, in this order:

• Add a Markdown cheat-sheet (help)
• Dialog box to add fenced code blocks with language autocomplete
• Theme system, already adding around 10 themes (but not yet tuned for Omarchy)
• Dialog box to customize fonts
• Zoom control on the Preview
• First attempt at “typewriter mode” (this will cause plenty of headaches later)
• Dialog box to search files by path with a fuzzy finder
• First attempt to sync the editor scroll with the preview (this will also cause plenty of headaches)
• Dialog box to search files by content with regex support
• Dialog box to search and embed YouTube videos
• Dialog box to search images, upload and insert
• Initial Docker support

That completes the first 34 commits and about 4 hours of work. Again, very close to “it already works”.

But the fun begins at commit 7bbf03a, titled: “Refactor to Restful Architecture”.

This is a Rails-specific thing, and an architecture thing in general. Claude, without me instructing it, did exactly what I’d expect a Rails intern to do: it crammed all the logic for managing directories and files, image uploads and everything else into 2 or 3 service modules.

It also wrote all the routes manually. That is, it didn’t use the most basic thing in Rails: the concept of Restful Resources. Read the linked guide; I won’t explain what that is here, just that any experienced Rails person knows it with their eyes closed.

So it created routes like “http://localhost:3000/notes” but didn’t enable things like “http://localhost:3000/notes/hello” automatically opening “hello.md”, and HTTP verbs like PATCH to update the file or DELETE to remove the file. And also, without the GET option, I wouldn’t have the option to bookmark a file directly. All of this comes for free if you use RESTful. So that commit was the refactor where I instructed it to redo everything in that architecture. Just that alone was almost 1000 lines added.

The “correct” thing would have been to set up, right at the start, a CLAUDE.MD or CONTRIBUTING.MD file or something similar with the specific architecture rules and code conventions — but I didn’t, so here’s a reminder for you. 😅

Refactoring and Fixes

After that first big refactor, I went back to making adjustments (fixes) and kept adding new features:

At this point we already crossed 47 commits and more than 8 hours non-stop. And yes, I didn’t take my eyes off the monitor. You can’t read 100% of everything Claude is thinking and doing; it’s a lot, but overall I’ve noticed you need to keep glancing at it and, most importantly, pay very close attention!

The processing time for multiple agents in parallel, many in reasoning/thinking mode, is really slow. Claude is one of the fastest compared to the others, but in practice I find it painfully slow.

After lunch, I decided to open YouTube on the side while waiting for Claude to finish the tasks. That means I wasn’t paying attention and only glanced over to see if it finished with “success” or asked me for some permission to execute something.

I don’t remember if it was at this point, but I went to look at what it had generated, and of course, by this stage it already had an application.css with more than 1000 lines, which I asked it to fix in this commit, and it broke one huge file into all of these:

Even the themes: everything was in a single file!! This is the level I’d call “intern”. Since everything “works”, it just keeps piling up code, all in the same place, and leaves worrying about it for later. Every intern does this at the start if nobody teaches them, and apparently the LLM does the same. It won’t proactively do anything you didn’t explicitly ask for. In fact, I never said in the prompt “remember to keep breaking things into small files”, but I should have.

But that wasn’t the worst. No sir, this commit has all the JavaScript in A SINGLE FILE. I think it was already past 4 or 5 thousand lines. Look at how many files it broke it into, it doesn’t even fit in this picture:

The problem is that I myself fell into what I’m criticizing here. I’d ask for a new feature, hit “reload” on the browser and voilà, there was the new feature! “WORKING”!! (Ruby on Rails is very productive!)

And that’s how it went, adding “it already works”, adding, “it already works”, and when I finally looked, horror show!!

At the last refactoring we were at around 9 hours of work. This is where we wrap up the day; we’re on the next day and, not counting the time I slept, we’re already at 17 hours, 70 commits. Roughly HALFWAY through the project.

All this to say the following: the BIGGEST part of Vibe Coding will always be REFACTORING, fixing bugs, and adding TESTS!

I18n - Internationalization

I got a little ahead of myself; before the JavaScript mega-refactoring, I had done another mega-refactoring: I asked it to extract all the English strings and already translate a Brazilian Portuguese option for me. Another gigantic commit with more than 1600 lines modified.

I wanted to make a separate section just to comment on this because this is one of the points where I think LLMs shine. They were originally built precisely to deal with natural language and translations. LLMs are very good with languages. In the old days I’d have to go through Google Translate, which was always pretty bad, and then find a native speaker to adjust the terms Google got wrong.

As expected, after extracting everything, asking it to adjust the tests to take i18n into account, and seeing that Portuguese was working, I started adding others just for fun and was very pleased with the result. I18n is definitely something that doesn’t make sense to do without an LLM these days. It’s orders of magnitude better than the old way.

The Last HALF

From the last big refactor to the end, there are about another 70 commits and roughly 14 hours, the end of the second day and the third day, with a roughly 15-hour break in the middle where I got a fever and had to throw myself into bed and stuff myself with medicine… but all good, the next morning I felt a bit better and finished it!

From there on, I kept adding the rest of the features, like emoji, emoticons, find and replace dialog, jump to line dialog, adjustments to the configuration system (via envs, via .fed), and Docker.

One thing I didn’t mention before, but that came before the I18n effort, was a REBRANDING. This is another thing LLMs are very good at solving: text substitution, knowing how to tell apart plain text, variables and code in general. I wasn’t very inspired and, at the start, I was going to make a MUCH simpler little web editor than what it ended up becoming, and I was just going to call it “WebNotes”.

But when it grew and I decided it was worth sharing publicly, I decided to give it a real name. That’s how “FrankMD” was born. But it’s not enough to just give it a name; now you have to go rename EVERYTHING inside the code, strings, documentation, etc. It was in this commit: a solid 700 lines of modifications.

Now “does it work??”

I’m writing this article at 5 PM on Sunday. At 7:25 PM on Saturday, I sent it to some friends on Discord to test, innocently thinking I’d already reached version 1.0.

And there I went, with a fever and needing to lie down, but wanting to reach 1.0!!

The issues themselves I killed quickly, but Syntax Highlight I didn’t know was going to become hell in my life. The first version came out quickly, in this commit

Don’t Reinvent the Wheel (duh)

Yes, it’s the most obvious cliché of all, but even I make this mistake. As I said at the start, my expectation for this project was to be little more than a Web “Notepad” for my notes, and it ended up becoming the main editor for my blog.

The text editor part started with the first thing that works first: just a plain textarea.

But on Saturday I wanted to add a line counter column that takes line wrapping into account, control over that wrapping, typewriter mode always centered in the middle of the screen, and sync between the text editor scroll and the preview.

Not counting all the dialog boxes that add things to the text, like images, videos, code and tables. Not counting the shortcuts for things like bold, italic. Not counting auto-save routines, line count stats, current line, etc.

For those who don’t know, the problem with syntax highlight is that you can’t edit directly on the colored text (because it has hidden tags that format the text). One way to solve this is to duplicate the text block: one in the background, which is the raw text and you can edit however you want, and another formatted and colored block with HTML exactly on top, which you don’t touch, but it updates with whatever is edited. That’s how Claude did it.

But there are a LOT of “edge cases”: alignment problems due to wrapping, problems with size and position to adjust the auto-scroll sync. I spent hours and hours fighting with this. Look at the kind of problem I was dealing with:

Everything got resolved when I decided: enough. I’m reinventing the wheel. Obviously this problem has already been solved. So I asked Claude to remove all the logic tied to the custom textarea and replace it with Code Mirror, which is an open source component for a code editor, with support for line counting, syntax highlight, and much more!

It wasn’t just those 5 commits; those were the main ones. They took a solid 3 hours or more to stabilize that code, plus multiple small adjustments over more commits. A good 6,000 lines of code modified. It’s the kind of refactoring that, in a real project, would have taken the whole week and still would have come out with multiple bugs and side effects. But for this, the LLM is also very good. Big refactorings, especially if you’ve prepared a good automated test suite, go quite well with LLMs.

This is the kind of thing that happens in real projects. I can’t blame the LLM, it’s entirely my fault for changing the project requirements: originally there wasn’t going to be syntax highlight!

Tests, tests, tests

The main recommendations for how to do vibe coding are the same as how to program the old way:

• Be careful with architecture choices (yes, it takes experience)
• Build small features one at a time, each with the right abstractions and immediately with tests
• Refactor from time to time to consolidate or abstract code into the right domains, adjusting and adding more tests

If you follow those 3 items, it already helps a lot. It’s not magic: all of these are tools that give feedback to the LLM so it knows what to do.

If you’re the kind of dumb customer who only says “oh, it stopped working” — you’re no good at talking to a programmer, and I’m sorry to say that LLMs won’t help you either:

• WHAT stopped working?
• Did everything stop opening?
• Did just one element disappear?
• Does the element appear but clicking does nothing?
• Can you click, but an error message appears?
• What message exactly?
• What did you do before that?
• Did you change anything from the previous test to this one?
• etc

ALL OF THIS and more has to be in the next prompt for fixes. Including server logs, command lines to reproduce the error, and whatever evidence can be produced, to make it easier to understand the error.

There’s no such thing as “it stopped working” — your head is the thing that never worked.

One thing I really liked about Claude was when a bug appeared that hadn’t existed before, but I didn’t know if it was from the last commit or from 3 commits back. And instead of just guessing at random things, Claude itself offered to manually do the equivalent of a git bisect and kept offering me one commit at a time to test and keep going until we found which one introduced the bug:

Optimizations and Checks

Throughout the project, 2 or 3 times I specifically stopped to check things like memory leaks and security holes. Even being a personal project, I didn’t want very obvious holes.

Be warned that Claude is a champion at scattering setTimeout calls in JavaScript and never calling clearTimeout on anything!

It’s not much, but I had more than one commit to delete “Dead Code”: code that, during a refactor, was moved to another module but forgotten at the origin. LLMs will always leave dead code behind, because they have no way to look at 100% of every file 100% of the time. Eventually it misses one thing or another. And it won’t cause any obvious bug. You have to prune it gradually, after each refactoring.

When I started really testing with long texts, I noticed the interface had “lag”, kind of slow. Two things seemed to be causing it: the statistical count of how many words and characters the text has was very aggressive.

Again, “it already works” … but slow …

Worse: when I first asked it to create the text editor, I didn’t say exactly how I wanted the “auto-save” to behave. So it did it in the most conservative, aggressive and slow way of all: save everything on every keystroke!!!

There were several other things like not updating the HTML Preview if it wasn’t open and things like that.

LLMs won’t make performant code right off the bat; you need to tell them how!

Performance is always a trade-off. For example, if I go as fast as possible, the rest may end up super insecure. If I crank up security too much, usability collapses. If I over-optimize, maintainability collapses. There’s no way to make everything perfect: one will always negatively affect the other, and only an experienced programmer knows how to choose (or goes through trial and error until getting it right for the specific case).

Again, it’s not the LLM’s “fault”; this is normal in any project and we have to keep adjusting these things all the time.

Now really, reaching the end

There’s still plenty of technical debt left. The app_controller.js file still has more than 2,000 lines. And this is AFTER I spent a solid 3 hours refactoring just this one. Now there are roughly 28 JavaScript controllers, but before there was only a single file.

Besides that, LLMs can’t be consistent all the time, especially when the project code grows a lot. There was one type of feature it always did server-side, but later decided to do client-side. I had to interrupt and say: “hey, why?”, and then it redid it the right way:

Any code written with zero human assistance ALWAYS comes out at the worst possible code quality. With my assistance, I think the code is at least minimally presentable. You can check for yourselves at my GitHub repository.

I recommend digging through the commits: at least one thing LLMs do well is document the history of what was modified in each commit, which makes it much easier to search later.

There was one bug where Claude got stuck in a loop, trying and failing, to figure out when my CSS broke out of nowhere. It changed something and asked me to test; I restarted the server, did a force reload, and nothing: broken.

It was Saturday night; I was tired and a bit feverish, but then the penny dropped. I had done something dumb earlier. I put “notes/” in the .gitignore, which was the directory where I was creating test Markdown files in the editor and didn’t want to commit.

However, that also started ignoring directories like app/views/notes/..., for example. And neither I nor Claude knew this, but when I asked it to search, voilà:

Tailwind build obeys .gitignore, so it was screwing up the CSS compilation. 🤬

When we fixed that, it started working, but by then 2 hours had gone by!

As I said, you have to stay sharp on the errors, watch why the LLM is doing so much trial and error, doing and undoing in the same place and getting nowhere. This isn’t uncommon and can eat up half your day if you’re not paying attention.

Conclusion

When I started this Friday morning, I imagined:

“Ah, a full day of work should be enough.”

And as always, every estimate is an underestimate. It’s already Sunday, end of the day, and only now do I think I’ve gotten close to version 1.0. It still isn’t perfect, but I think it’s at least minimally presentable.

Remember I did this at my pace of extreme hyperfocus, when I barely blink, my eyes dry out and I start to see everything blurry, and even my head starts to hurt a bit from staying so tense, concentrated on a single thing. It’s not a state I recommend.

Even those 30 hours over 3 days, the right thing would be 30 hours spread over at least 5 days.

If I had let Claude do everything on its own, without checking anything, it would have taken half the time and, in the end, I’d have code “that works”, but bizarre, with a single CSS file of around 2000 lines, a single JS file of around 8 thousand lines, everything with ZERO tests, and everything looking like a house of cards where you touch one small thing and break 10 other things without knowing why.

Overall, it was a good experiment. Knowing how and where to use them, LLMs are exceptional. As I said at the start, without the LLM I would have taken more than 200 hours to do it alone. Even going through several rough patches along the way, I only took 30 hours. So the LLM really did make me work at least 6 to 7 times faster, maybe more.

Finally I feel we’ve reached the elusive “10x Developer”. All you need is to be a senior first.

To wrap up, a mini-report from Tokei:

Breakdown by language:
┌─────────────────┬───────┬────────┬────────┐
│    Language     │ Files │ Lines  │  Code  │
├─────────────────┼───────┼────────┼────────┤
│ JavaScript      │ 137   │ 26,621 │ 19,922 │
├─────────────────┼───────┼────────┼────────┤
│ Ruby            │ 60    │ 8,449  │ 5,883  │
├─────────────────┼───────┼────────┼────────┤
│ YAML            │ 10    │ 3,477  │ 2,867  │
├─────────────────┼───────┼────────┼────────┤
│ Ruby HTML (ERB) │ 33    │ 2,927  │ 2,634  │
├─────────────────┼───────┼────────┼────────┤
│ CSS             │ 29    │ 1,619  │ 1,297  │
├─────────────────┼───────┼────────┼────────┤
│ Markdown        │ 1     │ 716    │ -      │
├─────────────────┼───────┼────────┼────────┤
│ HTML            │ 5     │ 369    │ 329    │
├─────────────────┼───────┼────────┼────────┤
│ Dockerfile      │ 1     │ 88     │ 46     │
├─────────────────┼───────┼────────┼────────┤
│ Other           │ 6     │ 145    │ 76     │
└─────────────────┴───────┴────────┴────────┘
The codebase is primarily JavaScript (60%) and Ruby (17%) by code volume.

So, roughly 33 thousand lines of code. This is a SMALL project! Big projects are 10 times bigger, with more than 300 thousand lines of code. I’d guess that at an iFood or Mercado Livre, with all the subsystems, it’s more than 1 million lines of code. Adjust your expectations!

I’ve been saying this for years: I LIKE LLMs, I use them a lot since they came out, and I’ve never had a problem with them. My problem is calibrating the UNREALISTIC expectations of “normies”, non-programmers: you’re never going to get an app like this with a handful of prompts without knowing exactly which components and techniques to use underneath.

This time, I decided to tackle another little problem that had been sitting on my todo-list for a while: having a self-hosted note-taking web app (to put on my home-server. Over the years I’ve used everything: Evernote, Notion, Obsidian, among others, but none of them really pleased me. So why not build my own exactly the way I want?

I’m going to split this topic into 2 articles: in this first one, I’ll talk exclusively about my application; in the second one, I’ll talk about the process of vibe coding with Claude. Spoilers: it took 3 full days (roughly 30 hours). 137 pull requests! Wait for the post-mortem.

The Problem

Overall, this is just me being fussy. Keeping notes shouldn’t be complicated: create a directory on your machine, open LazyVim, VSCode or whatever, done: edit the Markdown as pure code and be happy.

Anyway, recently I was just using Obsidian on a shared directory in my Dropbox. That way I could access it from my phone if I needed to. But it’s a pain because if I’m on another PC, I need to have Obsidian or some other editor installed. If I have plugins, I need to install those too.

In practice any other text editor would do: they’re just text files, but the inconsistency of having something different in each place, all misconfigured, demotivates me from writing.

In particular, I was using Obsidian and, later, LazyVim to edit my blog posts, which are also in Markdown. And here I have a bigger set of problems:

• there’s a specific path and Hugo frontMatter; I have to be careful with the title to generate the right slug, etc.
• there are images/screenshots that I keep manually uploading to S3, grabbing the URL and pasting into the post
• I avoid using tables because “drawing” tables directly in Markdown is a pain
• I keep Google Images, YouTube, etc. tabs open so I can keep grabbing links, alt-tab, and paste
• there’s no good preview, so I let a lot of little errors slip through (duplicated image url, for example)
• there’s no good spellchecker, so lots of little typos get through that I then have to keep fixing

I wanted to solve all these problems in one place: a beautiful editor like Obsidian that would fix all these inconveniences and let me focus only on my text.

FrankMD

Frank Rosenblatt was the creator of the Perceptron in 1957, which gave rise to modern neural networks. Since I built this editor entirely with AI, I decided to pay tribute to Frank.

So I named it Frank Markdown or Frank Editor (fed). This editor has all the basics you would expect in any editor:

• syntax highlighting
• HTML preview
• markdown formatting helpers (Ctrl-B for bold, for example)
• customize font family and size

But then I started adding some things specific to my personal taste and/or that would make my life easier for editing my blog posts. Let’s go.

Image Insertion

This is an important part for me. When I write posts about code, I’m always taking screenshots of my terminal or editor to illustrate. The process is a print screen that sends it to ~/Pictures/Screenhots. I open Nautilus (I’m on Linux) and run a little script I made to upload that image to a bucket on my AWS S3. I copy the generated link and add it to my post.

It’s “a little annoying” doing this every time. On top of that, sometimes I’d like to resize the image to make it more optimized. But that means going to the terminal and running magick screenshot.png -resize 50%, which is another manual step.

So I decided to make a dialog box with several options for this.

By default, I can configure a main images directory on my PC and it will display a grid limited to the 10 most recent. Or I can filter by name. There’s an option to link directly (in case I want to upload the image along with the html) or to serve from S3 and it will copy the generated link automatically (which is what I prefer).

Same thing for images on the Web (Google, Pinterest), where I can choose to download, resize and upload to S3:

And the link will be in the expected format ...amazonaws.com/frankmd/...jpg. All pretty, easy and practical! For me, this helps a lot!

It’s an extra, since I couldn’t skip integrating an AI; the last tab is for Nano Banana:

Nano Banana is really impressive. Look at what this prompt generated:

Even more important: I can see the preview immediately (ctrl-shift-v) to know whether I inserted the right image (something I used to screw up a lot editing in NeoVim, without seeing it):

For me, these image insertion helpers are the ones that are going to help me the most when editing my blog posts.

Markdown Helpers

Simpler than an image is embedding a video player. I can either pass any link with a random .mp4 file, or I can directly search YouTube and embed it properly:

It will insert the correct HTML, <embed ..., with the right URL and title.

I also built an easy way to add and edit tables:

And it will generate the Markdown just right. Never again do I have to sit there editing that garbage by hand to readjust columns or rows.

| Cabeçalho 1 | Cabeçalho 2 |
| ----------- | ----------- |
| Linguagem   | Nota        |
| Ruby        | 10          |
| JS          | 5           |
| Rust        | 6 😂        |

But if you want to do it manually, you can also do that:

I added this mostly because it would be weird to leave it out, but in general I prefer to write code blocks manually. But there it is for anyone who wants a visual mode.

Then, of course, it had to have an easy way to edit Emojis 😆 (ctrl-shift-e):

But what nobody would expect is that I also offer support for Emoticons!! ☆:.｡.o(≧▽≦)o.｡.:*☆

Customization

Speaking of Emoticons, that reminds me that I wanted this editor to be infinitely customizable. For example, of course I added internationalization and it has Japanese!!

And other languages too; go poke around later. It has Portuguese too!

“What’s the best font for programming?”

Who knows! That’s why I added several to choose from:

Since I use Omarchy, I also wanted my editor to support exactly the same themes:

In the README everything that can be customized is documented. You can customize many things through environment variables and also through a .fed file, automatically created in the directory where you open this editor. There’s plenty, so I recommend poking around.

Focus on the Text

Obviously I included a “Typewriter Mode” that keeps my cursor closer to the middle of the screen and centers the editor, while hiding all distractions.

I normally prefer TUIs, but I have to admit that using a browser has the advantage of giving me access to extensions. The most useful one, without a doubt, is Grammarly, for any language:

But beyond that, I added an “AI” button in the toolbar (which is configurable via ENVs and a config file — read the README). And it does this:

It sends to your LLM of choice (local Ollama, OpenAI, Anthropic, OpenRouter, etc.) with a prompt telling it not to rewrite your text, only to check grammar, spelling and errors of that kind. Then I return a “diff” interface to compare and accept, edit or cancel.

I think Grammarly alone is already enough, but it cost nothing to build this one, so I built it.

Hugo Blogging

This blog is made with Hextra/Hugo. That’s why I wanted to already bake in an easy way to create new articles in Hugo. It starts right from the option to create a new document:

And it already creates it with the frontMatter, automatic slug generation, timestamped subdirectories and all the rest:

Like I said, this editor was built mainly to make my own workflow easier.

Self-deploy vs CLI

Originally I thought of this project as a Notion-light or something like that. A web editor that would deploy to my home server and serve only as an organizer, a place to put notes bigger than a post-it (like the history of my Linux configurations, step-by-step commands, etc.).

But as I kept building the app, more and more it grew and started looking like a desktop app. But by then it was too late. I wanted to use Ruby on Rails 8 (to shake off the rust and because I like it). Only halfway through did I think I should have done it in Node, because now I can’t embed it in an Electron app anymore.

Fine, the idea is to be a Markdown editor for programmers. Every programmer has Docker. So I wrapped it in a little shell function and I can just land in any directory on my Linux and type:

cd ~/Projects/akitaonrails-hugo
fed .

Read the README of the project to learn how to add it to your .bashrc. And doing it this way, it will work on my Omarchy exactly like any other native app:

In reality, I’ll use both ways: as if it were a native app. And as self-hosted, to organize a central place with my notes — which will be separate from where I organize my blog posts. So it really does have multiple uses.

Conclusion

I’ve summarized the features; there are several little things you’ll discover as you start using them. Everything is clickable; if you click on the app title, there’s an About:

Right-click on top of selected text has a formatting submenu; Ctrl-I works for italic; Ctrl-H has a basic “find and replace”; there are a bunch of keyboard combinations to access things.

Oh right, I didn’t even mention that you can quickly search files by name or by content using Ctrl-P and Ctrl-Shift-F:

To make sure everything is working, this very article was written entirely with my new editor. And I’d say that, if it isn’t perfect (for me), it’s at 99%. Feel free to open Issues with bugs or features that would make sense — remembering: the idea is to stay away from replacing VSCode and having EVERYTHING. I need it to have only ENOUGH.

Considering it cost me 3 days of work and that I didn’t write a single line of code, the result is impressive. Yes, text editors are very well documented applications with tons of training material — that’s why Claude managed to build it without trouble. Don’t get too impressed. That said, yes, I wanted a custom editor for my personal use, one that would be beautiful to use, and it managed to deliver, so I’m satisfied.

Don’t miss PART 2 for the details of how this was built.