Terminal is Home — Why I Keep Building CLI/TUI Tools
I build on both ends of the stack, but I keep coming back to the terminal. Here is the honest reason why.
Let me be upfront about something.
I build on both ends of the stack. React, Tailwind, shadcn on the frontend. Express, Redis, TCP servers, Rust on the backend. I have shipped polished UIs and I have written async networking code from scratch. So when people see that two of my most invested projects are a terminal chat app written in Rust and a keyboard-driven task manager that runs in your shell, the obvious question is: why not just build another web app?
It is not nostalgia. I did not grow up hacking on a green-screen terminal. I am not trying to be a 10x engineer aesthetic guy on Twitter.
The honest answer is simpler and a little harder to explain.
The GUI lies to you
Every time you build a GUI, you are making a hundred invisible decisions for the user. Where the button goes. What color signals danger. Whether the modal closes on outside click or not. You are constantly managing attention — pulling it here, hiding it there.
That is real work. And it matters. But it also means that most of what you build is noise management.
The terminal does not do that. There is no hover state. There is no animation to soften a hard truth. When something prints to stdout, it just says the thing. When a command fails, the error is right there in your face.
I started noticing that when I worked in the terminal, I thought more clearly. Not because I am a different person there — but because the environment forces a different kind of precision.
You cannot hide sloppiness behind a nice gradient.
Building rchat: one week, one idea, no shortcuts
rchat started as a stupid question: what is the minimum viable chat system I can build on a LAN?
No accounts. No servers in the cloud. No onboarding flow. Just two machines on the same network, talking to each other through TCP.
I built it in Rust in a week. And that week broke me open a little.
Rust does not let you be vague. You cannot just "figure out the state management later." The borrow checker wants to know right now who owns what, and if your answer is unclear, it will not compile. Full stop.
Managing concurrent client sessions, designing a message protocol that is both human-readable and predictable, making sure one client crashing does not take down the rest — these are not frontend problems. There is no useEffect cleanup that saves you here.
What I learned in that one week was worth more to me than months of building another CRUD app.
And here is the part no one talks about: the terminal user trusts you more. When someone opens a CLI tool, they already decided they want control. They are not waiting for a walkthrough. They want to type something and have it work exactly as described. That contract is clean. That contract is honest.
Building Ritual: two months of real design
ritual-tui took two months. It is a keyboard-first task manager — three panes, infinite nested tasks, a live timeline, local-first storage, and a sync system using short-lived codes so you can transfer state between machines without locking into cloud storage.
The most interesting design problem was not the code.
It was: how do you make a terminal app feel fast without making it feel cold?
Every GUI framework gives you animation, color, spacing, transitions. Ink (React for the terminal) gives you a box model and re-renders. That is it. So you have to be deliberate. Every keybinding choice is a UX decision. Every piece of text you show is fighting for limited real estate.
I spent more time thinking about interaction design on Ritual than I have on most of my web projects. Because in the terminal, you cannot paper over bad design with motion and color. The structure has to actually hold.
Three-pane navigation (1, 2, 3 to jump directly, Tab to cycle) sounds like a small thing. But getting it to feel right — getting the user to feel at home — took real iteration.
That is what the terminal teaches you: constraints are not the enemy of good UX. They are the prerequisite.
Why I keep coming back
I build on both ends. I genuinely like React. I write backend services. I will keep shipping all of it.
But the terminal is where I go when I want to build something that works — no noise, no performance theater, no marketing color palette. Just a tool doing exactly what it says.
There is a certain kind of developer who feels most at home in the terminal. Not because they are old school or trying to prove something. But because once you build something that runs in a shell and does its job cleanly, you understand what software was always supposed to feel like.
Fast. Honest. In control.
That is why I keep coming back.
If you want to look at the code — rchat and ritual-tui are both open source.
