Show HN: Open-Source Rails Point of Sale

You're also right about performance. Loading unnecessary stuff on a page is just going to slow everything down.

It's a great idea and also being a relatively new starter myself I can relate. Hopefully you can take all the feedback everyone is giving and make your project better!

It is difficult if you are coming from a web development standpoint. I started programming with PHP and moved to Ruby recently and I am not familiar with Java or the like. For someone that is familiar with those technologies I am sure it is a snap but honestly I have zero interest in learning Java or anything similar. I want to use the things I am familiar with. And yes, documentation is almost always horrible because POS companies almost always want you to pay them to integrate or extend the system.

I have a iOS app that integrate with several ERPs/POS (http://elmalabarista.com/bestseller) that is used in my country.

In first place, API???? What the hell is that? No kid, POS/ERPs don't know what a true API is. Is direct access to the DB, plan text files, and a lot of hyper-pain talking directly to the developers of that systems. And good look doing data archeology of all of that.

Because this I'm also building a POS for the iOS (in late stage, but is hard to do this solo). One of the innovations it have? The customer table is called: drum-drum-drum "Customer". Seriously, after dozens of integrations mine is the only one that the tables have names that make sense. And the fields. And the data type of that fields (cough a database have a datetime field? cough).

POS companies will often charge you a large sum of money in order to work with their systems. I think we paid Micros $10k to be able to integrate with their junk, and we had to fly to Maryland and sit in their offices for 2 days while they ran around being useless.

Workflows can be vastly different. If you're trying to write an IPOS interface that abstracts all that pain away for the client that's interacting w/ the system, it can lead to weird situations. Some POS systems will let you open a check w/ nothing on it (Aloha) but some won't (Micros). And on Aloha, if a server logs in and looks at that empty check before you put something on it, it'll automatically close. There are a ton of edge cases that you have to test, and the way two POS systems work in similar conditions are never the same.

Getting menu data out of a POS is a nightmare, as there's usually a ton of unused junk that you don't need. Often there are many duplicates, so the Onion topping you add to a taco is different from the Onion topping you add to nachos, and both are different from the Onion topping you'd put on a burrito. Despite the fact that it's literally the same onion being used. Sometimes, menu items that are on sale for happy hour or something aren't different items, but they get modified with "happy hour". You don't want your users seeing that junk, so you have to do a bunch of magic behind the scenes to submit the normal item AND the happy hour mod when the user orders it.

I could go on, there's a LOT of this weirdness when working with POS systems and most of the time you don't know what it'll be until you've sat there banging your head against your desk because when you order a Sandwich + fries it works, but a Sandwich + garlic fries will only add the fries to the cart. Feels good when you're finally done with the integration, but it's hell getting there.

Oh, and a lot of the time there is no real API, you're changing database files or doing some sort of dark voodoo magic to get the thing to work. Sometimes you get lucky and there's a SOAP service or some COM calls you can make that'll play nice with the POS, but that's hardly ever the case.

The industry is definitely moving in that direction, but POS companies are behemoths that haven't had to innovate in the past 20 years, so it'll be slow and painful.