Bringing AI-as-a-Service To Every ERP With an API Ecosystem

One of the things I find interesting about working with a SaaS product such as Kaunt is the relationship between business strategy and technology. There are always plenty of things we would like to build, but as long as development resources are finite, everything boils down to hardcore prioritization - and it is the business vision and strategy that should guide this prioritization.

We are currently investing a large part of our development efforts in areas around our public API ecosystem. For the non-technical reader, an API is basically to a developer what a graphical user interface is to a normal user. It usually allows for the same actions as a graphical interface but is built to be invoked via software. Hence, APIs allow two pieces of software to perform actions and exchange information with each other similar to how humans interact with software using a mouse and a keyboard. For Kaunt, by exposing APIs, we essentially allow anyone to automate accounting with AI, freeing up resources for more meaningful work.

Exposing services via APIs is nothing new at Kaunt, but really embracing our public API ecosystem is. And as everything we do at Kaunt, we don't do it halfway. In this article, I will discuss the importance of an API ecosystem in a SaaS-company like Kaunt and explain how we approach the task of building such a product. Firstly, however, I would like to give a bit of background on our journey which will clarify why now is the right time for us to prioritize public APIs.

A Brief History of Kaunt

Most SaaS start-ups go through a number of phases, which generally look like this:

MVP development ➡️ Product/Market Fit ➡️ Scale

Each phase has areas of focus and goals, and trade-offs have to be made to ensure that time and resources are spent on the right things. In the first phase, the most important task is to create a prototype that can be used for iteration, and, ideally, to find a number of customers that can help with co-creation. Kaunt was in this phase a few years ago, where we developed an MVP with a large Danish region (the B2G segment).

With a prototype in production, we had a point of departure for iteration and learning. In collaboration with an increasing number of customers, we gradually fine-tuned the product to what really created value for the masses rather than for individual customers. Over time, this has resulted in lots of ”noes” and eventually a greatly simplified product, both in terms of features and its price structure. Instead of building tons of features, we invested in our AI technology, showed proof-of-value, validated our business model, and gained the traction required to start scaling the business.

In the iterative phase, I find it beneficial to own as much of the tech stack as possible and avoid dependencies to external partners e.g. via public APIs. This is because external dependencies make pivoting more costly, as partners need to adjust their parts of the software stack to the new direction of the company. Partners may be busy with other things and not in as much of a hurry as you are, making the timeline for executing pivots long and slow. We therefore built and maintained all integrations to ERP-systems ourselves at the cost of having only a small number of different integrations - but that is completely fine in this phase: If we manage to nail the business case, scale will inevitably be needed later - but if we don't, we haven't wasted time and resources on premature scaling.

During the last year at Kaunt, we have gradually moved into the scale phase. Contrary to the previous phases, in which learnings about the product/market fit was one of our main outcomes, the focus of the scale-phase is mostly to take those learnings and figure out how to automate everything and reduce operational costs per customer. To allow for scale, we can no longer afford to invest many resources into each customer onboarding and operations, mainly due to the following two reasons:

• Firstly, we do not increase revenue if we cannot scale our customer base without scaling the number of employees by an equivalent rate.
• Secondly, lowering the operational costs means that we can increase our customer base to include mid-size companies in addition to the enterprises and large customers we currently serve and make those mid-sized companies generate revenue.

Now, let's get into how an API ecosystem is one way to leverage scale at Kaunt by considering APIs from a high-level strategic point-of-view. After that, I’ll move to a product-oriented perspective and describe our approach to building the API.

Using APIs to Leverage Scale

Building an API is about more than adding a new feature. It is about opening new revenue streams for Kaunt and our partners, about moving from direct sales to indirect sales, and about supporting non-dominant ERP-systems and customer-specific workflows. Some people refer to the financial aspect of APIs as The API Economy.

Companies such as Stripe have an API as their main product. They provide lots of other companies and products with their service without being responsible for the end-users. Such an approach is extremely scalable since there is a gearing between Stripe and the end-users, namely all the companies that need payment systems.

