30 years as a software entrepreneur

We founded Vertec in 1996 with the aim of creating standard software for service providers. Today, we call it “ERP and CRM,” at the time our business plan stated: “We want to develop, offer and further develop a comprehensive and technologically leading solution for the EDP needs of law firms (TIM-Office).”

We did it! But the term “EDP” (for the younger generation: it means “electronic data processing”) shows how much time has passed. The company was called Vertec from the start, but in the early years the product was called “TIM,” which stands for “Time Is Money”. In 2004, we named the software the same name as the company. It soon became clear that our software is also in very good demand from all project-oriented service providers, not just law firms.

In this blog post, I want to share my experiences as a standard software entrepreneur who has stayed true to his product and customers for 30 years – and how to do that in the supposedly fast-paced software world.

An organization can only do something good

I believe that an organization or company can only do something good and should focus on that. In our case, a “CRM and ERP for service providers”. Not an “ERP that can do it all™”. With good reason, we do not add payroll processing or FAR, not even a warehouse or a webshop – these are not core requirements of our customer industries. In addition, there are already many systems that can do this (very well) and secondly, it is not good if a CRM vendor also makes a FAR; just like if a FAR vendor makes a CRM that still smells like FAR.

From product development to marketing and sales to consulting, project management and support, no one has to think about what product or product line he or she should be working on today. You can focus all the creativity of everyone in the company on one goal.

Of course, I know that there are examples of companies that have been successful in other ways – but we should be aware that all the examples in the IT industry are from a different era. And conglomerates like Siemens reorient themselves almost every year, buying and selling (or going public) companies. Will employees be able to participate in every step of the way while still working productively? And do all customers understand exactly where the company is the current heading?

The next technological cliff is coming

No matter how modern and technologically advanced you design your product, in 10 years it won’t be, and there’s a technological cliff that you have to overcome. It’s the privilege of younger developers to consider the technology you’re dealing with as absolutely superior, and even to think that it’s destined for eternity. As a long-time software entrepreneur and Product Management Lead, I know that’s not true. Faster than you think, the platform you’ve invested so much into is obsolete or can’t keep up with the new requirements.

What technological pitfalls have we had to overcome in the last 30 years?

1. mid-late 90s: the emergence of LAN technology at customers, of SQL servers and client-server technology
2. from about 2000: Web frontends as a new requirement
3. from about 2005: mobile applications, first on special devices such as handhelds, later on smartphones
4. from about 2010-15: the expectation that you can operate the software from anywhere (without terminal servers!), which then also enables cloud quotes.
5. from around 2020 under the keyword “digitization” the requirement of customers that an ERP can seamlessly integrate former “peripheral areas” such as DMS and that it is very open regarding the integration of data and services.

The current technological cliff is certainly the meaningful integration of AI capabilities into ERP and CRM. Although there will be corrections on the market due to very large investments in AI infrastructure, I very much assume that the technology will prevail widely. The already achievable and visible benefit is too great.

And that is exactly the right advise when the next hype is approaching. Ask yourself what kind of benefit you want to bring to your customers with a technology. For blockchain and metaverse, there were inquiries about our “strategy,” but no one could identify a real use case in the area of ERP and CRM. So the hype quickly flattened out again.

Architecture eats Technology for Breakfast

To paraphrase Peter Drucker’s famous quote (“culture eats strategy for breakfast”), I argue that architecture determines whether your product can meet changing demands, not technology. A sustainable and stable software architecture allows for new technologies and use cases, but state-of-the-art technology without a suitable architecture is a dead end in the long run.

But what constitutes a future-proof software architecture? In my opinion, one has to deal with (at least) the following questions:

