December 11th, 2025 Business & Technology

Most businesses can get away with buying software for their day-to-day operations. Either their business is not complex enough, or it is already so big that the big guys are interested in you, and will bend over backwards to please you. If you are somewhere in the middle, you have a choice to make, and I am going to make the case that building at least the core business platform internally makes more sense today than ever before.

Mental Model

Just like you have friction with integrating numerous off-the-shelf software products, each software company also has conflict supporting many diverse customers. They have to find common functionality that works across their customers that can be supported as a cohesive product.

Let’s imagine a simplified scenario, where you have some sequential three step business process, for example for a car insurance company going from an online inquiry form to a signed contract. And let’s say you have to deal with three different applications sourced from three different imaginary software vendors along the way: Gherkinsoft, Buyforce, and Octillion.

The steps are:

1. A customer opens a website with a form, enters their details, submits them.
2. A sales person gets a notification, calls the customer on the phone, agrees on a quote, and generates a contract that is sent to their email.
3. The customer signs the contract and makes the first payment. Linear process.

What looks like a line to you can be visualized as a curve navigating the space of features that each of the product has.

Curve through two-dimensional partitioned space.

Each time you cross the boundary, there is an integration step between the two pieces of software. At that point you have to make sure the data is synchronized correctly, and that the data model makes sense. In most cases you will have to maintain a mapping of terms used between the software - what is an order in Gherkinsoft, might be called a task in Buyforce, or there might not be any 1-to-1 mapping at all. In addition, there are Non-Functional Requirements to consider, such as security, reliability, and performance.

If you zoom in, you can also imagine navigating not the whole software package, but individual features.

Single product zoomed in, partitioned by features.

You are not using all the features that the product provides, only those that are necessary to complete your process. It is usually a small fraction of the whole set. But you still end up paying for everything.

The Gap

While your business is similar to a lot of others, there is historical or environmental context that also makes it unique. You will run into gaps in the process where the existing software breaks down.

Gap between two partitioned product areas.

You have these options to deal with the gap:

• find another piece of software that plugs it,
• ask the existing vendors to develop new features for you,
• build something custom yourself,
• modify your process to fit the software,
• have humans handle the gap manually with a Standard Operating Procedure (SOP),
• do nothing, and fail.

These are all legitimate options depending on the scenario, your time sensitivity, your budget, and the overall importance of the process. But I am here to argue, why building something yourself makes sense, especially considering new developments in the IT industry.

Own Your Data

If I ask you, where does the data live in the example above, what would you say? It is smeared across all three software products. This is very problematic, considering that the organizations of tomorrow are trying to off-load a lot of operations and analysis to artificial intelligence. Finding answers to simple questions can become laborious exercises in exporting, importing and joining across different schemas.

This is the core idea behind the Data-Centric Revolution in the IT industry - put your data in the middle. Own your data store, and develop your own ontology (a.k.a. business model, schema). Your apps can be small, focused on specific problems, and ephemeral.

Data store in the center with apps attached to it.

Once you shift to the data-centric mindset, experimentation becomes easier. The barrier for trying out some operational improvement using software is reduced. Your organization becomes more flexible and adaptive. Costly mistakes are avoided, when there is one consistent place, where you can get an answer. In addition, when everyone shares the same language, it is easier to communicate ideas and train people.

Supporting Trends

I would not be so bullish on the above idea, if it wasn’t for the Large Language Model effects on developing new software. The cost of building and modifying these small apps has dropped immensely. What used to take weeks to build a custom user interface with a small back-end now takes hours.

In addition, there are numerous cloud platforms that are rock solid at this point that greatly simplify the software development and deployment processes. Not only are they easy to use, but they are also cheap. You get an amazing amount of value with a typical Postgres database running on commodity hardware.

Next Steps

I will caution that not every business should be building their own data platform. But there are common signs that you might be ready, that I will cover in a follow-up article, including how to maximize your chances of success, and convince the rest of the organization.

However, if what you have read already makes sense, let’s get in touch.

Ready to Own Your Data?

Let’s discuss how a data-centric approach can transform your business operations.

Start a Conversation

Subscribe to Future Articles

Get notified when new articles are published. No spam, unsubscribe anytime.

**Thank you for subscribing!