notes

We were redesigning our app’s UI, and I wanted to give the loading spinner some love.

It seemed like a small, enjoyable bit of work. I found a dot-matrix loader that looked cool and thought it would be a nice detail to bring into the redesign.

Several versions later, I ended up with a simple progress bar across the top and a dot-matrix spinner on the right. Getting there involved two dotted lines, a notch, an aurora, and a lot of opening staging and changing my mind.

Some context: this is a dense, multi-tenant B2B application built with Laravel and Inertia. There are plenty of queries and aggregations behind the screens, and some interactions take a moment. People need to know that their click registered and the app is doing something.

Our audience is mainly busy business professionals. They’re in the app to get through their work. They shouldn’t have to look around the screen to figure out whether anything happened.

We already use loading spinners on buttons and skeletons in slideovers. Extending that kind of local feedback to every interaction would have meant a much larger refactor, which is another story. I also wanted a global indicator for work that didn’t neatly belong to one button.

It started with dots

The first version put the dot matrix in the top-right corner, beside the account menu. I really liked it. The dots had a bit of character, and it felt like a small detail that had received some attention.

The problem was that I knew exactly where to look. Someone clicking a link elsewhere on a busy screen might never notice it.

So I tried carrying the same idea into the progress line at the top of the page. One row of dots, with a brighter band pulsing along it. It looked okay, but it was still too easy to miss.

My next idea was to add another row.

Two rows looked terrible. They were more visible, certainly, but the extra green pixels across the top made the whole thing feel clumsy. I wanted clear feedback, and I was getting a very conspicuous dotted border.

A small island

I work on a MacBook and have Alcove installed. It gives the notch a Dynamic Island-style interface for notifications and other activity. Around this time, a meeting notification popped up there, and I thought: we could do something like that.

A little notch dropping out of the top centre of the app would give the loader a consistent, obvious home.

I played with the shape, spacing, and animation, trying to get that smooth spring feeling. It was super cool. The dot matrix sat inside the notch, which dropped down when something was loading and tucked itself away afterward. I was happy to ship that version.

Then I opened our staging preview and started navigating around.

The notch appeared on every navigation that lasted long enough to trigger it. Something that felt lovely when I replayed it in isolation felt surprisingly jarring when it kept dropping into view as I moved through the app.

There was also a timing problem. I had set a 300 ms delay before showing it, so immediate interactions wouldn’t get an unnecessary loading animation. But plenty of interactions finished in under a second. If a request ended shortly after that threshold, the notch barely had time to appear before it disappeared again.

That gave me a flicker instead of the smooth animation I had spent time on.

I added a minimum visible time: once the notch appeared, it would stay for at least 1.5 seconds, even if the request finished sooner. That applied to the indicator; the page could become usable while it was still visible.

It looked much better. But as I kept navigating, something still felt off. The timing was calmer, yet the repeated appearance kept drawing my attention. I couldn’t quite settle on it, so I parked it for a bit.

The aurora phase

Later, while browsing the Effect blog, I noticed a ripple-like animation in the top bar. That gave me another idea: what if the loading state lived in the header itself, using the same dot-matrix style?

The first attempt looked nice, but again, it wasn’t clearly visible. So I expanded the dots into a grid that occupied the whole top bar. I added a fade toward the bottom, then replaced the simple pulse with an aurora-like animation moving through the grid.

I really liked this one. It gave the header a bit of life without needing a separate shape to drop onto the screen. I shipped it into the preview and started using it.

And, after a while, it got annoying too.

There is a big difference between watching an animation because you made it and seeing it repeatedly while trying to do something else. I kept enjoying the first few appearances and judging the design from those. A longer session in staging gave me a much less flattering view.

The header was moving while I was trying to read the page. Every navigation was another little performance. The actual content already had plenty going on, and I had given the loading state a generous share of the screen and my attention.

Back to a line

I was testing all of this in Dia. At some point, I noticed its simple progress animation and thought: let’s just stick to something like that.

So I landed on a thin progress bar across the top, with a brighter leading edge and a softer trail, plus the dot-matrix loader on the right.

The line gives an immediate sign that something is happening. The dot matrix keeps a little of the character that started this whole exercise. There’s no notch arriving in the middle of the header, and no field of dots moving behind the navigation.

It felt much more comfortable as I moved around the app. I could register the feedback and carry on looking at the thing I had actually opened the page for.

What I took from it

The most useful test turned out to be continuing to use the app after the animation stopped being new. I could make almost any of these versions look good in a short preview. Repeating the same ordinary navigation over and over made the tradeoffs much easier to feel.

Visibility and distraction needed to be considered together. The corner spinner was easy to miss. The notch and aurora were easy to notice, but also hard to ignore. I had spent a lot of time moving between those two problems.

Timing mattered just as much as appearance. The delay and minimum visible time changed how the notch felt without changing its design. They also introduced a tradeoff: preventing a brief flash meant keeping the indicator around after some requests had already finished. Those values deserved the same attention as the spring curve.

I also learned something about borrowing ideas. A meeting notification in Alcove is meant to pull my attention away for a moment. A loading indicator that appears throughout an ordinary session has a different job. I loved the reference, but I needed to account for how often our version would appear.

I’m glad I tried the more elaborate versions. They helped me understand what I wanted from the simple one: feedback that is easy to notice, easy to understand, and comfortable to see again and again.

I started out wanting to give the spinner some love. Apparently, that involved giving it a few increasingly elaborate personalities before asking it to calm down.

We started Blistt because one steel broker was spending hours every week on repetitive billing work.

But once we started building, we realised the problem was bigger than billing.

The way a broker works doesn’t neatly fit into a conventional software workflow.

