This is part 2 of a blog series around different approaches to business software. While this blog stands alone, you can read part one here.
Same, same – but different
People that know me are probably sick of me comparing Kobas to the iPhone, but in case you’ve not had this pleasure, I’ll say it here. If you think back to what you had in your pocket / bag around 2005 it was probably something like: mobile phone, camera, diary, address book and a music player. By now you’ve probably condensed that down to a single phone – and life is better for it.
The path to this single device wasn’t always clear, the early phone cameras were no match to a small digital camera, they didn’t have the storage capacity of your music player and weren’t quite as easy to use as your paper diary. But the suppliers listened, improved and here we are in 2022 where most high-end phones are pretty much as good a standalone option for all but professional uses.
The simple truth is that technology converges over time, which is generally a good thing, and continuing this analogy with Kobas I’d say we are a 2019 smartphone – on the right path, a fair way along it, but not the finished article yet.
There is also growing evidence in the hospitality software space that the Kobas view is gaining traction. Setting aside our own explosive growth over the last 18 months, you can look to other providers doing a similar thing. Zonal has a long history of buying companies that provide a solution it doesn’t have, to add to its suite. Access Group has spent a significant amount of money purchasing some very good systems and trying to stitch them together. More recently we’ve seen Mapal start something similar. These are all really big bets on the value a wider, centralised, application can bring.
The holistic approach
For all the money spent and how great these separate systems are in their own right, they are at a significant disadvantage to Kobas in two key ways that will only grow in importance over time.
Firstly, and most importantly, Kobas was founded on the belief of a holistic approach to hospitality management software, which means we’ve never looked, wanted, or needed to buy in a third-party system to extend our offering. It’s certainly slower to build everything yourself, and maybe even more expensive initially, but the long-term benefit you get is staggering. No legacy code, no separate code base to maintain, no competing coding styles (if you ever want to see developers getting overly passionate about something trivial, have a read of some of the online debates about the use of tabs versus spaces in your code!), and many other factors.
Drawing on another analogy, it’s much easier to construct a building in stages where there is a plan for the overall structure than it is to build a small structure, then try to add an extension, a basement, a container bar… then re-wire the whole thing.
In reality, this sort of approach, with both buildings and software, is taken because it’s the only option available and probably quicker to market, but this shouldn’t be confused with being the best-suited approach. Having a well-defined project and making minimal changes during development is a proven way to a solid product. It’s the reason there are a growing number of applications that have a relatively limited scope; they are simple, concise, and quick to write.
If you have, say, an EPoS company and you want to offer your own self-ordering app, you need to either:
- Integrate with someone else (no ownership but limited upfront and ongoing costs and quick to market)
- Write your own (total ownership, but some upfront and ongoing costs and slower to market)
- Buy a company that already has one (total ownership, large upfront and some ongoing costs but faster to market)
Different companies will choose different options that suit them better, but in the long term option two gives the better trade-off between costs / ownership / time.
The other crucial difference between Kobas and just about every other EPoS provider, and many other sector suppliers, is our technology stack. Everything we do, be it hospitality EPoS, KDS, Loyalty, Kiosk, Self-Order, Rotas or CRM is written to work in a web browser powered by the same underlying technologies. This simplifies our business and software in some incredible ways, not least that we don’t need to worry about integrating with various hardware components as the browser takes care of this.
Other benefits are:
- We have an incredibly modern software stack that is being constantly improved by a large online community
- We have a single version of our software that runs in all locations: till (different makes and models), tablets and phones
- There is a ready supply of developers familiar with our stack, who can work on any of the products we offer
- Lower costs for our clients as no licences are needed for Windows
- There is massive potential to scale with trivial changes – as we use internet-scale technologies, even if we were to grow our install base to 50,000+ locations, we still wouldn’t register compared to our stack’s abilities
Saying all this doesn’t mean that you can’t operate with the models of other providers of a centralised system, it’s clear you can do. My feeling, however, is that on a like-for-like basis our software is easier to maintain, easier to scale, and easier to extend.
But what does all this mean for you as an operator?
On the face of it, you don’t need to care too much about these things as they’ll mostly be hidden behind client support and account management. What you might notice, however, is slower innovation and increased costs to cover more complex needs. There is also no certainty that you can utilise data from what were once separate systems in the way you want as while they appear to you to be one thing, under the veil of a single sign-on, they are still standalone applications. It’s also likely they’ll have different teams working on each application, so getting enhancements made that span two or more of them is harder than when it’s a single team (though easier than when they are independent companies).
In the future, most if not all software will be written like Kobas is, working in a browser, on any device and at any time. For now, you have a couple of choices:
Do I look for a centralised supplier or try and build my own combination of systems? And, if I choose a centralised supplier, do I want to use the bought and bolted together version, or the one that was conceived as a holistic system from the beginning?
I don’t think it’s a hard question.
Disclaimer: The opinions expressed in this blog post are those of the author and do not represent the opinions of the people and/or organisation the author is associated with, unless stated otherwise. The thoughts and opinions of the author may change from time to time as they learn more and/or develop an understanding of the topic that is being written about. This blog post provides a snapshot of the knowledge, views and opinions the author holds at the time of publishing. The author has the right to evolve and change their opinions without assigning any reasoning.