Katana is an MRP Software catering to the needs of manufacturing businesses both small and large. The sweet spot of a client for Katana is a small to medium-sized producer that is currently managing its processes in a semi-manual manner but would be ready to transfer onto a software solution that is adaptable to their needs and does not break the bank account.
Katana MRP has been using PDF Generator API since 2019 already, which makes them a prime target for yet another case study. To dig into their specific use case and the reasons for choosing PDF Generator API, we spoke with Priit Kaasik, CTO.
When making a decision on whether to buy a solution-as-a-service or build it in-house – what are the key criteria for Katana? Could you describe the decision-making process a bit?
For many starting businesses that choice is simple – starting out with 3 developers back in 2017, we simply did not have the resources in-house to develop something like this and when resources are scarce, the obvious decision is to buy. So the decision that has to be made is not whether to buy, but rather which solution to buy.
The same logic applied to any solution that wasn’t a part of our core business. In our case, anything that is related to planning or resource management falls under our core business and is developed in-house. The rest we buy as a service. A good example here could be user management where we use Okta to handle all the signup flow and related processes.
On a strategic level, we have made a decision to use best-in-class solutions already available on the market and use our own resources only to integrate those into our everyday operations. That way we are able to focus on our own strengths and core business which, at the end of the day, is after all production.
On a strategic level, we have made a decision to use best-in-class solutions already available on the market and use our own resources only to integrate those into our everyday operations. That way we are able to focus on our own strengths and core business which, at the end of the day, is after all production.
Priit Kaasik
How did you come across PDF Generator API?
We were looking for a solution to handle our document generation workflows and came across PDF Generator API. Your solution supported most of the functionality we were looking for, and the initial interaction with you was constructive from the start, so the decision to jump on board came relatively fast.
The discovery that both of our businesses are also based in Estonia just helped to cement the deal.
Which functionality did you miss most when you transferred to using PDF Generator API?
There was obviously some functionality we would have liked to have, but considering that we operate in a niche market, having those available out of the box would have been a bit far-fetched.
What we can do as a service provider is to offer our clients only the best possible solutions for their needs. So whenever a client uses an integration we offer, they can be sure that it has been through a rigorous validation process and we are putting our seal of approval on it. No sub-par integration will pass through.
Priit Kaasik
How large is your development team at Katana?
Today we are about 30 people, so we have grown 10 fold since we started. And we are currently looking for 20 more by the end of the year. The team has the freedom to work from a distance as long as they are able to come to Tallinn for any face-to-face meeting a few times a month. We would like to keep some of the benefits of meeting face-to-face every once in a while. That also makes recruitment somewhat easier in this day and age.
How does Katana approach the process of buying software-as-a-service – who initiates the search for a solution and who makes the final decision?
We run a mostly bottom-up process with external services. The proposal comes from the teams, but I am always the final approver. So whenever we need a solution, someone will run a wide sweep of the market to pinpoint suitable solutions, and only in the case where none are available, we resort to building something in-house.
In the overwhelming majority of cases, somebody has already put in the resource and developed a world-class solution to solve a specific issue, so committing our own resources would be just plain stupid.
Priit Kaasik
But isn´t there a risk that if one of those external solutions falls down, your entire product will be on its knees? The putting all your eggs in one basket analogy?
That is why I as CTO always run my own signature “service health” checks. Whenever we are considering an external solution, I do my due diligence and try to find out who the people behind it are, how big the community is, try to find out about the installation base and release practices. I use the service health metric to determine whether the solution is growing and developing, stable, or showing signs of decline already. You could probably summarize with the term “maturity”.
Another integral factor is communication flow – will the service provider assign a dedicated person to handle our account, how quickly are our concerns addressed, or what type of communication style does the company you in general. That was also something where PDF Generator API stood out.
What type of monitoring do you use to check service health with your various service providers?
That is one of our requirements whenever we procure new services – the potential service provider would need to be able to give us that information in the form of an RSS feed or similar, which we will then integrate into our own monitoring solution. All communication related to uptime, maintenance windows, and release schedules is pulled into our common service alerts system.
Who was responsible for the actual integration work – who was involved?
I built the first prototype of Katana that was in line with our general approach to using microservices. We employ what I would call an anti-monolith approach at Katana. We want to make sure that all the services are scalable and replaceable if needed without any impact on other parts of the system.
I was the one that designed the initial integration flow and create blueprints on how services should interact with each other and what are the dependencies. The actual integration with PDF Generator API was built by the backend team.
How easy-to-grasp was our documentation?
This speeds up the integration process for us. The documentation was easily understandable, and the request examples helped a lot. We use Loopback to automatically generate models based on the API documentation and publish REST API for internal use.
How long did the entire implementation process take?
It took a couple of days to develop the first working prototype and then a week to go through our regular testing process and release it to staging. All-in-all, the process took less than a month from beginning to end.
These past years or so have seen a shift in customer buying behavior – 10 years ago a software product was expected to do everything out-of-the-box. Now we see a more modular approach where the final solution is put together from best-in-class components. How do you see this development in your own target markets?
I agree. What we can do as a service provider is to offer our clients only the best possible solutions for their needs. So whenever a client uses an integration we offer, they can be sure that it has been through a rigorous validation process, and we are putting our seal of approval on it. No sub-par integration will pass through.
As you can see, PDF Generator API is truly a flexible product that adapts to the needs and requirements of its customers, regardless of the sector – independent of whether it is implemented on top of an existing stack or used as a building block for something entirely new. We hope these case studies will help anyone interested in ways to utilize PDF Generator API to further their own business to gain insights, examples and best practices in making the most out of the tool.