• How do you encapsulate the business logic so that it is never duplicated? I have seen web apps where the SQLs were repeated for a REST API. If you want to have access to the objects (e.g. for an MCP server), the problem becomes bigger and bigger.
• How is the (standard) software adapted to the needs of customers? Is it done in an updateable way or do you even have (in the worst case) special builds for certain customers?
• Software is always structured in layers that communicate with each other. Are these layers clearly named and known, and do they communicate only with the respective layer further “up” or “down”? Take data persistence as an example: Of course, the database server used is a separate layer (because it is its own software), but which layers in the own software access the database independently? Another example is the UI: how does the UI access calculated data, such as a running sum? Is it computed by the UI or by a layer further down (which encapsulates the logic)?

Evolution instead of revolution – never try to make everything new

If the next technological cliff seems unattainable from the point of view of the current architecture and technology, the decision is often (too often in my view!) made to rebuild everything. In other words, to completely rebuild the existing software and replace the “old” system at some point. This strategy is tempting especially because young employees like to tackle new things and are convinced that they can do it in a short time.

I contend that this strategy leads to the abyss in the vast majority of cases. The reasons are manifold:

• The scope of functions of the existing application and the various use cases for customers are massively underestimated. Imagine a FAR: until you only have a “Minimum Viable Product” (MVP), it takes a very long time, because no one buys a simple FAR solution with debits and account statements like in the 1980s. No, the requirements are gigantic and one thing we must not forget: existing customers now have a fully developed application and will certainly not switch to an MVP just because it is more colorful and the buttons are larger.
• Because the scope of functionality of the existing application and the requirements of the customers are massively underestimated, the duration of such a project is also massively underestimated. But how much time and budget do you have? And how long are the existing customers willing to wait?
• Implementing a completely new generation of products with new ideas and processes will lead to a migration process for each customer. Even if the new software does (almost) everything the old one does, the impact is often greatly underestimated by customers – for them, it’s like migrating to a new solution, and this is where a different principle comes into play: Customers are loyal to a product that benefits them continuously, not to a product company. Even if the new solution satisfies all existing needs, you will lose at least 30% of your customers because they start looking around for a completely new software solution.
• You should also carefully analyze the effect on your own workforce: because the development of the new product is usually done by a different, new team, you suddenly have two teams: one that is allowed to use the “cool” new technologies, enjoys freedom of fools because the product does not yet have customers and also enjoys strategic priority. And another that has to maintain the “old shit” and must comment on customer bugs. At the same time, the cash cow in the company is due to existing customer contracts. It’s easy to imagine the conflicts: Who wouldn’t prefer to work in the first team?

How do you manage to evolve on the basis of what you already have? The answer to this is anything but trivial and depends heavily on what kind of architecture you have, what kind of lock-in technologies you use (e.g. Oracle Forms), etc. But I maintain: no matter how desolate the current situation is, with enough imagination and investment you can find a way. It starts with recognizing the existing “legacy” as an “asset,” not as a “liability” – the word appears prominently in the killer argument of “technical debt”.

Functionality matters!

In addition to all the discussions surrounding HCD (human centered design) and MVPs (minimum viable products), do not forget that (except in the real start-up scenario) you have existing customers who use and need a certain functionality in the product. From my point of view, it DON’T make sense to launch a new version of your product (or e-banking, website, app, etc.) that looks more colorful and has bigger buttons, but misses parts of the existing functionality.

Although many customers judge a software product purely by its UI – it can get a little old-fashioned just because it was designed 5-7 years ago. But the same customers don’t want to have an update to something with modern UX/UI, which loses functionality!

Documentation vs. many support employees

Many standard software manufacturers criminally neglect the documentation of their system. There is no info at all or just a few FAQs. In any case, hoarding know-how is seen as increasing sales, especially for sales partners. However, how they hold this know-how when it only exists in their heads is a mystery to me.

I don’t think this is a good strategy for several reasons:

• any software vendor has more margin on IP (intellectual property) than with services.
• only explicitly available knowledge can be used in terms of AI. And more and more customers expect this.
• hiring more and more support employees is also scaling very poorly, also in relation to other countries and languages.

Conclusion

The principles formulated here have been valid for me for decades and are thus obviously not exposed to the waves of constant technological change. Quite amazing for our “fast-moving” industry!