I'm currently lying on my couch on my laptop with a cricket hidden somewhere in my kitchen, going wild. So I figured this would be an excellent time to talk about an idea I've had rattling in my head for a minute but have struggled with the proper formulation for how to make it work.

Since earlier this year, I've been thinking of programming a POS. I work a retail job as my main gig currently, and since I've been doing that, I have learned about the fascinating but horrifying world of POS. Most of these systems are riddled with problems. Let's go over a couple, shall we?

Clover

Clover is a register POS that uses the android platform as its base of operation. From what I know or assume, Java mainly powers it (which isn't uncommon for POS applications), but what is unique is that it uses a customized Android Linux kernel, which is supposedly "unhackable."

Clover, on the surface, looks like a beautiful pick, having many different options to use, ranging from portable table-side systems to full-blown POS registers with a nice sturdy build. However, there are some significant issues with them, and I know this because this is the register I use at work. The presentation and the build are perfect, but when it comes to software, problems arise. I find their register to handle extensive inventories terribly, having essential inventory control such as pricing, tax categories, SKU codes, product codes, and naming. All of this is good, but a question. Where are batch edits?

I've used Clover for a long time, and it baffled me why batch editing didn't exist; you can edit one product at a time, but what if you have a bunch of products worth $1, and then the company raised them by 50 cents? Well, let's say there are 16 products by that company. It takes four presses to get to their category (from going into the inventory to getting into the category). Then you press eight times to go into a single item, select the price, delete the set price partially and add 50 cents to the product, only to go back to the previous page to repeat the process 16 more times. That's 128 presses that have to be done manually by the manager/stocker/inventory manager/etc. Every single time something like this happens. Let's not forget a margin of error on the user's part. So roughly, you have to press give or take 132-158 times to handle all these product price changes.

When you work with multiple wholesalers and multiple companies that all change prices on the regular, there is no reason they couldn't have the ability to select a set of products and modify something about them, especially in pricing. Drinks, candy, etc., all have prices that match, so why hasn't Clover had this ability? And before anyone says it, I know Clover has an app store for installing different features, but my point is you shouldn't even need to go to the store to get such a feature. You shouldn't even need to get inventory managing software for this feature; it should come with Clover by default.

Another thing, and a pretty big thing with Clover, is that credit/debit cards are handled so... so... poorly. Let me put it this way, every credit card reader you have ever used has something called an SVC Fee. The SVC Fee, or service fee, is a fee that is charged to the customer for using a card. This fee has been a known thing for a long time in the retail world, that using a card is more expensive, about 3.5% more costly for our credit card readers. Now, for some reason, with Clover, they don't charge the customer a service fee through card transactions. Why!? It's insane that a register company that makes as much money as them doesn't have a feature as necessary as this one built-in!

So now you have two options since the register doesn't do this, you have to find an app that applies a fee on checkout, which can be sketchy, leads to custom items replacing the actual product names, and don't work right half the time. Or, you have to apply a 3.5% increase to all your products and then discount them depending on what the customer is paying, which means good luck on those split payments if they don't tell you they're going to pay with cash and card. It's insane how something so seemingly simple can cost a business big. My current job, in which I know the owners personally, lost over $2,000 because they didn't know about this issue until it was too late. A register, something you are supposed to trust down to its name (Point-of-Sale), cost you already a lot to install, but now even more because of a significant issue on their part. It doesn't make sense in any way.

Clover is so clean and straightforward, but it takes its simplicity to the point that it hurts itself, and I have loathed it since it appeared. I liked it a lot initially and respected what it's doing, but these issues have been a part of it for so long now, and it just seems like the creators don't care.

I want to note that there is the option to enable a $1 service fee to cards, but from what I know, there are even issues with that. They need to fix it and make it work and not hide it from the user. A business like ours cannot work with something that makes an active effort in its inabilities to harm our profits and affect our income because of a mistake on their part.

ParadisePOS

ParadisePOS is a semi-decent one. It was developed on IOS and used an IPad as the screen, it's features are pretty big, and it's generally fast to use on account of Objective-C being used as its primary language. I like many features, age-gate for 18+ older products, an actual service fee because it uses Star as their card reader and general performance. I hated sitting there on Clover waiting for it to respond. This one speeds right on by. It does a great job in so many things, but I found the biggest issue with them is the UI. Everyone, except one person, could barely use it because of the daunting UI. This wasn't just a UI with a bunch of stuff on it, but most of the UI was solid color on color rects with no sense of direction, the UI felt like a prototype to what they were aiming for, but it never left the stage. Something about it felt off.

I like ParadisePOS and like a lot of what they're trying to do, but they need to bring in a UI designer and a graphics designer because their UI is horrible in terms of user experience. It's even hard for me to use it, and I've been working with registers for a while. A register should be easy to use, quick to learn, and fast to master, and this is because it will take less time to train a new employee on how to use the register efficiently. When a register can't do this, it struggles to take off or even become efficient in a large corporate environment, instead locking itself in a constant state of being a "mom-and-pop" shop register.

A New Register

Now, even though I said all these things about both registers, I love them both. I want to point out something, did you pick up on the flaws I laid before you? The first register has a beautiful presentation and excellent UI but falls short in the software; the other is horrible in the UI but excels. It seems registers tend to be this mix of both, never sitting on one or the other. Even Walmart has these same issues with the human-controlled registers, not even having a screen half the time and just using something that looks like it came out of the 90s. So, this is where my idea comes in.

I've been researching and looking into ways of making a POS; they are simple, most of them stupidly so. It's a program that interfaces with a product scanner, credit card reader, and a screen. It will receive codes from the scanner, find the product, and add it to the list of products the customer will buy. On checkout, the software will send a signal to the credit card reader, typically with data for the receipt paper to print, but also data for opening the register drawer (not all of them, but many have the drawer connect to the card reader) and processing card information if the customer paid with a card. And all of this is shown on the screen for the employee. It's like a dance, a simple one, but a dance nonetheless. A POS isn't complex, at least in theory; a POS is simple to learn and understand.

So I would like to talk about how I would develop a POS.

The UI

The UI is important and needs a ton of attention, but luckily, I think I know a good pick. Electron integrated with a REST API.

• Electron is stupidly simple. All you need is Node.js. Initialize a project through npm, install Electron through the dependencies, and boom, it's ready.
• Electron is a browser ran without any distractions, a browser with the full power of Node.js.
• Electron can handle many tasks and many operations; there's a reason why Discord and Visual Studio Code use it.

Electron is just an all-around good pick. It's modern, pretty fast, and it's easy to make things pretty, especially considering just how much support there is for HTML 5 and CSS programming. And that's another thing, it's easy to learn and find developers for. This is a big thing. No matter what, you need people to help with projects, and thankfully, Electron is in a field that has you covered for that. Many modern-day developers are web developers, so it takes no time to find those willing to join and help with making something like this.

The Software

Now, this part will be long, so bear with me. The software will not be Electron, but rather a server. This server will be developed in Rust to be quick and highly performant. Rust needs to be here for the fastest speed possible, which I will explain later. Electron will handle the pretty colors and buttons, but the server will be the one pulling all the strings. The server will handle the calls to the reader and scanner, it will have information given to it, and even manage the settings to the program. On top of this, I want it to hold a local SQL database to store information tied to the register, something it can quickly call to and set up with and write data that needs to be stored. SQL is efficient in a lot of that, as long as it's used correctly. Now, how will Electron communicate to this server?

This server may use hyper or warp, maybe even something else if I find something better. But I could use it, make routes to specific calls that the server can receive. The server is meant to take in information like JSON, attached with a specific route, and then update its information tied to that thing. For instance, if I wanted to checkout a customer, I could call 127.0.0.1:3000/checkout and secure all the information given by the customer (card info, cash info, product list, price before tax) in a packet sent to the server. The server can then take this information, form the data it needs, and take the appropriate actions for checkout. This is just an idea, but it could work very well if done right, and this is what I've been looking at as of late.

I'm hoping that it will be self-sufficient by the end, run itself with little to no hassle, and the Electron front-end will be like a control panel communicating with it. Doing this will make the program insanely fast, as everything necessary is done with speed because of Rust, while the front-end waits for the code 200 (OK) to be received. Pretty interesting, huh? Keep listening.

Since I have this idea for something simple (at least initially), I was thinking of testing how quick it could be. I want to run it on Raspberry Pie. It uses a microprocessor, can use the internet, and can use Rust. All I need is to see if the speed of the Raspberry Pie can keep up, I don't know if SQL or Electron will prove to be a bottleneck at all, but I'm assuming it won't since they have steadily gotten more and more powerful. I figure I could use it to power the whole POS. But I'm also curious if I can put Arch Linux on it and custom build an OS image for the software itself and make it entirely rotate around the POS, similar to Clover. I'm assuming it's possible since Linux has yet to disappoint me with its endless open-source features!

I have made a little testing server in hyper to see how the server would work. Sadly I can't achieve much without some UI connected to it since what it returns can't be done through a browser, but I'll keep poking it a little to see what I can shake from it; who knows, I might get somewhere with it.