A deal might start with a call or a WhatsApp message. From there, the broker has to keep track of the buyer, seller, quantity, rate, GST, brokerage and payments.

So we kept going back to the actual workflow and asking:

What can we remove?What can we simplify? What can AI take care of?

That’s how Blistt evolved.

The workflow is simple:

• Make the deal.
• Upload the document.
• Blistt extracts and fills in the details automatically.
• Review and track the transaction in one place.
• Generate invoices and outstanding bills in a click.

The goal wasn’t to add another software layer to their work.

It was to make the work itself simpler.

What started as a conversation about billing became our first real experience of building a product around a specific industry.

And perhaps the biggest thing we learned:

AI isn’t the starting point.The problem is.

https://blistt.com/

When we started speaking with people we came across many interesting problems.

One conversation led us to an iron and steel broker.

His billing and invoicing process was almost entirely manual.

Every week, he had to enter the details of each transaction like buyer, seller, quantity, GST and other details. And because he often dealt with the same parties, much of the work was repetitive.

Tracking payments and outstanding amounts was another challenge.

A lot of it happened over calls and WhatsApp.

As we understood his workflow, we realised something:

The problem wasn’t simply that he needed a better billing tool.

He needed a system that actually understood how an iron and steel broker works.

So instead of trying to fit his work into a generic accounting or invoicing system, we decided to build around his actual workflow.

We started talking in terms of metric tonnes, GST, buyer-seller deals, party-wise transactions and the way brokers actually work.

And that’s how Blistt came to life.

The idea was simple:

Take the repetitive work out of the process, make transactions easier to track, and let the system handle the parts that don’t need to be done manually every time.

We built Blistt around that idea.

How I Started Understanding LLMs

An AI model can produce a polished answer in seconds. But producing even one small part of that answer involves several layers of computation—tokenization, numerical representations, learned patterns, probabilities, and a lot of matrix multiplication.

I had been using AI for a while, but I could not have explained what was actually happening between a prompt and its response. I assumed the basic idea might be simple. After all, so many companies were building AI products. But man, I was wrong.

Using vs. understanding

When we started our company, we wanted it to be AI-first—not simply because AI was trending, but because we were genuinely interested in what it could make possible. We built AI-powered products that helped solve real business problems, and the experience changed how we approached software development.

After spending seven or eight years writing software in the traditional way, the difference was hard to miss. Development and iteration became faster. We could spend more energy deciding what to build and less time wrestling with every implementation detail. AI opened doors for us as builders.

Still, being able to build with AI is not the same as understanding how it works. I could use a model, write prompts, and integrate it into a product, yet I still could not clearly explain why it produced a particular answer.

The missing steps

One day, my co-founder shared 0xkato’s article, How LLMs Actually Work. Unlike many introductions I had encountered, it went beyond broad analogies and gave me enough context to follow more technical discussions.

It also made me notice a common problem with explanations: once we understand something, we forget which parts were difficult at the beginning. We unconsciously skip steps that now feel obvious to us. Those steps, however, may be exactly what a new learner needs.

Think about explaining mathematics to someone encountering it for the first time. You would not need to explain every number, but you also could not rush past addition and multiplication. The goal is to find the useful starting point: foundational enough to build real understanding, but not so basic that the explanation goes nowhere.

One token at a time

Here is one such starting point: an LLM does not read and write text exactly as we do. It first breaks text into smaller units called tokens. A token might be a complete word, part of a word, punctuation, or a chunk that includes whitespace, depending on the model’s tokenizer.

The model converts those tokens into numerical representations and processes the relationships between them. Based on patterns learned during training, it produces a probability distribution for what token could come next. It chooses a token, adds it to the sequence, and repeats the process. What looks like a flowing answer to us is generated one token at a time.

That description leaves out an enormous amount of detail—and that is precisely where this series begins.

What comes next

I am approaching this as a builder and active learner. I often need to revisit an idea a few times before it truly clicks, which also means I remember the questions and missing steps that made it confusing.

In the coming articles, I will build a practical mental model of LLMs from the ground up. We will explore transformers, tokens, embeddings, positional information, attention, training, and text generation in plain language, using examples before equations wherever possible. The series is for developers, founders, and curious AI users; no machine-learning background is required.

The goal is not to turn every reader into an AI researcher. It is to make the technology less mysterious and give you enough understanding to read, question, and use it more thoughtfully.

We will begin with the big picture: what a transformer is and how a prompt becomes an answer. From there, we will follow the journey step by step—starting with tokens, what they are, why models use them, and why one “word” to us may not be one token to an LLM.

This series was inspired by 0xkato’s How LLMs Actually Work. It follows some of the same conceptual path, but the explanations, examples, and interpretations are my own.

When we first decided to start something of our own, we knew we wanted to work in the AI space.

But honestly, we had no idea what exactly we wanted to build.

So, like many people starting out, we began looking for problems.

We came across several ideas that seemed interesting. But there was one thing missing - we hadn’t validated those problems with the people who were actually facing them every day.

And without that validation, moving ahead didn’t feel right.

So we decided to pause and not pursue any of those ideas.

Around the same time, we started telling our friends and people around us that we were exploring something in the AI space.

We asked them about their businesses, how things were going, and whether there was anything they struggled with regularly.

And that’s when something interesting happened.

They began opening up, sharing those minor hurdles and the same old tasks that kept cropping up in their daily routines.

And for us, that was a turning point.

Instead of trying to guess what people might need, we started listening to what they were actually struggling with.

That’s when we began identifying real problems - this time with validation from the people facing them.

Since then, we’ve had the opportunity to work on a few such problems and explore how technology and AI can help make business systems simpler and more efficient.

We’re still exploring and figuring things out.

But it feels good to be building solutions around problems that are actually real.