Makings of a Katana

KatanaMRP engine
Here’s Katana’s product engineering story, which began in April 2017. It started with our bet on the fact that the future is SaaS and tailored ERP ecosystems.

This write-up sheds light on the technological choices of Katana.

When our product engineering story began April 2017, a few ground rules had to be established between Kristjan and myself regarding how we are going to build it…

…the criteria for decision making had to be defined.

Our Bet: The Future is SaaS and Tailored ERP Ecosystems

Our bet for the future and choices of technology relies on these key predictions (some of it has already become a reality): manufacturers are not interested in wrestling IT challenges, they want to focus and succeed as manufacturers.

Building their own IT infrastructure, platform and software will be the end of them.

Since the beginning of our mission to find scaling manufacturers manufacturers growing out of Excel, we discovered that standard terminology and abbreviations like ERP, MES and MRP sound too big for them, and to find the transition point from "making and crafting" into "manufacturing" requires describing it as a production planning software combined with inventory / warehouse management.

Also, there is no single ERP for your manufacturing plant, fitting like a glove.

As the complexity and the number of tools grow, instead of choosing the least uncomfortable solution, today's IT investment will go into choosing an iPaaS (such as, SnapLogic etc) and identity service (such as onelogin, Bitium etc)

Katana wants to be the best choice for modern manufacturers, and MRP software focusing solely on excelling at manufacturing while allowing other key capabilities to be integrated with other ERP services. 

Derived from above, the following goals and objectives were set to Katana engineering team:

Katana — Smart Manufacturing Software for manufacturers

Sustainable Low Cycle Time of Implementing Product Changes

To be able to deliver our product quickly we had set this KPI early to embed it into our DNA. 

It has to apply to bigger changes as well: the ability to split them into parallel work streams without getting into dependency management hell.

Luckily for us, the choices above deliver additional benefits to our product, such as:

  • Increasing it's longevity;

  • Flexibility; and

  • Scalability.

Focus on Building MRP/MES Product

When building a SaaS product one has to make use of things already done, offload as much devops and database work as possible.


On backbone we made use of:

More technologies have been listed on Stackshare.

Low Cost to Acquire and Retain Customers

Another important metrics for engineering to take into account for service design.

Our current target is set to be

less than 1€ per month per customer organization

with the help of

  • using microservices architecture style;

  • integrating third party services with fitting usage tiers; and

  • multitenancy.

Our product is built on independently tiered and priced services and applications which vary from free to up to 200€ per month. 

The metrics and criteria might change in the future, but it is still important for the engineering team to know what handles are there in the system to scale it's part and what is the cost of different performance / capacity tiers.