A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Have 6 years exp. in Point-Of-Sale(POS) systems. All of those developed in various Langs&DBs includes C, Delphi, Btrieve and Borland Interbase.
I am thinking of developing a Point-Of-Sale(POS) system with added features and user-friendly interface as a part-time project. Hope that it may grow into a commercial product one day. Don't mind investing on tools I needed to move this project ahead.
- Platforms: Windows, may be Linux (in future)
- Need strong Reporting in depth
- Client/Server model
- It should be cost-effective for the end-user
Would appreciate any suggestions on what are the best language, DB and report module combinations(Pls keep in my mind that it should be cost-effective to end-user eg.: Cost to end-user buying SQL Server licence and etc.).
If you need code obfuscation and compilation to machine code, you better say it before any suggestions appear. :-) I really don't know about these requirements in POS techs.
Sunday, April 03, 2005
Are you sure you want to enter this area? It seems POS/Retail Management and e-Commerce is merging and there are just trillions of off the shelf shareware to solve any problem. Seems it's better to become familiar with a framework like Microsoft Solomon and build a consultancy around it. The little guys are getting their $30 fix from Tucows anyway, the profit margin would be too razer thin to feed your side business.
"Are you sure you want to enter this area? It seems POS/Retail Management and e-Commerce is merging and there are just trillions of off the shelf shareware to solve any problem. "
There is a big difference between shareware apps and real enterprise quality applications. The eCommerce side does seem to be covered but the POS side is still viable. The "off the shelf" POS systems really aren't geared toward retailers who have more than a couple of stores.
Anyway, for POS you want to be able to integrate easily with OPOS or JavaPOS for device support. This means that you want to go with Java or a language that can handle ActiveX (like VB or .NET). If you are interested in Linux support then Java may be the best option.
As a side note, IBM seems to be putting their money on the SuSE Linux for Retailers version.
Sunday, April 03, 2005
The ones which most easily enable you to fully* solve your problem.
* For varying values of "fully"
Monday, April 04, 2005
They may not have made it in-house. You'd probably be surprised at the poor quality offered by some of the high end solutions today. This is why I believe that there is still some money to be made in POS. At least I hope there still is... I'm banking on it. ;) You don't need to sell a CompUSA to bring in 6 figures per deal. There are still plenty of smaller chains (30-100 stores) out there using DOS or early Windows systems. Anything less than 5 stores is currently being serviced by package products and resellers. You may not make billions but you might be able to retire early.
Monday, April 04, 2005
Hi Matt: am totally agree with you. There is a still chance of making money in POS. Most of the custom packages are either targetted small or expensive. Every country differs in features for retail & hospitality systems. That is why can't make generic POS system. i would like to contact you personally. Pls provide mailid.
I think the biggest profit to be made, should you enter this niche, will still end up being support for the particular customers who DEPEND on your software. So if you can provide a complete service of POS and differentiate yourself well enough, I think some margin should exist. All I know is that it's a hard ditch to crawl out of though, you are betting your development on building a highly specialized derivative (POS for sayyyy... a model airplane company) of a general tool (POS), chances are the business man in you will want to venture out into related fields--and then 5 out of 7 teams will destroy themselves by either over-generalizing their code base (never getting it out) or over-specializing their code base (never able to make it scale on a profitable level). I hope you guys will find the right balance. G'luck :-)
To answer your question:
I worked for a company that developed POS and they used the following MIX of technologies:
PostgreSQL (www.postgresql.org) Database
Apache & Tomcat for Web front-end (optional)
Client POS Interface:
Written in C++ Builder (C++ Code)
ZEOS VCL Library to connect to PostgreSQL
Tuesday, April 26, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz