The mouse is optional. Speed is not.

Every accounting tool I have built has been keyboard-first. Fast-XML was, and SAHARA CORE is. That is not nostalgia for old software. It comes from doing the data entry myself.

I keep the accounts for our family business. When my father travels, that whole workload lands on me. So the entry screen is not a design problem I read about — it is where my evening goes.

Two different categories of object

Open a modern accounting product and you get a spacious interface. Lots of air, rounded cards, a large button to start a new transaction. Everything is discoverable, largely because there is very little on screen to discover.

Open Tally and you get something that looks like it came from another era, and people who have used it for twenty years get irritated when you try to replace it.

Both are called accounting software. They are not the same category of object. One is optimised for a person’s first ten minutes with the tool. The other is optimised for their eighth year.

Optimising for the first ten minutes is a real choice, and it makes sense when the person deciding to buy is not the person who will use it. It is just not the thing an operator needs.

”Fast” is not a vibe. It is three specific things.

Muscle memory. The same key does the same thing on every screen, permanently. After a month the hand knows it without the head being involved. The moment a product “refreshes the navigation”, it throws away a year of somebody’s training. Discoverability is a beginner’s need; consistency is a professional’s need. A lot of software optimises for the first and calls it good design.

No hunting. Everything needed for the decision is on the same screen at the same time. If I have to scroll to see a balance while typing an amount, I am hunting. If a dialog covers the figure I was comparing against, I am hunting. This is not a milliseconds problem, it is an attention problem — every hunt pulls the eyes off the document in front of you, and then you have to find your place on it again.

Entry flow. You should never be forced to leave a transaction in order to finish it. A party that does not exist yet should be creatable without abandoning what you are typing. Going back should go back exactly one level, and never quietly discard what was entered. The value is not the seconds saved. It is that an interrupted entry has to be rebuilt in your head from the beginning.

None of the three is about how quickly the server responds. The bottleneck in data entry is almost never the machine. It is the human context switch, and mouse-first design manufactures context switches by default.

Density is not clutter

Somewhere the industry decided that a screen with a lot of information on it is overwhelming. For a visitor, it can be. For someone who works inside that screen for hours, empty space is distance the eyes have to travel.

A ledger is a table. So give them a table — real rows, tight line height, figures right-aligned and monospaced so the digits line up and a wrong number is visible as a shape before it is read as a number. Density done badly is clutter. Density done well is a cockpit, and nobody flying a plane wants bigger buttons with more padding around them.

What that means for what I am building

SAHARA CORE is in active development and internal testing. Nobody outside our own business is using it, and I am not going to pretend otherwise.

But the design constraint is fixed, and it is this: if an experienced accountant is slower on my software than on what they use today, the redesign failed. Not “it looks more modern, they will adjust.” Failed. Their speed is the specification.

That is an unfashionable thing to build toward. It rules out a lot of interfaces that would photograph better. I still think it is the right trade, because the person I am building for is not evaluating software — they are trying to get through the day’s entries before the shop closes.

The mouse is optional. Speed is not.