From Corporate SaaS Vibes to Terminal-First UX: The Story Behind Terminol

About two weeks ago, I somehow found myself inside Google AI Studio, poking around and experimenting. One thing led to another, and I ended up playing with the shadcn/ui terminal component to prototype a different kind of UX.

I started simple: a terminal box, a few commands, some ASCII logos. It was fun. A little toy interface that felt closer to how I actually think and work, rather than yet another polished "hero section + cards + CTA" layout.

That’s when something clicked.

Why a Terminal-Like UX for KODKAFA?

KODKAFA is, at its core, a personal engineering sandbox. It is not a corporate SaaS platform, not a startup landing page, not a generic dev tool marketing site.

But my previous design didn’t reflect that at all.

It looked too corporate, too "production SaaS". It gave visitors the wrong impression about what KODKAFA is and what they should expect. Even worse, with a static, pretty UI, I had almost no way of understanding:

• Why people landed on the site,
• What they were trying to do,
• How far they got before bouncing.

So I started thinking:

What if interaction was not optional?
What if the only way to "use" the site was to type, explore, and react?

A terminal-like UX solves exactly that:

• It forces interaction instead of passive scrolling.
• It gives me a natural way to observe user intent (what they try to run, what they look for).
• It gives me a perfect surface to ship browser-based tools as commands, instead of bolting on yet another separate UI.

That’s where the idea of building something more serious than a toy terminal really began.

The Over-Engineered Phase (a.k.a. the Spaghetti Era)

I started hacking on the prototype using Cursor, wiring up commands, ASCII art, and little helpers here and there. It escalated quickly.

What began as a "fun little UX experiment" turned into:

• Conditionals piled on top of each other,
• Input-handling hacks for interactive flows,
• Increasingly tangled state just to keep the illusion of a "real" terminal.

At some point, the codebase stopped being fun and started to feel like spaghetti that wanted to fight back. That was the moment I stepped back and asked:

If I’m already committing to a terminal UX, why not build this properly?
Why not design a real plugin architecture, with commands as first-class citizens?

So I did the thing every engineer does when they hit this point: I opened a new doc and started sketching an architecture.

Enter Antigravity and a Real Architecture

Around that time, Antigravity dropped, and I figured: why not use this project as the test bed?

That’s when Terminol really started to take shape:

• A provider that owns state: history, output, input modes, overlays, modals.
• A command registry, so each command is a plugin with a clear interface.
• A parser, so commands like help --tag code don’t turn into ad-hoc string splitting everywhere.
• A UI adapter that renders the terminal using shadcn/ui, but keeps the core logic headless.

In other words: if this thing was going to live at the heart of my personal sandbox, it had to be structured like a proper component, not a fragile demo.

And when it came to the registry, input handling, and UI pieces, I didn’t overthink it — I leaned on shadcn as the base and focused on making the architecture solid and extensible.

Naming It: Dyslexia Power-Up and a Little Bit of Medicine

Once the project started to feel "real", I needed a name.

So I did what everyone does: went hunting for names, only to discover that all the good ones were either:

• already taken by great projects, or
• quietly living somewhere on npm, GitHub, or in old blog posts.

At some point, I embraced the dyslexia power-up approach: lean into a slightly broken, typo-like name that still sounds right.

I wanted it to feel a bit like a medicine for terminal UX in the browser, something you take to solve the problem of boring, passive landing pages and overly corporate vibes.

That’s how I landed on Terminol.

It’s close enough to "terminal" to be recognizable, but with a twist, and it quietly hints at paracetamol in the background. A terminal that acts like a little pill for your UX.

I liked it immediately.

So What Is Terminol, Really?

Right now, Terminol is:

• A plugin-based, browser-first terminal component for React.
• Built on top of shadcn/ui and Tailwind CSS, with a headless, testable core.
• Designed to make it easy to:
  • Register new commands as plugins,
  • Build interactive flows (wizards, prompts, consent flows),
  • Render modals and overlays directly from commands,
  • Track usage and intent when you need to.

And on kodkafa.com, it’s the primary UX:

• Visitors are dropped straight into the terminal wrapper.
• If they want to understand what this sandbox is, they interact.
• Their intent is visible through how they use the interface, not just where they scroll.

Where the project goes from here is open. It might remain a personal tool, it might grow into something other people adopt. Either way, it’s already doing its job for KODKAFA.

Try It Yourself

You can see Terminol in action live on the KODKAFA sandbox:

• Live demo: https://kodkafa.com

The code lives in its own repository and is meant to be reusable, forkable, and breakable:

• GitHub: https://github.com/kodkafa/terminol

If you want to bring Terminol into your own project quickly via the shadcn registry:

npx shadcn@latest https://kodkafa.com/registry/terminol.json

From there, it’s up to you whether it stays a toy, becomes a core part of your product, or just lives as a beautifully over-engineered terminal in your own sandbox — exactly where it started for me.`