My company, HMS Software, just released a brand new version of our keystone product, TimeControl. That’s great news of course and you can read all about it at HMS at: but what went into this development and release has our company thinking about development quite differently and so this post is more about how software development philosophies are evolving.  It’s certainly a watershed moment for us.

TimeControl has been a browser-based product since 1999 which predates many companies in the software industry and certainly many companies with browser based products. For awhile TimeControl really only worked on Internet Explorer.  Seven years ago we took pains to ensure that our product would work on multiple browsers and on multiple devices.  We did testing on Internet Explorer of course but also on Firefox, Chrome, Safari and even Mozilla on Linux.  For a few weeks I took great delight whenever I would wander into an Apple store to point the iPads and Macs I’d touch to the TimeControl demonstration URL.  We were delighted to have expanded our view from the most prolific browser to support for many browsers.

We even made a mobile interface with a responsive design to allow browsers on different sized mobile devices to get access to the most common functionality of the timesheet system. But this was still through a browser.  Yes, it was groundbreaking at the time, but it was still inside a single direction of development.

In the last 3 years, we’ve seen a critical mass of organizations and users shift their computing time to more software as a service and mobile devices. TimeControl is already available both as a purchased license for on-premise deployment and as a subscription service so I’ll save that part of the conversation for another day.  The movement of computing to mobile SmartPhones and Tablets however is significant.

So, this month, as part of our new release of TimeControl, we released the TimeControl Mobile App. The development of the App over the last year came with plenty of design decisions.  Should we write native code for Apple and Android separately?  Should we use a hybrid design?  Should we make the product work asynchronously or just like the browser version? How different should the interface be? Should we make some functionality that just works on the App?

Yet, through all of that conversation, until near the very end, most of us were thinking of the App as an extension of our existing development.

Now, with the App already published on both Google Play and the Apple App Store, we have decisions we’ve never considered.

Do we sell it or give it away? We decided quite some time ago not to charge for the App.  We considered selling it as an additional feature or even using advertising to monetize the features.  In the end, releasing it for free still means that clients have to own a license of TimeControl as the App only works when connected to TimeControl’s Server.

Should development of the App continue on an independent stream from the main product? The App is dependent on functionality available in the server itself of course, but what might we be able to do without updating the server?  Or, should new features and improvements await the next major release of the server-based TimeControl?

It’s a quandary.

Many users, including myself, now wear a smart watch or other wearable technology. When something new like the TimeControl Mobile App come out, should I be expecting a watch version?


Users of Apps are less invested in these conversations than they’ve ever been. We have come to expect to look down at our phone and find the Apps we selected being updated with new features and better performance all the time.  We expect to find an App that requires no training, no explanation, and no headaches.  It is just supposed to “be”.  It is at the developer level that we are expected to take all the complexity that used to be so present for the user away.

Software developers all over the world are considering these questions and it is an evolving marketplace. There is little room left for monolithic thinking that we build one big thing and people will use it once we explain how.

One thing is certain, there have been many changes in how we look at the software market and there will be more to come.