Ask HN: Do you think there's room for a Point of Sales webapp?

9 points by davidjairala ↗ HN
I've been working the past couple of months on a Point of Sales webapp, and it's getting to the point where it's almost good to go, however, I'm beginning to wonder about the actual business potential for it.

I've been looking online for possible competing business or other webapps that do similar things, but so far I've been unable to find anything really up the same alley.

So what do you guys think? Could this be a good lifestyle business if executed correctly? Have you noticed a need for this on your field?

Thanks!

27 comments

[ 3.8 ms ] story [ 59.3 ms ] thread
You need to make sure you have near 100% uptime. If someone is using this as a PoS and it's down, they will lose money. You may also need to get some sort of insurance.
Thanks, will definitely be looking into various forms of reliability and maybe have some mirror servers just to provide 100% uptime.
Having researched potential PoS systems for a local shop I can say there is a lot of room for improving the PoS products but I'm far from convinced it's actually lucrative to provide such solutions.

As rick888 is pointing out you will definitely need a solution that is forgiving towards system threats. The system needs to be functional in all sorts of conditions.

I was looking at a suscription model, kind of like what the 37 signals guys do, but with more affordable pricing. I was thinking something like $20-$30 a month for the basic package.

Thank you for your pointer about functionality and system threats, I hadn't really thought about that and will be looking into it very thoroughly.

Why the downvotes? Too pricey?
Not sure why someone down-voted that... But it doesn't sound too pricey as long as it does what it needs to do and it does it well. 20-30 dollars is probably what most store owners pay just for being able to accept credit cards. In my country the credit card terminal alone costs the same as a mid-end desktop computer and you still pay for the service to be able to accept credit cards and in some cases fees for the processing.
In my case suscription models with somewhat absolute pricing were attractive because it provides a way to even out the money cost over time.

But the price was not the only thing in consideration when it came to costs. The concerns my client had with suscription model was if the provider would still exist and provide same service in a year, or in five years for that matter. The amount of time they had to invest for the PoS (which was with inventory management) needed to be secured. They were okay with phasing in the inventory over a long period (it was a specialty store with a huge inventory) given the system didn't rely on being functional if only it knew the inventory - as long as the time investment couldn't be lost. Should the PoS provider go bankrupt or otherwise stop the service they wanted to be sure their effort time-wise wasn't worthless and could be ported somewhere else. Contracts with a minimum binding periods was okay as long as it didn't mean the time they used the system couldn't benefit them elsewhere.

Someone pointed out that the robustness wasn't a deal-breaker because you could revert to handwriting receipts. It's true that you can just do that but the point about PoS isn't just that it's slightly more effective than a calculator that can print out receipts for customers. A PoS grants valuable data. Even older cash-registers have data capabilities such as who the salesperson was and time of purchase. If you can provide great analytic tools for the data it has gathered, that'll be a major improvement of many available PoS systems.

But store owners also care about stability very much. If the system doesn't work when there's internet shortage they won't be happy. No electricity is probably only acceptable factor when it comes to having a PoS on a computer. If the system is slow and customers are waiting because there's unstable internet they will also be dissatisfied. Debit card processing all goes over the internet and when it's slow customers have bad experiences but at least they know it's because the internet is messing up and some ISP probably is to blame. If the cash-register is screwing it up they will blame the store.

I've worked in a store for a couple of years as a sales person so if you have more questions I'd be happy to help. I'm available through email: pierre@snowboardforbundet.com.

Hi Pierre, thanks a lot for your comment, you raise some very valid concerns about the application that I will have to take into consideration, and will definitely hit you up via email in the next couple of days.

I guess I should start considering some options so the shops can have an offline app, or some sort of offline synchronization options at least.

I think the two prior comments about having a robust system with 100% uptime are on the money. It definitely can't be laggy, either.

I'd suggest the following reality check. Set up a "head to head" test vs. a cash register. Give someone basic training, and have them run through a list of transactions. Is your app as snappy and responsive as the hardware of the cash register? How does it compare to the cost of a cash register? I'd suggest doing this competitive analysis of the cost and performance before going any further.

