Method Community

 

Blog

The future of web apps: end-user web platforms

Since the launch of Method, I'm asked more and more for my thoughts on what the future holds for small business software.   You might be surprised that I respond that the future of small business software isn't software at allThe future is customizable web apps, built on end-user web platforms.
 
During the last 10 years, I have had the pleasure of working with thousands of companies, learning about their needs, as well as the software they depend on. 
 
When it comes to my thoughts on which business technology will push to the forefront in the years to come, my nod goes to developers that can truly (I mean truly) satisfy the demands of small business. Sound like a cliché?  Of course it is. Especially when you look at what small businesses actually want.
 
So, what does every small business want?  Across the board it's actually the same.  They want something simple their staff can use.  But they don't want to sacrifice on the features they need.  Oh, and did I forget?  It's got to be very affordable and it's got to be today!  In other words they want to have their cake and eat it too…..and it should be no more than 0 calories, and it can't cause a tummy ache.
 
Wait, wait!  Don't despair software developers…...there is hope! Those of us who have started to get their hands dirty with end-user web platforms can report back: "We've seen the future, and the future is friendly."
 
Let's do a short history lesson.
 
Desktop Software Programs
The 1980's and 1990's saw desktop software jump on the scene.  The model was simple: find a core problem for similar companies in an industry, and sell as many one-size-fits-all products as possible.  For small businesses, it was certainly a lot cheaper and painless than getting a custom program made. But with desktop programs the famous Henry Ford quote comes to mind when selling his Model T car: "Pick any color - so long as it's black".  Contrary to the desktop software model, companies in the same industry are not all that similar.  So, in order to sell more products, developers over-complicate their programs by jamming in as many features as they can in an effort to say "yes" as often as possible.  Ironically, this gave them the illusion of being useful, but ended up having the opposite effect.
 
Web 2.0 apps
In the 2000's, business apps started moving to the web, in the push towards Web 2.0. The big "ahh-ha" for web apps was that it became completely acceptable to produce a simple solution and stay simple.  In fact web apps proved that smart, streamlined design made systems more useful than complicated desktop software.  The best example, and a company I'm a big fan of, is 37Signals.  They built an incredibly successful company on the idea of creating products that "do less than the competition — intentionally".  Web apps were made to be simple partly from necessity: browser-based websites using html and JavaScript just have a hard time doing the fancy things a desktop program can do.  So rather than try to mimic the desktop, successful web apps focused on being the opposite of everything desktop programs stood for, and used the browser based constraints to their advantage. 

The other reason the web apps were successful was that they had the advantage of learning from the mistakes of desktop programs - since web apps are sold on monthly subscriptions they don't have to jam in features to justify selling annual upgrades. Companies like Salesforce.com built empires on being the "anti-software" based on this reason.
 
End-user web platforms
A shortcoming of Web 2.0's model of keeping it simple, though, is that a well disciplined web developer must say "no" much more often than "yes" to features requests, and must turn away users who start to outgrow their apps - otherwise they'll fall into the tangled feature trap that desktop programs fell into.  This, of course creates friction with end users who justifiably can't be expected to appreciate the bigger vision that developers have for their apps, and get frustrated from hearing "no" to most of their feature requests.
 
Web 2.0 apps have taken us a long way.  But they are no match for the next generation technology I refer to as end-user web platforms. Imagine you are an end-user and you have two, nearly identical apps to choose from.  Which of the following would you choose?

  • Web App A: Developed by a programmer using code.  Updates are made by feature requests only.
  • Web App B: Developed by a non-programmer on a platform. Updates can be made by users using drag and drop tools.

Of course you would choose Web App B!  The platform app would always win.  Web App A is a simple, useful app that solves today's core problems.  But Web App B is a simple, useful app that not only solves today's core problems; it also imposes no limitations on solving tomorrow's problems - whatever they may be.  Perfect for small business! It's like taking Henry Ford's Model T, clicking a button on the production line to paint it red, and then a month later clicking another button to add a sunroof, and then the following month clicking another button to add a rear spoiler!  Who wouldn't want that?
 
I'm going to clarify what I mean by an end-user web platform.  Unlike regular web-platforms, which are designed to be used by programmers, in an end-user web platform the user must be able to design and create a system themselves, without any programming knowledge. Users must have the same tools available to them as the developer that built the app.   In other words, here’s the big test: it must be possible for end users to re-create an entire web app themselves from scratch using drag and drop tools.  No coding.
 
Now, that's a whole new way of thinking isn't it?
 
Method Integration - Suite of Apps
When we created Method, we weren't trying to start a revolution.  We actually stumbled upon the idea of creating an end-user web platform.  At first, it was a platform we created for ourselves so that we could create a suite of simple QuickBooks apps that enabled users to develop and share their own features.  It was our solution for not having to put new features into our desktop software every year, thereby preventing it from getting more and more complex!  So for the problem we were trying to solve, the solution that later became known as "Method" just made sense.   We had to create our own end-user web platform since, at the time, such a thing in the web world didn't exist.
 
Now that we have a platform, we can rapidly churn out useful, integrated apps for QuickBooks. Later this week, we'll be putting out Method Warehouse, which is an inventory management app for QuickBooks.  It's amazing how simple inventory management can be when you strip it down to its core.  It's all about knowing where your inventory is (locations and bins), how they got there (transfer orders), and how much material you need to build and purchase in order to meet finished good deadlines (MRP).  The entire app is in one single "Warehouse Center" tab within Method.  How were we able to make it so simple?  Because the Web 2.0 world taught us to strip the problem to the core, solve the problem and nothing else.   But since it is built on an end-user web platform, users can keep it simple by adding only the features they need as they need them. Nothing less, nothing more.
 
Method Warehouse Preview
 

Given the optimal solution provided to small businesses, tomorrow's web apps will be built more and more on end-user web platforms, so my advice to everyone is to hop on early and enjoy the ride.

Want to spread the news? Click here to Digg this article.

'till next time,

Paul

Comments

No Comments

About Method_Paul

While studying at Queen's School of Business in 1999, Paul founded Alocet Incorporated, developing 'QXpress', which later became the top rated field service scheduling add-on for QuickBooks. Alocet Incorporated later went on to create Method Integration - an innovative small business management platform that allows users to create their own web apps for QuickBooks.