I've worked for a POS company for five years and boy, do I have some stories about the industry! I definitely agree with the OP that the market is littered with terrible products that were knocked together in VB or Delphi, overpriced, and put together with little consideration for actual use cases.
With that said, I don't think that there exists a 'one size fits all' solution. For small and medium retailers without their own IT staff, a service contract makes a lot of sense (consider hardware failure or a corrupted database, or re-training on the system's admin functionality for example). These guys often have a very large inventory and I doubt that a lightweight product (eg Square Register) can manage it elegantly. Unfortunately the needs of these retailers often result in a huge, enterprise-y solution that is both cumbersome and expensive to maintain.
Large retail franchises generally hire firms to tailor a POS product for them, service it, and integrate it into their existing ecosystem (SAP, PeopleSoft etc.).
I think the small retailer market is really interesting and some newcomers like Square Register are shaking things up. Small retailers are often family-owned and really need a product that works out of the box, is easy to configure and use, accepts credit cards, and is very inexpensive. If the POS is designed intelligently then there retailer can probably run the entire thing themselves as long as they don't need special features (think gas stations, loyalty programs, and other markets like hospitality).
I think the OP's project looks awesome and it seems to be targeted at small businesses with low- to medium throughput and where the manager is reasonably technical (see the reviews from the SourceForge page where people dont know how to set it up - these folks probably need a ready-made solution or a consultant). I could also see consultants taking this and extending it to compete with a lot of the existing products out there, which I would be really excited to see!
You've caught on exactly on one of my desires for this project. If you need parts A, B, C and D, then it should matter where you get each of them, they should just all work together. If you're savvy enough to run you're own back-office, I want you to be able to. If not, I want your neighbor to be the person who is running it for you.
As I said in some of my other replies, I want to engender a market of choice. Right now, you can plunk hugeo cash down on an SAP system, you can go with some fly-by-night local operation that has written their own software, or you can go with Square who are just as monolithic as SAP but prettier and cheaper.
Long term, I have my eyes on SAP and other ERP snake-oil salesmen, too. Really, how many different ways can you present basic inventory management and analysis? It's a centuries old problem and it's not rocket science. Companies like SAP and Oracle annoy the shit out of me, too.
Having worked years in high-volume retail and foodservice, as well as having extended POS and designed one, I can tell you it's not nearly as easy as it appears.
Software must react ASAP, keeping the customer waiting at the time of payment is one of the easiest ways to lose sales (and employees will leave if it interrupts tips or the customer relationship).
Hardware must also be rock-solid, for the same reason. Happy paying customers are the foundation of a business and any error or downtime is unacceptable.
That is why the vast majority of retailers accept the high cost of POS as the standard cost of doing business.
There are many, many low-cost and free entrants in this space. They quickly discover it is difficult to compete on features with established players:
* Taxes differ by *city* (on products, alcohol, wholesale/resale, shipping,
handling, and more) -- maintaining a correct tax system is a constant process
* One of the top reasons to use POS is comprehensive analytics that gives great
insight into the effectiveness of sales, employees, and timing (creating such
a product is practically a business of its own)
* Users expect to be able to customize almost any data entry, because to make a
sale and happy customers often requires working 'outside' of the
established system
While I believe there is a place for a web-based POS using a modern software stack, the huge amount of work needs a solid business model to pay for it. If you are stuck on open-source, I would suggest doing like Gitlab, sell the service and hosting and give the source away for free.
>> If you are stuck on open-source, I would suggest doing like Gitlab, sell the service and hosting and give the source away for free.
That's the idea. I fully admit that I don't have all the answers. I'm hoping I can encourage competition in this field. Right now, I think there is a lot of irrational fear around payment processing and inventory tracking (seriously, they aren't that hard, once you know what you're doing. The difficulty comes from making early mistakes that you then have to either fix or live with). That fear keeps the market segmented into a variety of local monopolies.
Square didn't think the local tax issue was that insurmountable to keep them out of the market. There are only just so many ways to slice-and-dice taxes. It's leg work, but it's not difficult work.
I'm going to get a little cynical on your last point. All my years of consulting have taught me that users don't know what they want. Users see themselves as bosses, and like all bosses, they want to justify their existence vis a vis the system. If they don't have input, they don't feel like they have gotten their money's worth.
That's part of the motivation for making it so cheap. You can drive around the corner and open your bag and realize your McDonald's cheeseburger for which you paid a whole $1.00 did not have cheese on it. And you'll still eat it, because a regular burger was only $0.99 and it's more important for you to get down the road than it is to argue about missing cheese for a whole penny.
But if you're paying $15.00 for a burger, it better be the best damn burger you've ever had, exactly the way you want it, even though nutritionally it's no damn better than the slag that McDonald's is shoveling at you.
I don't expect anyone but a true data and accounting geek to understand the best way to work out the data entry for a POS. There will be a lot of people who have opinions on it, but they will mostly have the wrong opinion. I've dealt with this in so many business intelligence situations: the client doesn't know their numbers and certainly doesn't know how to crunch their numbers. They will have opinions, but they will be extremely goofy notions of double-counting and comparing unlike units and dividing by magic numbers.
So by making POS dirt cheap--and democratizing the parts--I am hoping to be able to say "take it or leave it". Here are the good parts, we're not beholden to you for your goofy notions of reports.
The majority of retail sales is low-margin, so I can guarantee you that those businesses watch their numbers like a hawk. They break it down by time, user, product, incentive, and many more. Inventory and scheduling decisions track week by week and often day by day. Anyone using 'magic numbers' or 'goofy notions' will quickly be out of business.
Also, it is the UI that will really sell the product. If a user can enter data 5% faster and make 5% more sales, this is HUGE for a retail business. Furthermore, if the UI is too inflexible and does not allow for enough modification, leading to the business losing or not tracking 5% of sales, this is a huge problem.
I really encourage you to study your use cases in depth. There is already a ton of competition in this space, and building such a product is easily going to take months.
Source: Over the years I have worked with 10+ different POS systems and built one from scratch.
From the interviews that I've conducted with business owners in my neighborhood[1], they mostly have no clue what their businesses are doing in terms of efficiency. They know that the take from the till at the end of the day is more than they are spending every month. Some of them have been in business for a few decades, so they have an intuitive sense that the end-of-day sales should be X or else they suspect their cashier is robbing them, but ultimately they have no real metrics. They dump their POS data on their accountant every month and the accountant serves as a glorified Excel spreadsheet for them to generate a P&L statement. That's the sum total of analysis they do. As long as the tax man stays out of their business and the doors stay open, they don't care.
But also, with the business owner friends that I've had, it can be a really isolating experience. When you're a business owner, you don't have a lot of peers. And you have to deal with a lot of bullshit artists, too. I see a lot of lack of trust. Sometimes, people put trust in expensive systems--a form of passing on responsibility. Sometimes, people are willing to take a chance if the chance is not expensive.
A pub is a pub is a pub. It's about the markup on the drinks and wrangling the bullshit of the drink distributors' promotions. Customers expect Guinness on tap and Guinness distributors expect you to also take Harp from them, but customers don't want to drink Harp[2]. There isn't too much that you can customize in that environment. No, it's not a science, but there really should be a "currently best know configuration" for such a place that opinions to the contrary had better come with some rock solid evidence.
At any rate, I want to build a cash register that Just Works, and let my experience help others make cash registers in their own vision. If someone thinks my cash register works for them, then they can take it. If they want something else, I hope there will be others available for them. I know that there is a type of business owner that would want what I'm making. That's enough of a start.
Thanks for linking me to that post, good to hear about your groundwork!
I would be interested to see what your business model is for incentivizing owners who currently do no (!) tracking. They are inherently cheap and taking a chance on $300-$500 in hardware may not look as attractive as the 'free' existing options that are bundled with payment processing.
I think removing the upfront hardware cost by suggesting whatever touch device the owner has would make for much easier conversions. Sell them better hardware after trust is established. There are definitely foreign Android tablets for $100 which are fast enough for a simple browser POS.
As for pubs, there absolutely is a science, and customization is a part of it. Rotating tap lists, happy hours, specialty drinks... but the tools to simplify and apply the science are mostly atrocious and unknown (just Google "bar cost calculator"). Bars done right have some of the better margins in retail though, so I think they could be worthwhile to target. As you can probably tell, I've thought long of doing this (ever since I redesigned the cost spreadsheet when managing my first bar.)
I wish you the best in your venture! I'm subscribed to see how it turns out.
I'm not that far down the road. I suppose I should be. A lot of what I'm doing right now is about understanding the current market. That obviously terrible software can still exist and survive on its own in this space suggests that there is a fundamental disparity of information between vendor and business owner.
I'm playing with some ideas for, once FOSS POS is an easily implementable thing, what would service providers look like around such an ecosystem. I think half the guys I knew in college had some form of IT consulting business on the side, computer setup, virus cleanup, etc. If FOSS POS could be made easy, maybe such people would have more ways to fund their tuition. What better way to help out small businesses than to make a way for them to easily find other small businesses in their area?
I'm also considering a concept of commodetization of the data platform. With an Open Data attitude, and simple means to export and import data, then it would give a lot of users a lot of leverage against whomever is hosting their database. Maybe they host it on their own some day, too.
Too many of the parts are not interchangeable. You can't easily put a support person into the situation who wasn't responsible for the initial installation. You can't ever leave the database you're on if you want to maintain your data history in a reasonable way. And if you want to add features, you're stuck. Unless you're big enough for your vendor to care about adding it for you, you're not going to get anywhere and you're not going to be able to get anyone else to come along and help you.
There is so much data in these businesses that is going completely untapped. There are so many opportunities for analysis and insight, and they are mostly going overlooked because the system is viewed as a burden. Let's get rid of the burden and then see where we are.
There's also iZettle in some markets where square might not be available yet. I do like the OP's thermal printer though, as receipts can be important for some small businesses.
Yeah, I'm just looking to open the market to choice. That's what FOSS is really about to me, having the ability to make choices for yourself. "Libre, and gratis".
Ultimately, I see the issue to be one of choice. I want to give people the ultimate ala carte experience. Whatever you have on hand, plug it in and I'll tell you the rest you need to get your small retail business running.
Some people don't want to buy an iPad. They already have a 4 year old laptop and that really should be good enough. Or they are ultraconservative and think the iPad is an iPassingFad. IDK, whatever people have for reasons to want choice, I don't really care. More choice is a good thing.
One of my hopes is that, by enumerating the ecosystem and smoothing over how the parts interact with each other, I can blaze a trail for others to follow and offer services for the individual parts. Competition drives prices down.
So that means, you can either run your own server or contract out to someone else. There will be people who care about hosting-their-own solution, and there will be people who don't care. And for the majority of them on either side, the current state of affairs is a murky cloud of poorly understood information.
How is it possible that there can be so many different POS offerings in the world? Each market has its own dominant system, and they are very often a locally developed system. You can't tell me that there are so many valid opinions on how to track inventory and sales that it warrants a different system per city. It's a lack of information that is the problem.
It's also fear. A lot of business owners are very willing to pay big bucks to be able to pass the buck. They can buy a POS system with a service contract and say "it's taken care of". My interviews have indicated that this is the vast majority of cases, that people tend to buy the system with the least amount of friction (and in many cases, "taking the time to learn about 2nd or 3rd options" is significant friction).
PG talks about how bad technology can continue to dominate a market because it's not an interesting enough problem for hackers to overturn. I think a lot of people don't see the POS software itself as that interest, and see the payment issue as too scary, that they aren't throwing their hat into the ring to build this sort of software.
Think about it, what bigger market of customers that you know are more than willing to pay big bucks for a system at the drop of a hat for bog-standard CRUD apps than small businesses in need of POS? Yet why are there so many "social photosharing" startups. There's almost no revenue proposition out of an Instagram-like (Instagram may have a revenue proposition, but being an Instagram knock-off isn't going to get you the same sauce). Yet that's where everyone is at: writing their own JavaScript templating engine to serve up social photosharing.
And I just think it's because social photosharing is very well understood. POS is not because of the auditing and payment issue. And it's not glamorous, though I think it could be if it weren't so scary. So, I'd like to ask Mr. Gorbachev to tear down this wall.
I love the idea and think a raspberry pi with some basic setup could easily solve this although why not something like a Square Register - https://squareup.com/stand
What I would be more interesting in is a system that is a POS or hooks into a POS (square) and connects the offline with online. One way I have seen this done is at Target - via a credit card. If a user pays for something both online and offline with a credit card, a system could figure this out and match up the users past history.
I've interviewed a couple of people who are using Square right now. They are very happy with their systems and I cannot argue with that. Square is doing awesome things; more power to them.
My position is that more choices is a good thing. If Square were good enough for everyone, then the iPhone would be good enough for everyone. But it's not. There is room in the market for choice. I'd like to make choice as simple and painless as possible.
In my original post, I talked about being inspired by Ubuntu and Linux Mint and Arduino and the like. The way they work for grabbing the zeitgeist of people is that they make it very easy to bring people into the FOSS wheelhouse, which opens the doors for them to explore into the vast choice that FOSS provides. You might buy a preconfigured Ubuntu system today, and maybe, just maybe, 6 months down the road you are compiling your own software.
I just can see someone sitting in their newly-opened microbrewpub with an RPi in their hands (it's not that big of a stretch, the same people who are interested in brewing are often interested in a variety of DIY projects) and thinking "what can I do with this?" Let's make that simple for them. Let's make a brewpub distro. Or something.
I also have been making an open source point of sale but haven't touched the hardware end of it yet. I think I am going to take a different approach and integrate my POS with existing payment processing and printing options. Not sure I want to tackle making custom hardware when a stock desktop comes with everything you need. At the bike shop I own we are using my software to track inventory and sales but not to process anything. We use a square device for that and the stock printer to print receipts. This is the cheapest route one could possibly go.
I don't really consider myself as tackling this from the hardware direction. It's more that I'm trying to piece together a set of existing hardware and software that fits the need as best as possible. I'm trying to connect the dots of what already exists.
Some of that is motivated out of laziness. I don't really want to write a POS system from scratch. Not that I can't, I just have too many other projects on my plate to deal with such a thing. So doing a "literature survey" of the existing FOSS POS systems seems like a good place to start.
I fully expect to have to customize it to fit individual need. But that's the beauty of FOSS, you get to do that if you want.
But a good part of it is also motivated from knowing that there is a segment of people who are going to try to build their POS from scratch. They might have a touch screen already and need everything else to go with it. They might have bought a receipt printer on Amazon and didn't really think it much further than that. In the same way that Linux runs on just about anything you can think of, I want to eventually get to where you can fill in the blanks on what you have and get a list of what you need and be able to purchase it easily and have yourself a POS for great justice.
I have a friend who owns a bar and microbrewery just outside of Philadelphia that built his own POS system from completely COTS parts and FOSS software. It took him 3 years to get it to the point that it worked, but it eventually worked. I'm trying to make that 3 years turn-key for everyone else.
I'm still looking into payments. Payments are kind of the big, scary elephant in the room for this field. I'm betting it's actually not that big of a deal. It's probably just the classic problem of getting through the slog. I've worked on enough SOX-compliant systems to know that such things aren't really that complex, you just have to know the rules ahead of time.
Anyway, I'd be really interested to see what you're doing. Please, share what you've got so far.
Your perspective on this issue is an asset to me. I also have been tinkering with different approaches for about three years. I started out hacking on Virtuemart for Joomla, then tried Spree for Rails but I have found that they are too biased towards the online store checkout flow.
My most recent attempt has been built with Active Admin and Rails. I built it in a couple of months so we could have something for the bicycle shop I opened recently. I admit it's quick and dirty but it tracks work orders, sales, inventory and customers. I have not addressed payments beyond a select field for credit card, cash, check, etc. but I have considered integrating with an online processor. Currently we use a Square like reader from our bank and the stock printer for the store desktop. We don't have a touch screen but we do use tablets on the floor for work orders and sales occasionally. Since the printer is on the network, we can print receipts from any of the devices the sale is being made from.
I have published everything to my Github account (https://github.com/websitescenes/point_of_sale). Much of it is hard coded for my specific shop but I plan on making a general version that would be more configurable.
I am interested in following your progress because you seem to be attacking some of the angles that I am ignoring. Thanks for your response.
Cool beans. I'll definitely include it in my review. I'm getting about a day's worth of work on the project done a week, and I'm looking into an intern to take up some slack on my other projects to be able to put more time into this one.
Any interest in applying to Ycombinator together? I have applied numerous times by myself and haven't gotten much of a response. I can't find anyone locally to run with on a startup. Not sure if we are compatible based on our limited communication but wanted to throw the idea out there anyway. I am a mid level engineer that has been programming for about two years. I am learning fast and always improving my skill set. You seem to be more advanced than myself but perhaps there is still a way you could utilize me.
I live in the DC area and don't have much interest in moving to the Valley, which is a YC requirement. But I'd definitely be into collaborating with people. I post frequently on Tumblr, so you'll be able to see updates when they happen. You can also follow my Github profile and you'll eventually see something there (https://github.com/capnmidnight/). Finally, you'll find my email address in my profile.
I wish there was a good open-source POS 6 months ago! But I didn't find any that fit my startup's needs. I think it's awesome that you're doing this as it'll help retailers a lot. We can exchange notes. A basic POS is the type of thing
that should have been solved already so we can move onto newer and better things.
I'm one of the co-founders of AvidTap (http://avidtap.com). We're a mobile retail company providing additional value by bringing the latest mobile technology to help retailers engage customers and enable a better way to shop. Think mobile wallet using NFC and Bluetooth LE (iBeacon), mobile loyalty, personalized experience, etc. We want all of our partner stores to be able to say hi to their customers by name, remember what their regular orders are, and just generally make it a more personal shopping experience.
In the beginning we looked around for an open-source POS since we believe we'll be adding value on top of it, but unfortunately all the existing ones don't fit our needs or can't enable our target pricing. We ended up building one.
You're spot on in terms of the pricing. When we looked at the market, we talked to people that are still using the old fashion cash registers bought at Costco between $100 to $300. Then at the other end of the spectrum there's the really expensive POS system costing $10K per station just to start. Or nowadays you can go with Square Register and get dinged a lot more per transaction than the rate an established shop would be able to get. We've been able to convert people using all of these systems to our system.
My company's solution (http://avidregister.com) is a complete POS package that sells for $425 for the hardware. We also let our customers buy the hardware themselves if they want. After that it's $15/month subscription fee to help us add features, for support, and for the additional mobile features we provide. Some people really need the tech support and hand-holding. If you're interested, AvidRegister is downloadable on Android Play Store and has a demo mode. Note that it's only optimized for certain screen sizes. The good thing about it is that it'll still work if the Internet goes down. It was one of our requirements.
We worked hard to get our pricing to basically the cost of an old fashion cash register so that everyone can have a modern system. That way AvidTap can then bring everyone to the mobile retail age like what Starbucks is doing already.
We're using well known brands for receipt printer and cash drawer. If we use cheap no-name ones, then our hardware cost can go even lower. We also looked at potentially using Raspberry Pi but we had supply issues with that, on top of
having to find touch screen that's within our price range. We ended up developing our own POS system to run on Android tablets. It's a really nice system IMO. Android tablets can go below sub-$100 now btw.
Let's get everyone a modern system so all retailers can move onto better things. I'm happy to exchange notes should you wish to look into Android tablets too.
With that said, I don't think that there exists a 'one size fits all' solution. For small and medium retailers without their own IT staff, a service contract makes a lot of sense (consider hardware failure or a corrupted database, or re-training on the system's admin functionality for example). These guys often have a very large inventory and I doubt that a lightweight product (eg Square Register) can manage it elegantly. Unfortunately the needs of these retailers often result in a huge, enterprise-y solution that is both cumbersome and expensive to maintain.
Large retail franchises generally hire firms to tailor a POS product for them, service it, and integrate it into their existing ecosystem (SAP, PeopleSoft etc.).
I think the small retailer market is really interesting and some newcomers like Square Register are shaking things up. Small retailers are often family-owned and really need a product that works out of the box, is easy to configure and use, accepts credit cards, and is very inexpensive. If the POS is designed intelligently then there retailer can probably run the entire thing themselves as long as they don't need special features (think gas stations, loyalty programs, and other markets like hospitality).
I think the OP's project looks awesome and it seems to be targeted at small businesses with low- to medium throughput and where the manager is reasonably technical (see the reviews from the SourceForge page where people dont know how to set it up - these folks probably need a ready-made solution or a consultant). I could also see consultants taking this and extending it to compete with a lot of the existing products out there, which I would be really excited to see!