The head to head test vs. a cash register is a fantastic idea, thank you! Basically, from what I've seen thus far, cost-wise I'd like the webapp to be the affordable solution, 'cause most of these POS setups can get really pricey from the get go.

Speed is pretty snappy right now, but this can vary once it's running with a couple of actual clients on, so I'll have to look into it a bit more carefully, start caching whatever's possible to, and so forth, so thank you for that suggestion as well.

I'd be happy to look into trying it out for a retail store of general merchandise, like a local grocery store.

The only issue is some kind of guaranteed connectivity on one hand or just good uptime and is it a real time database or is it using push changes from the client?

Would need 2.

Thanks ottoid, I'll let you know via private message or email as soon as I have a beta setup online, which should be coming in a couple of weeks tops so you can give it a go. It would be tremendously helpful to have someone actually try it out with real data.

The database is real time, and I'm definitely beginning to look into some sort of setup that would allow me to offer near 100% uptime.

David, Good news is I won't be needing a PCI compliant system because I use a separate credit card machine. So let me know if you want to get started sooner.

you can email me @ lrmyotherid followed by the @sign followed by gmail.com - i get enough spam already!

Sure thing ottoid, I'll let you know as soon as we get a beta online which soon be really soon, thank you!
I think multi-site stores would be a good target for this kind of app. Removing the need for networking/synchronisation across multiple sites can be handy. Especially if you show stock levels that let them easily look up accurate numbers at other stores.

I am not convinced 100% uptime is a showstopper, shops can revert to a paper receipt book temporarily if needed. Internet outages are inevitable, even if your server is still up.

Hi redguava, thank you for your input.

As you mention the app currently does allow you to run a multi-site setup, as well as a multi-company setup for those lucky people running more than one company.

Seeing the concern for 100% uptime I will be looking into offering as high uptime as possible, maybe adding some EC2 instances ontop of my Linode servers or something of the sort.

Thanks again!

Take a look at Vend: http://www.vendhq.com/

They are a cloud-hosted, browser-based POS system with full offline service. And they've just announced series B funding so others also believe there is a market there.

Thanks julian, definitely hitting up many of the same areas as my idea, but hopefully there's room for another option in the market. As they say, always nice when someone else validates the idea.
OP, care to share an email? I have been floating this idea around for a long time, and have a ton of experience programming/installing PoS systems etc.
Sure! davidjairala@gmail.com

Thanks for taking the time!

I hate to break this to you, but for any larger merchant, you're going to be SOL, for one basic reason: PCI compliance. Unless you spend a ridiculous amount of time and money researching and implementing things like key management, credit card tokenization, and the like, no level 1 or level 2 merchant will look at you.

For level 3 and level 4 merchants, you may have a shot-- especially if you can seamlessly upgrade the application to add more functionality, allow for customization, etc. Basically a Shopify for the real world.

Hi mark, thank you for your comment. The product is definitely more geared to smaller shops, level 3 and 4 as you said. However, I'm beginning to think that maybe looking into PCI compliance wouldn't be a bad idea.

Thanks again.

Not sure of the market you are targeting. It has been my past experience developing and selling stock/sales system in India that it's very hard to break in with a browser based remote model (vs. FoxPro, curses) based interaction model. The main reason being adoption. Some of these adoption issues are.

- Hot keys

- Popups (like FoxPro) and selections.

- Local vs remote (availability) vs sync later. Syncing has to be automatic with extremely good fail over mechanism.

- Install once and forget about it. What I mean here is that retailers (at POS) are not thirsty for new features/functions.

- Forgiving.

My2Cents worth.

Hi Yesh, thank you for your comment, it raises some very good points and concerns I've been having lately.

The target market is pretty much small to medium retailers who are looking for an affordable POS solution.

I love the idea of having hot keys on the webapp though, it would really make the whole processing faster.

(comment deleted)
Thanks for the great list vrikhter, this gives me a much more in depth analysis of the possible competition.