Chapter I: DNA

You may have heard that humans share about 90% of their genes with mice. Mice are often used in medical research because many human genes have analogous functions in mice. Interestingly, humans even share a significant portion (about 60%) of their genetic material with fruit flies Drosophila melanogaster.

From an engineering point of view, this is both fascinating and expected. Our creators—whether they are the Universe, Gods, Aliens, or something for which we don’t yet have a word—engineered this world in a way that naturally involves sharing common functionality across species. Things become even more intriguing when you consider the exact numbers: Humans and mice share 90% of the same code and data to function.

If I were a science fiction author, I might entertain the idea that mice were created with the goal of testing and verifying some of the upcoming primate body functions and processes. Much like how mice are currently used in medicine to reverse engineer and test human body functions.

What is contained in those 60%-90%? The foundation of life. These are the basic building blocks for any animal life on the planet, defining all the complex processes necessary to bring an animal species to life. This foundation is the essence—it’s complex, super important, and barely visible, existing behind the scenes (or within the scenes).

Chapter II: SaaS Applications

In the software world, source code and data (models) play the same role as DNA in the biological world. Most of this code (DNA) is not directly exposed to the end-user; instead, this code has little to do with the application features. It forms the foundation of the application—the building blocks necessary to bring the application to life.

Typically, this code has many layers: starting with the infrastructure layer (servers, databases, etc.); the client layer (web, mobile, etc.), which deals with the infrastructure; various services (authentication, authorization, etc.); utility functions and frameworks (logging, error handling, reactivity, scheduling, collaborative editing, etc.); general-purpose UI components (such as tables); and finally, the domain-specific logic on top of all of that.

In a well-designed application, the domain-specific logic is just the tip of the iceberg. I wouldn't be surprised if a thorough analysis showed that only about 5% of the code is specific to the application domain (such as CRM, incident management, or user support systems). The remaining 95% of the code provides the foundation necessary to make the application work. If you were to ask the authors of a well-designed CRM application how much of their code they would need to transform their CRM into a user support system, the answer would likely be around 5%.

Of course, the actual answer might be different and more than 5%. However, if it is significantly more, it could be a sign of poor design or just a reflection of the Minimum Viable Product (MVP) stage of the app, which is not meant for production use.

Moreover, even at the domain-specific layers, every niche SaaS application tends to create the same parts of business logic. For example, you may find a "Task Management" module in nearly every niche application. This is common in CRMs, Applicant Tracking Systems, User Support Systems, and almost everywhere else. Typically, these modules are poorly designed and implemented because they are not the main focus of the application. They are just a side effect of the niche.

And finally all these niche applications typically integrates with same services: Google, Facebook, Stripe, Twilio, Slack, GitHub, etc.

Chapter III: Niche Applications Madness

The software world is full of niche applications. There are CRMs for real estate agents, CRMs for lawyers, CRMs for dentists, CRMs for plumbers, CRMs for software developers, CRMs for CRMs, and so on. The same goes for Applicant Tracking Systems, User Support Systems, and many other types of applications.

As discussed in Chapter II, authors need to rewrite only about 5% of the code to transform a CRM into a User Support System. Possibly less, as some business-logic functions (such as task management) remain the same.

I've been concerned about this for years: creating an application like a CRM to a production level and making it feature-complete so it can be used by real users is a massive amount of work. It may easily take a couple of years for an experienced team of highly skilled engineers. Many teams worldwide are currently on this multi-year journey (e.g., working on a CRM for plumbers or a "modern" CRM, whatever that means).

These teams are essentially wasting tens of man-years each to create 95% of the foundational/integration layer, then common functionality of CRM including task management, just to expose their niche features or "modern" ideas to the end users (which might be less than 1% of efforts if we speak about a plumber-specific CRM).

Why does this happen? Why has such madness become the norm? I think there are several reasons:

First, what I can probably call "Common Misconceptions." I've always been a "platform" guy, and since the '90s, I’ve heard from people of various expertise levels that it's "impossible to create an app that will handle all needs well." I still hear this from many people, and I can't understand their logic even after 30 years. The funny part is if you ask each of them "why do you think so," you'll immediately realize that most have never thought about "why"; for them, it's just a form of "common sense."

However, the reality, including the software world, is full, full of examples of products that perfectly handle the needs of different industries, workloads, niches, etc., in an excellent way. Moreover, the most used and most successful software in the world is precisely this kind of software. From Operating Systems, Databases, and Web Servers to Microsoft Office, Google Docs, and Slack, these products are used by millions of companies in different industries. Excel wasn't designed for accounting, but it's used by millions of accountants. Slack wasn't designed for software development, but it's used by millions of software developers. And so on.

Honestly, I still do not know any real reason why it's "impossible" to create software that will handle all needs well.

Second, Apple's influence. I believe Apple contributed significantly to this madness by creating an App Store. Remember "We've got an app for that"? This was a great marketing campaign, but it also created the "niche problem" we're talking about. I admire Apple, and Steve Jobs was a pure genius. He did everything right for Apple and the new mobile computing market they created. The mobile market was new and in desperate need of many applications and many vendors. And Apple needed them now. So attracting as many developers as possible to create as many apps as possible quickly was the right strategy, and Apple succeeded. However, it was a strategy for a new market, a new platform, and a new era.

Apple couldn't wait a couple of years for vendors to come up with serious, multifunctional apps for the App Store; having an empty App Store for a couple of years was not an option. They needed to fill it immediately. And they did it. But people started to believe that this was the correct way to build software in general. People began to think that every problem should have its own app. This mindset led to the proliferation of niche applications, many of which have no real reason to exist.

