Monday, September 2, 2013

Meteor Is Not Just A Toy

Toward the end of 2011, I kicked off the R& D phase for a new project called EtherPOS.  EtherPOS is a cloud based retail point of sale system for multi-store organizations.  At the time, one of my other companies, Atomic Tattoos, was struggling and burdened by the inefficiencies of three different retail point of sale systems.  At my wits end, I decided it was time to create a retail point of sale system that acts and thinks like a retailer does.  My decision involved selecting Meteor as the framework of choice!

Why three different point of sale systems?

We were on a never ending search for a retail point of sale system that actually improves our business processes, provides business automation and saves us money.  Instead, we encountered retail point of sale systems that created more back-office work, increased our business processes, some can't even balance the cash drawer, most have no concept of fraud and risk management and all of them actually increased our operational costs.

I believe that a retail point of sale system should reduce back-office work, business processes and costs while lowering normal retail issues like fraud and risk management, cash breakage, inventory shrinkage and it should streamline and automate business processes.  A retail point of sale system should not require a significant introduction of business processes so much so that it increases operational costs.

I have built a wide range of websites and applications with everything ranging from perl and C in cgi through Cold Fusion,, .NET, Java and J2EE, PHP Lamp stacks, etc...

I never had the luxury of building something in Ruby or Node.js but with all the buzz online about both of them I started tinkering with them.  All the while, I was seeing a lot of chatter about Node.js.  I noticed a lot of excitement around socksjs and and projects like Socket Stream, Derby and Mojito.

A point of sale system, regardless if it is a desktop application, website or a web app, really needs to have real-time or at least near real-time data transfer.  Strangely, most retail point of sale systems rely on non-real-time data transfer such as file transfer and refresh or proprietary network data transfer protocols.  Most of these methods require some kind of manual action or scheduling of events to trigger the data transfer.

For example, one of the biggest and by far in my opinion worst, retail point of sale systems is Intuit's Quickbooks Point of Sale.  It relies on manual file transfer or their own proprietary network file transfer to update data from headquarters to remote stores.  We used this product at some of our busiest Mall based stores and it was the worst software and retail point of software experience of my life.  Not only were we unable to update prices, employee information and other data in real-time, this Piece of Shit (pun intended on the POS) doesn't even properly balance a cash drawer when you Z-out (close the drawer).

Ultimately, I knew that EtherPOS needed to be as close to real-time as possible.  Not just real-time for price changes, employee updates, inventory counts but also for sales data like invoices, invoice items, payments, discounts and reporting.  EtherPOS needed both the features and the real-time retail horsepower that the big retailers have but at a fraction of the cost for development and production so that it would be affordable to smaller chains.

Atomic Tattoos is currently a 17 store, 3 city, 2 state retail chain.  So, the retail point of sale system business requirements are similar to those of a large multi-store retailer.  We not only deliver personal services such as tattoos and body piercings but we stock hundreds of retail products such as body jewelry and the latest hip tattoo lifestyle fashion products.  In order to be competitive we have to have the tools and business intelligence to survive and flourish and it all starts at the point of sale.

Around January 2012 I was starting to lean toward using Node.js for EtherPOS because the ability to add real-time data transfer was appealing to me and because I was really sick of writing an application in 3 different languages (css, html and javascript on the front end and then a server side language like php, ruby, cf on the back end and then tsql on top of it all.).  I really wanted to leverage the power of a single language stack or as close to it as I could get.

Then the HN article about Meteor hit.  I watched the videos.  I could not believe what I was seeing.  The demos were inspiring, especially in comparison to the other real-time stacks.  It just so happened that I was in SF for the Future of Money & Technology Summit III and the buzz among some of the techie attendees I met was Meteor and of course Node this and Node that.  I knew there was something to this Meteor thing, I just didn't know how much at that time.