Similarly, we can scale Kaunt to far more ERP-systems than we would be able to ourselves by providing ERP-partners and customers with an API that exposes our AI service. Over the years, we have found a large variability in workflow systems and ERP configurations, and the only way we can support all of them is to hand-over the responsibility of building ERP integrations to partners and customers. Enterprise customers with very specific custom workflows can integrate Kaunt exactly where it creates value for them, while medium-sized businesses can use a generic ERP-extension built by a third-party partner.

There are several examples of companies using APIs to leverage scale. One is the API transition by TomTom, presented in a case study in the APIs@Scale report by BCG Platinion:

By allowing its partners and customers to bring the TomTom products inside of their own applications, TomTom has expanded the scale of possible markets exponentially.

Hopefully, we will see similar effects in Kaunt as a result of our public APIs. However, such results will not come without prioritizing the developer experience. In the next section, I will describe how we approached this task at Kaunt.

Treating APIs as Any Other Product Feature

As a software engineer, I tend to have the expectation that SaaS-companies expose their services via APIs. However, building and maintaining a good API is no simple task, and to succeed, an API must be considered part of the product similar to any other feature. It should be present in the roadmap and go through design phases. There are two important differences between a "normal" feature and an API, though. The most obvious difference is that the target group is software developers and technical managers rather than non-technical end-users. The second difference is that an API must be backward compatible, as software will depend on it to work correctly. Once the API is live, changes have to be carefully considered so they don't break things.

Before starting out on building the API, we reviewed the annual State of The API report by Postman. This report summarizes several findings regarding development, implementation, and adoption of APIs. The main take-away for us was the list of “Main obstacle to consuming APIs”. After all, the last thing we wanted at Kaunt was that our API ended up unused. The following items were the top three obstacles according to the report:

1. Lack of Documentation
2. Difficulty in discovering APIs
3. Lack of Knowledge

One can argue that all these items can be mitigated with great documentation and a good design. In many ways, this is no different from any other product feature targeted non-technical end-users. Likewise, we must treat developers as we treat any other user, and we should invest our UX resources into what some people call Developer Experience (DX), i.e., the documentation pages, API portals etc.

Again, I would like to refer to the TomTom API success story from the APIs@Scale report, which describes this specific approach as being key to their API success:

It’s all part of a mission to design a developer journey similar to how TomTom might have previously considered a customer journey when it was a manufacturer.

To make sure our documentation is clear, and that our API is simple to use for its future users - yet able to represent all important use-cases - we have been co-creating the API together with some of the largest Danish ERP partners and new customers from the beginning. To ensure a fast iteration cycle, we sent our API documentation long before the implementation was complete. After all, it is much faster to change a textual document than an entire database schema! The feedback we had from our founding customers has been extremely valuable and they have been a big part in shaping the API.

Besides documenting the technical parts of the API, we have also found it very important to document non-technical aspects. Over the years, where we have been building ERP-integrations ourselves, we have discovered the importance of integrating Kaunt at the right steps in the user workflow. The value creation of Kaunt greatly depends on this, and it is important to document our suggested integrations, as it is obviously in our interest that all customers get as much value as possible from Kaunt.

Summing Up

Building a good API is no easy task, but by doing it right, it can leverage growth and drive new business models and revenue streams. Whether an API will be succesful depends on several factors, including timing, business strategy, and of course execution (product management and implementation). Although these differ from case to case, I would like to end this article with a list of our most important learning from building an API for Kaunt:

• APIs usually belong to the scale phase and should initially be kept private. Having APIs tend to reduce agility, so to allow for fast iteration in the product/market fit phase of a startup, own as much of the stack as possible (e.g. own external integrations – as a bonus, you will gain knowledge which will be really useful when time is right for building an API)
• Share API documentation with customers before building the API to understand implementation complexity, documentation quality, and data model design. Make the documentation look as if the API is a finished and polished product even if it does not exist. It is much faster and cheaper to iterate over the documentation than the implementation.
• Prioritize developer experience when creating APIs. Engage the product team in the API design and development as with any other user-facing feature.
• The data model is the most difficult part of building an API. To quote Albert Einstein, keep it as simple as possible but no simpler. Try to support all relevant use-cases with as simple a model as possible - collaborating customers are extremely useful for this.

‍