Third, I believe marketers love this madness and continue spreading this "impossibility" misconception, which is close to a "lie." It's much easier to sell a niche application than a multifunctional one. It's much easier to sell a CRM for plumbers than a CRM for everyone. It's much easier to sell a CRM than a CRM and also a User Support System. And so on. Or at least they think so (which could be another misconception). What is true is that the broader your audience, the more competition you're facing, possibly ending up competing with companies like Microsoft, Google, or Salesforce. So from that perspective, marketers will choose a niche market where they can "compete" without clashing with industry giants for market share.

Chapter IV: The Everything Apps

Let's define what I mean by "Everything App." This is very important for further discussion. A chess application bundled with a photo editor and a music player is not an Everything App. It’s a "bundle" of applications.

By "Everything App," I mean an application that shares a vast majority of codebase and infrastructure, as well as a lot of business information across different problems this everything app is designed to solve. For example, a CRM and a User Support System address different problems, but they share a lot of common functionality and business information. They share a user base, task management, notifications, integrations (calendars and mail), customer (user) information, and a natural information flow when a customer becomes a user and vice versa. They share a lot of things. And they can share even more if they are designed to be Everything Apps.

This is not a new idea, and this way of thinking was more common in the past, before the "we have an app for that" mindset and niche madness took over. Moreover, consider Rippling and its CEO's Parker Conrad ideas. What they are building is essentially an Everything App in the HR space. Parker is a guy who didn't buy into the "niche madness."

Rippling created an Everything App for HR, and it’s working well. Parker Conrad calls it a Compound Startup which is fine, but it's important to understand that "Compound Startup" is more of a business perspective. From that viewpoint Atlassian could also be considered a "Compound Startup" though their technical solution is far from being a well-designed Everything App. An Everything App is more about software design, not business design, and any startup developing an Everything App is inherently "compound" by definition.

So, why are Everything Apps better than Niche Apps?

First, developing Everything Apps is in orders of magnitude more efficient. As discussed in Chapter II, you need to rewrite only about 5% of the code to transform a CRM into a User Support System. This means that you can add a User Support System to your existing CRM app with 95% less effort than creating a support system from scratch. This is a huge difference, not only in go-to-market (GTM) time and effort but also in maintenance, support, and further development. Very likely, a bug fix will affect both "modules" simultaneously.

Then, let's add an Applicant Tracking System, software development project management, and other modules to our Everything App. The more modules you add, the more efficient you become. The more modules you add, the more you can share across them. The more modules you add, the more you can leverage the power of the Everything App. Finally, you might have 20-50 niche apps in one Everything App, spending just twice the effort compared to creating one niche app. This is a huge difference.

Second, integration. The current world of niche apps has made everything so fragmented and almost impossible to use as a whole system. You need to switch between apps, copy-paste information, re-enter information, and re-learn how to use each app. This is a nightmare. Therefore, integration among those apps has become essential, and there are many solutions to this problem.

People who think they can integrate two modern applications together are both right and wrong. Typical integration between two applications in 2024 is at a similar level to copy-paste functionality in operating systems from 1994. If you think about it, you'll realize that there are no real integrations; it's just workarounds. A typical "integration" assumes "copy-paste automation"—for example, if you create a customer in your CRM system, it will automatically appear in the User Support System when the customer becomes a user. Or some property changes in System A will trigger some action in System B.

I'm pretty sure that a very basic level of "integration" is what companies worldwide spend millions on. Many companies work on products to facilitate that, managers get huge bonuses, and there are a lot of presentations about "successful integration projects" going on. I believe CEOs are happy to know that the entire IT department completed an "integration" project I described in a couple of months. If you think more about it, it's crazy. Assume you have a well-designed Everything App. How much effort would you need to implement such a level of functionality? I would assign an intern for a single day's task to do it.

Integrating several niche apps to have consistent information about users/customers can be a nightmare. You need to use one app as the source of truth and somehow prevent any modifications from other apps, implement a custom shared database as the source of truth, or just forget about integration and force your employees to open one app for up-to-date information. This is a nightmare.

Third, synergy. There will never be real synergy between niche apps because they never work as a whole. Even with perfect "integration," you only automate information entry; instead of employees copy-pasting data or updating data because of some "events" in another system, it will be done automatically. But it will still be a set of isolated niche systems, so no synergy effect will emerge from that.

Think about the kind of synergy you can achieve in your business if you have a well-designed Everything App. I'm confident you'll find many opportunities. It's also worth listening to Parker Conrad's interviews—he talks a lot about synergy in his Everything App... sorry, Compound Startup.

Conclusion

To me, whatever you do, you should always aim to create an Everything App. This aligns with the nature of software development. Generalization and reusability are key concepts in software development. When building your next app, you should always consider what other problems you can solve with the same codebase and infrastructure at every layer of your solution.

That's why we initially envisioned Huly as an Everything App. Moreover, when we started Huly, we had no idea what types of apps we would create and for which industries. Huly started with a platform, a layer to develop virtually any SaaS application very efficiently. It was initially designed to be extended by plugins, and by plugin, I mean any big or small extension of the platform and the application. It could be a huge functionality for the end-user or just a button extending the UI of an existing application.

None of what I'm writing about are new ideas; many companies across different industries have proven that everything apps work well and are very successful. I already mentioned Rippling, which is a great example of an Everything App in the HR space. Software engineers might also remember Eclipse. I recall that in some documentation or blog post, the Eclipse Platform authors wrote that Eclipse is a platform for "Anything and Nothing in particular." And it was very true. Eclipse was also an exceptional example of an Everything App from a design and implementation perspective, demonstrating how to build a platform for an Everything App, how to reuse code, and how synergies emerge.