After my return back to FL, I started playing around with Meteor and Node.js apps in general.  Meteor had the features and I felt like the team had the vision necessary to provide a framework for building more than just websites and simple little web apps.  I felt like they had the vision to provide a framework sufficient to build cloud based applications that businesses could rely on for their day to day mission critical operations.

Toward the end of July, the Meteor team announced their funding which sealed the deal for me.  I would hang my hat and the future of EtherPOS and potentially the future of Atomic Tattoos on Meteor.

On April 11, 2012 Timo Zimmermann wrote a blog titled Meteor Is Just A Toy.  I remember reading that article and reading all the other player-hater posts on HN and other sites about how Meteor couldn't be taken seriously yet.  The future is always a bit scary but that is what makes the adventure that much more exciting.

I remembered 1995, when I started building applications in Allaire's Database Markup Language running under O'Reilly web server instead of using perl or C in cgi.  At that time, there were lots of supposed "toys" on the market, one of which was the Allaire brother's Database Markup Language.  I bet my future at that time on something unproven but it possessed a vision of the future of what web applications could become.  I could have kept writing stuff in perl or c in cgi.

Everyone knows the story, the Allaire brothers built a successful company called Cold Fusion, went public and were acquired by Macromedia which was later acquired by Adobe.  I built a handful of companies on top of the Cold Fusion framework, one of which I also took public through a reverse merger.  They had what I believe the Meteor team has, which is a vision of the future of application development and not just another "me too" strategy.

So, based on the features, the funding and the Meteor vision it was a "no brainer" to hang my hat on Meteor and select that as the platform for EtherPOS.  I dug in deep around mid August 2012 and didn't surface until sometime around late March 2013 with the finished product: EtherPOS a cloud based real-time retail point of sale system built entirely on Meteor.

Starting on April 1st, 2013, about one year from first finding out about Meteor, we started migrating the 17 stores of Atomic Tattoos and were finished by June.  Atomic Tattoos now depends on EtherPOS and subsequently Meteor for 90% of the mission critical business services.  These mission critical business services include purchase ordering, transfer orders between locations, inventory count and reconciliation, real-time inventory management, tax processing and management, timeclock and payroll processing and management, sales commission management, sales reporting and of course retail point of sale cash register and drawer open and close auto-reconciliation and balancing.

Ultimately, if Atomic Tattoos cannot sell things to customers and accept payments and pay employees and contractors in an accurate and timely manner then it goes out of business.  So far, we have been able to successfully do all of those things while realizing a significant return on investment.  So much so, that I believe the future bodes well for launching EtherPOS as a commercial SAAS product offering for other retailers.  A future blog post will cover the subject of the return on investment, cost benefit analysis and overall productivity gains achieved.

If you are building toys and use a hammer that does not make the hammer a toy.  Alternatively, you cannot be expected to be able to build anything serious with a toy hammer.  Therefore, if Meteor were a toy you would not be able to build anything serious with it.  Yet, I did just that.  I built a mission critical business application in Meteor.  You really can't get any more non-toy like when you are building retail or commerce applications.  Unless of course you are building mission critical financial services or healthcare applications.

Now, if  you are building basic websites or something that has fairly static or unchanging content or doesn't require much user interactivity then Meteor might not be the right tool for the job.  Hell, plain old HTML would probably suffice for the vast majority of the web, yet developers still use stacks and frameworks.

If you are building applications, especially cloud based applications or any application that needs real-time features and a high degree of re-activity or interactivity, then you cannot ignore Meteor because it is a good representation of the future of application development.  As well, the resulting product development capabilities match the expectation of the end user.  Social networks like Facebook, Instagramm and Twitter along with mobile apps, the mobile web and  web apps in general have conditioned the end user to expect a much more rich and interactive experience that is more akin to the behavior of desktop applications.

Look at it this way, if your account reps or customer service agents have to tell your end user to "refresh the page" then you have a serious design problem and are living in the 90's.

So, Meteor is not just a toy any more than a hammer is just a toy.

No comments:

Post a Comment