Makings of a Katana

 Katana MRP technological choices

This write-up shares light on technological choices of Katana MRP. 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 small 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 production planning and 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 elastic.io, SnapLogic etc) and identity service (such as onelogin, Bitium etc)

Katana MRP wants to be the best choice for small manufacturers, 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:

Looking to organize your inventory and production? Try Katana MRP for free!

Click here and sign up for free!

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, 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.

Backbone

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 organisation

with the help of

  • using microservices architecture style
  • integrating 3rd party services with fitting usage tiers
  • 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.