Building and maintaining integrations

Chift was born out of countless conversations with software publishers, SMEs, and IT service providers. Each time, the same observation came back: the software that SMEs use does not communicate with each other. Yet, when choosing software, customers are looking for one that can integrate with their existing tools.

As Meïssa Dieng Corbeau of Libeo, the French supplier payment specialist, explains: "Our customers prefer to work with the tools they are used to. Legitimately, they want an end-to-end automated process."

Software publishers are listening to their customers' demands. When the time comes to respond, they come up against the realities of building and maintaining an integration. This cornerstone of an integrated offering can prove difficult to lay.

By conducting interviews with SMEs, we realised that they look to optimise their processes through integrations as long as they can afford them. Software publishers don't always have the time or the technical resources to offer these integrations natively in their software. So, we decided to help software publishers help SMEs! Gauthier Henroz, Chift's co-founder.

Integration from the software publisher's point of view

Software publishers building an integration will go through several stages. Let's take the example of an accounting software that wants to integrate with the PoS popular among its customers. It would have to:

1. Complete a discovery process for the connector, including reading its documentation,
2. Obtain access to the software,
3. coding the integration
4. Testing and validating the integration,
5. document the integration
6. and maintain it over time.

And all this for each tool that the software wants to integrate with.

These different stages divert several weeks of work from the roadmap. They require days of work from the development team. They also break the devs' focus.

‍
💸 Adding a connector can represent an annual cost of €50,000.
‍

The sales or support teams of the software initiating the integration will learn this quickly: they will need to guide their customers. Often, it requires familiarising themselves with their software to guide them appropriately.

Once the integration is in place and at the heart of the customer relationship, work is not over. It involves monitoring the status of the connection(s), receiving alerts in case of problems, and potentially troubleshooting.

On these various occasions, the devs, sales, and support teams will have to coordinate and, if necessary, interrupt their respective workflows.

How do you build and maintain an integration?

When the question of integration arises, two solutions naturally come to mind: carrying out the integration in-house or calling in an external service provider. Both options have their risks and benefits.

1. In-house integration

There are excellent reasons for deciding to do in-house integration. It is core to the company strategy. It is an opportunity to measure expectations for a potential integration partner. It shows your customers that you put their expectations at the heart of in-house processes. In-house integration offers total control but comes with its share of costs and risks.

There is the opportunity cost of distracting developers from their core product priorities. There is the risk of demotivating teams who went through an initial integration and are asked to put in the effort again. There's also the risk of not being able to grow at the expected rate because of the time and resources necessary to an integration.

Finally, integration requires continuous monitoring of partner APIs. This monitoring and the alerts that come with it involve the in-house technical teams as well as the sales and support teams.

2. Integration via an external service provider

To develop and maintain its product, a software publisher knows better than anyone that it has to preserve the capacity of its internal teams of developers. The obvious answer is to call on external development teams. This response has its share of positive externalities: temporary recruitment brings on board senior profiles and can strengthen internal processes, such as documentation.

However, working with an external service provider does not come for free. It also means creating a dependency on an external service provider to carry out a project at the heart of customer relations. Last but not least, knowledge management and transmission can easily pose problems.

Software publishers and SMEs spending crazy amounts of money on consultancy to create the same integrations seemed like an aberration to us! Our idea is to be an integration partner, offering a standard, scalable, and affordable solution. Gauthier Henroz, Chift's co-founder.

The idea behind Chift is that these risks are not inevitable. There is the conviction that a software publisher can grow thanks to integrations. A software publisher does not have to build the integration or buy hours from consultants to have it.

There is a product solution to scale and manage the complexity inherent in an integration. It is the solution that Chift has chosen to develop: the Unified API.

3.  The unified API

A unified API is a layer of abstraction that gathers and standardizes the APIs of other software into a single model. With a unified API, the software publisher connects to software that makes sense in their business vertical. Their customers benefit from an integrated experience, from their usual cash management software to new financial management software, for example.

Chift's founding team knew from the outset that unified APIs are the integration powerhouse that SMEs need. The unified APIs enable software publishers to grow fast by offering integrated solutions to more and more prospects and customers. They respond to the inherent complexity of integration and the need for ease of use. Unified APIs are the solution that the Chift team is committed to developing, starting with four business verticals: accounting, billing, e-commerce, and point of sale.

‍