You’ve read about the story behind Apio and Mark and Sam gave us the deep dive into how this product came to be, as well as a preview of the future roadmap.
With the previous setup that we had, any small change required a developer and once you’d built the base or main framework of an integration, say you wanted to pull a different field, you’d have to specify that back to a developer.
Now with Apio, you don’t need to be that technical, you can solve the issue like pushing the field through without needing a developer. A solutions consultant or engineer would easily be able to do that.
We spent a lot of time looking at what was out there and a lot of solutions were good, but we felt the pricing was not justifiable for what they were doing. The pricing was very complicated and they were trying to solve everything - be all things for all people, which added to the complexity, but didn’t tick all the right boxes. We also had a clear idea for the visualisation and what we wanted to see when we logged in and how we wanted that represented back to us and we didn’t find a solution that we liked that was affordable. We wanted to build something focused on just ecommerce and that allowed us to build exactly what we wanted and without having to worry about use cases outside of our focus, i. e. a much simpler system.
“I would argue that the best programming solutions are simple and elegant and Apio definitely is.” - Mark, CEO of Apio
What that meant for us is we wanted to find a pricing strategy that isn’t prohibitive - i. e. only for SME or enterprise. We think you should pay for scale and volume and features should be opened up. What tends to happen is enterprise products have more features and they sell their solution based on more features, and I felt strongly that this isn’t the route we want to go. If you're an enterprise company, you’re putting through a lot more volume and scale and our aim is for you and everyone else to pay for the resource you are using. If you have a small business, why should you be limited if you need some particular functionality, if that’s cost prohibitive and impacts your business? We’ve tried to put together a strategy that enables the smallest and largest businesses to leverage the software in the best way that works for them - see our pricing philosophy for more details.
We’ve changed the way the integration platform works compared to other solutions. A lot of integrations work in slightly different ways, depending on what the use case is and what we’ve done is completely re-thought how that works, so we aren’t working with connectors, but will instead have recipes and host these in a library. We will have an open source library of solutions that you’ll be able to access. Any time you create an integration, you’ll be able to publish it to the library and make that available to anyone to download and look at how you’ve done an integration. Over time there should be thousands of different ways on how you’ve integrated i. e. Magento to SAP or Sage or to Netsuite or any other system. There will be lots of ways that people have found to save time and build on efficiencies and efficient solutions. Lots of reusable recipes that will benefit the whole ecosystem and provide ultimate flexibility because you can make it do whatever you want. The recipe builder is in beta right now and is launching fully in early Q4.
We also have an interface builder which is continually evolving. Scratch is a good way to describe how it works. Scratch is a visual programming language that is used a lot in education and teaching children how to program and the logic is very visual with a lot of drag and drop. That has been part of our inspiration and gives the retailer complete flexibility and isn’t too rigid. It allows you to perform actions like adding simple logic, combining multiple data sources and merging them into one.
We’re not sure if this will be a big thing, but it’s certainly different to how other data platforms do it. Using it is great, it makes it very easy to create recipes and build integrations. We’re already looking forward to seeing what problems people solve, how they’ll use it and what recipes they’ll build.
Our main takeaways for the launch are to provide visibility of what’s going on and make the integrations easier and quicker to do - which is this current version. Version 2 is how we expand that and how we can turn Apio into a central hub, connecting lots of systems. That will allow us to focus on microservices and build out more of these like a stock module (order routing, stock arriving and providing all the information the front end might need, triggering out communications when things are delayed, routing orders to the right warehouse, etc). This is an area that we’d like us to look at, as an add-on. We’ll be taking on small focused areas and working on solving one problem very well, rather than big complex projects. Another area is data analytics with regards to all the data passing through the system, allowing retailers to be able to report and interpret it, which could mean either building this out or integrating with a reporting or business intelligence tool.
Closing Remarks: That was part two on the story behind Apio, ready to give it a go? Get Started