Work tools: Build in-house or buy from the market?

We talk to Wojciech Zawistowski – VP of Engineering at Contractbook, a company that develops a SaaS platform for centralizing, managing the lifecycle, and extracting data from digital contracts.

Autentika: Let's assume we need a new business app for our company – such as a tool for crafting contracts or planning employee schedules. Is it better to build such a tool in-house (assuming we have a team) or look for a ready-made solution externally?

Wojciech Zawistowski: In this situation, I mostly see drawbacks to creating an in-house solution, mainly because of the high cost and workload involved. It’s essential to consider not just the initial tool-building phase of our developer team, but also the ongoing development and maintenance.

Buying an external tool means spending a lot of money, but developing it yourself means maintaining a team of 10 people for a year – a much higher cost. And we’re talking about just one tool here, whereas we usually need many of them in the company – not just for contracts or scheduling but also for tasks such as invoicing, email campaigns, CRM, etc.

From my experience, I can say that trying to build an application similar to Contractbook internally is almost impossible. When we started as a startup, our product team was 60 people at its peak. And that's just for one product we spent six years refining! Companies like Microsoft or Google can perhaps afford something like that, but small and medium-sized companies cannot.

Read also: Why business app design stands apart in UX/UI? My top conclusions

Do internally developed tools typically have lower quality?

When creating an internal application, some aspects can be overlooked. You might tell your colleagues, "Here's a little workaround." The application works, even if it doesn't have an attractive user interface, for example. However, quality issues aside, user expectations have evolved considerably. I remember old invoicing tools developed for MS-DOS that weren't expected to have a great interface or user experience.

If invoicing is cumbersome and cannot be automated, everyone will feel it. Therefore, it's undoubtedly a challenge to compete with the offerings of external companies in this area.

I suppose there are some exceptions.

There are indeed exceptions. One of them is when the field we're working in is so new that suitable tools are not yet available. This was the case a few years ago when we were developing our own analytics tools because Google Analytics was still relatively new and incomplete. Moreover, not everyone had JavaScript in their browser, and there were doubts about the accuracy of these analyses. Nowadays, it's almost unimaginable to develop analytics that can compete with Google or other professional solutions.

Another exception appears when a company operates on such a large scale that the standard market instruments aren't sufficient for its needs. Yet even large retail chains that deal with various complex issues such as promotional vouchers, gift cards, returns, complaints and different pricing strategies, rely on ready-made solutions. In the past, this was unusual. Today, a single application such as Stripe can handle subscription management, deferred payments, instalments, and online transactions. As a result, it's useless to replicate a "second Stripe" for a single company, especially considering the low prices of these tools, which are aimed at both large companies and small businesses or influencers selling their e-books.

For example, when I entered the Brazilian market at eSky, we had to develop a system for instalment purchases, a common but complicated practice in Brazil. So, we developed our system, which we integrated with other tools.

Read also: In-house UX design teams vs. external consultancies – which approach to choose?

Do I understand correctly that this integration was important at the time?

Yes, because it allowed us to link certain flight reservations to invoicing, which is a possibility that the accounting systems didn't offer at the time. The accounting software was used exclusively for accounting purposes. If you wanted to import invoices, you had to export them as CSV files from one system and import them into another. The applications didn't communicate with each other as they do today, where a reservation is linked to an invoice, along with data from the CRM system and reports for analysis in the operations department. We felt that it was worth developing such a tool, which added significant value.

However, every approach has its limitations. For example, we didn't develop our accounting or call center support systems but opted for professional tools. I stick to the principle of creating internally tools that bring a competitive advantage. Netflix is known for its high-quality and fast video playback - that's the system's strength. But if my company wanted to upload a short educational video for users, we'd probably choose YouTube rather than trying to copy Netflix.

Is this not possible with the products available on the market today?

I remember when the first online applications appeared and replaced the desktop programs installed in companies. In these new applications, exporting or importing files was more difficult; you often had to switch between interfaces and log in again. Application developers quickly recognized this problem and began to prioritize connectivity, so the popularity of APIs skyrocketed. Modern accounting programs no longer require exporting files for processing and importing them into another application. APIs facilitate direct data retrieval; subsequent APIs enable seamless import into other applications.

But how does this relate to the in-house team that creates the "glue" layer"?

It's worth delving into the question of why companies need new tools at all. After all, documents have been processed manually for thousands of years. However, it's not just about gaining new skills; it's also about increasing work efficiency, streamlining processes and saving time and money. If the systems aren't integrated, these benefits don't materialize - everything is entered twice, exported, imported, etc.

APIs were the first step in connecting applications. The in-house team could only develop the connection layer for the existing tools in the company, ensuring a smooth data flow. In our case, coming back to eSky, this made sense because the tools were still relatively primitive and not everything could be automated.

What if we really have a non-standard process and a large organization?

In my opinion, it's worth thinking about sticking to standard processes at this point and saving time and money by using a pre-built application. Is our unique workflow really that important?

At Contractbook, we appeal to the market by offering an exceptional contract tool, not by selling subscriptions to that tool in a very specific way.

Read also: How to build a knowledge system around a new tool?

And what if, for some reason, we don't want a ready-made tool and we have the choice between creating an in-house tool or hiring an external company?

Hiring an agency will be more expensive than having an internal team. It's worth considering when we lack domain knowledge on a particular topic - for instance if we want to build an accounting tool but lack expertise in accounting. However, here I question the frequency of changes in such a tool. Often, we order something, purchase it, and the tool doesn't evolve despite changes in the company's needs. For example, accounting software needs to be updated quite frequently, but usually due to legal changes rather than internal company changes. It's different when we purchase a tool to handle our unique processes. These are constantly evolving. Therefore, the only solution here is long-term cooperation with the provider, a partnership, rather than simply purchasing a product.

Why do you think companies today are so inclined to adopt standard market solutions? Is it because technological progress facilitates their development, or because of the trend towards process standardization and the need for uniformity?

This is mainly due to the maturity of online solutions. In the past, standardization wasn't so important because the applications worked independently of each other and required numerous manual tasks. However, the Internet and the development of cloud technologies have promoted the standardization of these processes.

Nevertheless, the challenge of data flow remains – a key issue for many companies today. Many customers prefer seamless data transfer directly from the tools and don't use intermediary applications such as Zapier.

Contractbook, for example, seamlessly integrates data from CRM systems such as Salesforce or HubSpot into contracts and then forwards them to the invoicing software. Customers receive this service as a standard offering so they don't have to integrate all applications individually. This meets today's customer expectations, and we are responsible for fulfilling them. Even if it's not always easy, some connections can be configured with a single click. Sometimes, however, a customized connection is required – a service we can offer.

So, is today's innovation more about integrating applications and tools than about developing the tools themselves?

Work tools have been around for thousands of years, but they're no longer operated manually. Instead, they're increasingly interconnected, offering real-time and cost savings through integration and automation that streamline various tasks. The next step, which we're already implementing at Contractbook, is treating documents as data. Contracts and agreements are no longer just seen as text, but as valuable data. This creates opportunities for artificial intelligence to extract numbers, amounts and dates and perform tasks such as setting reminders for contract renewals. This approach leads to significant time and cost savings and is likely to be the leading trend in the future.

In addition, ease of use is crucial but often overlooked in internal applications. At Contractbook, we emphasise usability and pride ourselves on offering a convenient and user-friendly interface.

How do you see the role of AI in work tools?

Many of today's functionalities are gimmicks that don't really speed up work. The goal is to eliminate unnecessary steps, and AI can help in it. The first step was to create visually appealing and user-friendly interfaces. The second is automating tasks, and the third is letting artificial intelligence do them. Of course, full confidence in AI is not yet justified, and its results need to be verified. However, the qualitative leap is already recognisable. Our customers no longer have to search through hundreds of contracts manually but can review the required data in a table format provided by the AI and simply click "ok" Instead of spending hours reviewing contracts, they can submit them to the application and have the required data extracted within 20 minutes.

However, AI is still in its infancy, and there is still much to explore regarding its potential applications in work tools.

Wojciech Zawistowski – with over 20 years of experience in product companies, he has a strong track record in developing in-house and commercial tools across diverse industries such as taxes, tourism, legal tech, and more. He specializes in building and managing cross-functional, agile software teams focusing on product and customer orientation. Additionally, Wojciech is an author of content related to career and professional development for software developers, which he publishes on LinkedIn and in newsletters.