The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Which web framework for a complex Point Of Sale app?

I have a client who needs a very specific, rich and complex Point Of Sale application for his business with a few hundred stores. He's thinks he may be able to sell the app to others as well, but it's not his first priority. He's leaning towards a Windows application that talks to a central server. Comparing a standard .NET web app with Ajax and a standard .NET Windows app, I think a Windows app would be quicker and simpler to develop and have better performance.

I'd think that Ruby on Rails might be too simplistic for this project. Any recommendations on web + Ajax frameworks that would be good for such a project?
naveed Send private email
Thursday, October 23, 2008
Point of Sale apps need to talk to peripherals (barcode scanners, receipt printers, payment terminals, ...) which is going to be much easier with a rich client.
Thursday, October 23, 2008
Definately use a windows forms app for the POS client. Webservices to talk to central db.
Thursday, October 23, 2008
you might want to have a local storage too, like a sql server compact, so that if the internet goes down, you don't loose sales. transactions can get sync'd up later
Thursday, October 23, 2008
Agreed with the above... if it's a POS package, you're going to need access to libraries to read the serial/usb port for the scanner, a special printer for receipts, and potentially a credit card swiper.  Usually the swiper will just act as a quick input for #'s, but not always.  You'll need something running on the local machine, not something web-based... but make sure it can interact with a central database for inventory, reporting, etc.
KC Send private email
Thursday, October 23, 2008
I would do some investigation into how POS applications are usually architected. As someone else mentioned they often run the POS terminals as stand alone applications that then sync with the server. This way if there is trouble with networks or servers they can still make sales!
Craig Send private email
Thursday, October 23, 2008
"Definately use a windows forms app for the POS client. Webservices to talk to central db."

+1 for this.

Try and keep the web services calls fairly straightforward and not too chatty. Make sure the app can handle comms problems.

Make sure you write stubs for your web services and mock client code.
Friday, October 24, 2008
I currently work on a browser based POS app. We talk to the peripherals from a browser. But it is a royal pain in the butt. We have to install a bunch of peripheral drivers on the client anyway for the devices so you lose the whole "thin client" benefit. With that said, I would recommend just going with a .NET Windows Forms based app. Your device interfacing will be much easier since you can use "POS for .NET" to interface with the devices.

By the way, how did you find this client? It seems like every couple of months someone with no POS experience comes out here asking about writing a POS system for some good sized retailer. Yet those of us who have years of experience can't find such clients. I'm just curious about what I'm doing wrong. My assumption is that I'm simply not looking hard enough (or at all).
Friday, October 24, 2008
I wasn't looking for a client, he's a friend.

Everyone, thanks for the great feedback!
naveed Send private email
Friday, October 24, 2008
I am, quite frankly, astonished that anyone would even contemplate building a point-of-sale system as a browser-based product.

It just seems like completely the wrong technology for the job, sort of like trying to build a road bridge from corrugated cardboard.

Given that you'll probably need to interface with laser scanners, cash drawers, credit-card PIN keypads, receipt printers etc, you want something that can talk easily to the hardware. And also with some level of persistent data storage on the machine or local network.

The last time I worked on something like this, it was a tiered solution - each shop had a network of terminals connected to a local database server. The per-shop database server uploaded transaction data to the central office, and downloaded price updates, special offer codes etc.

If the comms go down (and they will, eventually) then you don't want all transactions in all shops to just stop.
Not-really-a-POS-guy Send private email
Friday, October 24, 2008
"If the comms go down (and they will, eventually)"

Absolutely - make sure you test for this scenario. It will happen.

However, one thing we've found that works very well in branch offices is a router than will fail over to 3G if cabled networks go offline. If you have a 3G provider who charges by usage this can actually be a pretty decent way of providing low cost back up connectivity.

Saturday, October 25, 2008
What happened to "there are no dumb questions"? :)
naveed Send private email
Saturday, October 25, 2008
"There are no dumb questions" is a myth. There are plenty of dumb questions in the world. But you haven't asked a dumb question so don't worry.
Saturday, October 25, 2008
Hi all,

I've been a reader of the JoS blog, and the message boards for about a year now, ever since I picked up the "Micro-ISV from vision to reality" written by Bob Walsh (another reader, I believe).

I do a lot of consulting for a point-of-sale reseller in the Pennsylvania market, and am involved in customizing the system for clients.  To give you an idea, we have automated order entry for web-systems, we are in the process of building a Tavern and Delivery module for PA State beer stores, and we have a few more Add-ins that are slated to be started early Dec.

What I'm getting at is this.  I know what the hell is going on with point-of-sale, and I still have to refer back to the company that wrote the software before I can even customize it... doing just customizations is a nightmare, and can take somewhere between 4 weeks for simple stuff to two years for more complex pieces.  the retail package that we deal with is Microsoft Dynamics Point of Sale (formerly Dynamics RMS, formerly QuickSell).

Microsoft has spent 2-3 years working on getting the next release out the door, which it hasn't made it yet.  Without actually counting, I would have to estimate they have 20-50 people on the project.  Now, if that's the case, why is it every couple of months a consultant type comes on here and starts asking "How do I develop uber complex Point of Sale application for my friend.  I told him I could do it and that we could do it 'x' or 'y' way".

For all those guys, please forgive me, but look into a standard package that is currently in the market, and see if it can't be customized to meet the needs of your friend.  you are just wasting your time.

As I said, this isn't meant to put the OP down, but I think there are certain problem domains that have so many packages out there that us as ISV's should be looking into and seeing how to customize it to meet the verticals, so that we can better service the client.  the Point of Sale market is definately one of them.

I hope this sticks in the archives.  ANYONE looking into building a point of sale system from scratch, please, email me and let me see if Dynamics Point of Sale would work with a few customizations before you go down the road of dealing with taxation, inventory tracking, reporting, etc.  it's a horrid headache that has been solved many times already.

Thank you.


OP: I did drop you an email.  Please do contact me and let's see before you start going down the road of dealing with 5,000 headaches if you can't get your friend up and running multi-location with a HQ system easier.  I'd be more than happy to help in any way that I can.
Richard B. Send private email
Monday, October 27, 2008
Richard. Good advice but I'm sure it will fall on deaf ears. The only reason why most of the POS software vendors in the world (like me) are in business is because retailers don't believe they can use an off-the-shelf product. I've seen so many retailers that are convinced that what they do is so special that no one else or any canned product could possibly handle it. That's good and bad news. The bad news is that it opens the door for thousands of little POS shops with mediocre products. The good news is that little shops can actually make a product and sell it. Sustainability is an entirely different matter.

As for Microsoft POS, I can't say that I would recommend it to a 100 store chain. It has its own issues. The fact that MS has been struggling to get the next release out should tell you a thing or two about the product. It is fine for smaller retailers with around 10 stores. But after that it gets very unweildy. I'm not saying that it is a bad product. Just that POS systems come in a variety of flavors and what works for a 10 store chain might not work well for a 1000 store chain.

I think another issue here is that the OP's retailer has the idea of "writing a POS system and selling it to other retailers". I've seen this plenty of times before as well. Retailers should never attempt to write a POS system to be sold to others. That's not their business. It costs literally millions of dollars to write an enterprise class POS system (due to all of the issues you've specified). Retailers should not be spending that kind of money on something that is not their core business. I don't know why they become enamored by the idea of having a secondary revenue stream through selling software. Maybe they think it is easy money. But it clearly is not. Thousands of POS systems get started every year. Very few actually get finished and of those that do, very few are really marketable as enterprise systems.

To the OP, I agree with Richard. Try to steer him toward an available product. Writing a GOOD POS system is really hard and takes a lot of time. If you don't have any experience in this area then you are in for a rude awakening. The only way you could successfully write something that he could actually use is if his requirements are minimal. And if this is the case then he could easily use an off-the-shelf product.
dood mcdoogle
Monday, October 27, 2008
Pos for .net

Tuesday, October 28, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz