A few days ago a friend reached out to me. He was about to open a small business and needed a simple invoicing system. Nothing fancy, just keep track of inventory and sales, and keep a record of the dollar price according to the BCV (Central Bank of Venezuela). No fiscal printer integration, no POS hardware, no payment methods. None of that.
That is how Bllt was born. This post is not about how it works inside, but about why it ended up the way it is. The technical side, what it does and how it is built, is on the Bllt project page.
First things first, it has to work without internet
Before thinking about frameworks, I thought about something more basic. In Venezuela electricity is a complicated topic, and when the power goes out, the internet usually goes with it. A sales system that depends on a remote server leaves the business unable to sell right when it needs to the most.
So the first thing I was sure about, and the most important one, was that it had to work offline. The data had to live on the business's computer, in a local SQLite (opens in a new tab) database.
Tauri, Electron and the usual problem
My first idea was to use Tauri (opens in a new tab). I have wanted to use it in a production app for a long time, and a small project looked like the perfect opportunity. But the usual problem showed up, Rust (opens in a new tab).
That mattered more than it seems, because a good part of the code was going to be written by an AI agent, and I do not approve code I do not understand. With Electron (opens in a new tab) and TypeScript (opens in a new tab) I could quickly review and fix anything the agent wrote. I chose Electron for development speed.
The phone complicated the local database
While we talked, my friend mentioned he would like to see a summary of the day's sales on his phone. That created a new problem, because if the database lives on the computer, how does that information reach the phone?
My first thought was to connect the devices over the local network. It works technically, but for a regular person it would be a bit confusing. Going through the options and talking it over with Claude (opens in a new tab), we reached another conclusion, which was to use Cloudflare Workers (opens in a new tab) and D1 (opens in a new tab) to keep a mirror of the data, and have the phone read from that mirror.
That was one more reason to stay with Electron and TypeScript, since the desktop app and the Worker could reuse the same logic. I kept the phone app as simple as possible, a PWA (opens in a new tab) that shows the minimum information needed without overloading it.
A spec before dinner, an app after breakfast
The same day I talked to him, I started writing a project specification document with Claude's help. We spent a good while refining it before dinner.
The next day, before breakfast, I gave it a single instruction: "apply the document". I was extremely surprised. By the time I finished breakfast the app was complete, following every guideline I had defined, even the folder structure, the way files were written and what each one was for. Of course there were small things we had to fix, but it was exactly what I asked for, with the code I asked for.
I had not used Claude for a while, because Opus was working pretty badly for me, so I decided to use GPT-Sol and GPT-Luna for a good stretch. And to be fair, they worked really well, especially GPT-Luna. But this new version, Opus 5.0, and shortly after Opus 5.5, since they came out relatively close together, were incredible. It felt like Claude won me back, because it had lost me.
Refining until we liked it
Then came several changes and refinements, until we reached a product we liked, one that met the business's needs and worked.
Two computers, days before the opening
A couple of days before the opening, my friend told me he now wanted to use the app on two computers. With a local database, that is not a small change.
After analyzing alternatives, the answer was in something we already had, the Cloudflare Worker. We made changes to add the ability to sync different computers. What started as a mirror for the phone also became the meeting point between the business's PCs.
What I would do differently
There is something I did notice. The second PC my friend wanted to use had fairly limited resources; even opening the installer had performance issues. After that, at least, the app has opened and run fine.
But it left me thinking. Maybe that was a requirement I did not know about, and it could have been solved better with a Tauri app. It is something worth analyzing.
Open source from day one
When I started the project I was sure it had to be fully open source, and it had to be prepared for that from the start. There are surely hundreds of people in Venezuela with the same problem, so I tried to make it as generic as possible so anyone can use it.
If you have a small business, or know someone who does, Bllt is free at bllt.juanl.dev (opens in a new tab). The code is on GitHub (opens in a new tab). And if you want to see what it does and how it is built, the project page covers all the technical details.
