Maintaining Ashiba
Ashiba is our composable commerce accelerator. It is the foundation of our successful projects allowing project teams to get up and running quickly and focusing on our client's unique differentiators instead of repeating core commerce functionality such as a cart everyone has.
The core change we face maintaining Ashiba is balance. Balancing keeping Ashiba specific enough to provide real, tangible value but generic enough to be applicable to all customers. Balance ensuring we invest enough time in our own internal product but also as a digital agency having full teams delivering client projects and helping them achieve their business goals. Balance empowering developers with the freedom to try new and exciting technologies, but also not waste time chasing the newest fad.
Ashiba was built to be an accelerator for all businesses on their commerce platform of choice. It needs to be specific enough to provide great value to clients and accelerate rollout while being generic enough that it covers a vast amount of clients.
Our product owner Dan is always keeping up to date with the latest trends and new releases to stay ahead of the curve and be confident we have the technology answers when customers come to Cabiri. He is responsible for keeping a pulse on upcoming developments and evaluating ideas identified from outside sources but also the team - everyone’s voice is welcome and we thrive on everyone being able to contribute to making Ashiba something they believe in.
Everyone in the team is aware of and invested in keeping Ashiba relevant. They are constantly on the lookout for common functionality and patterns identifiable across customers that should be included in Ashiba and are needed in a generic way. This is the most organic way we contribute to Ashiba.
Something we’ve identified during delivery and upcoming trends and customer enthusiasm is POS (Point Of Sale). Nothing limits businesses from moving away from antiquated POS solutions with coordinated maintenance events and moving towards applications that can be updated over the cloud and seamlessly integrate with the rest of your composable commerce ecosystem to provide a single view or orders, customers and experience.
This can, of course, come with its challenges, it is difficult knowing when to stop as we want a full-blown solution but with Acceptance Criteria defined upfront and regular check-ins, we do our best to mitigate this and retrospective reviews of features allow us to tapered them back if needed.
Another recent no-brainer for us was extending Ashiba to support Native apps in addition to web-browser. This was born out of numerous conversations with clients wanting to develop their apps as part of a client-centric shift in focus across all channels in both iOS and Android. It's always been something we’ve had the skillset to complete and have worked on but hadn’t been given the space to be brought into the fold and this also enabled us to form a solid opinion on the question- Native or React Native?
When we’re actively putting a focus on Ashiba we like to ensure that there's a team around to support each other and manage it as a mini-project. What this looks like at a minimum is a Project manager, Test Engineer, pair of developers and someone wearing the Product Owner/ Business Analyst who has the ability to make decisions.
The beauty of Ashiba is that everyone within Cabiri has had an impact in one way or another. We rotate people on the project ensuring everyone contributes and is able to bring their own unique skillset and perspective. This can also be a great tool to help with burnout. It’s a moment of calm allowing developers to slow down after a challenging project or project with strict timelines and work on something they’re passionate about with the brief - New technology that we think would benefit the composable space or enhance the developer experience such as adding TypeScript-first schema declaration and validation library.
In addition to allocating team members to 100% focus on improving Ashiba there is a natural stage at the end of a project before moving on to reflect. Is there any functionality we have found of use during a project that we see value in recreating in Ashiba? Are there any lessons learned we could use moving forwards?
Sometimes our new improvements take indirect routes coming out of an investigation into something unrelated. We recently revamped how the frontend is hosted and delivered, moving from server-side rendering to static-site generation. This brought us the expected and realised benefit of improved performance, a key factor in increased conversion rates. This was born out of our explorations into commercelayer an up-and-coming composable commerce engine that we thought brought a great benefit and also allowed us to make sure our system-agnostic accelerator was just that, agnostic.
Ashiba has proven to be a successful composable commerce accelerator that has allowed project teams to get up and running quickly, enabling us to focus on our client's unique differentiators instead of repeating core commerce functionality. Maintaining Ashiba has required a constant balance between specificity and generality, investing enough time in the product, and delivering client projects. The team is always on the lookout for common functionality and patterns that should be included in Ashiba, ensuring its relevance and value to clients. Ashiba's success is a result of the team's dedication to creating a product that is system-agnostic, relevant, and provides value to all customers on their commerce platform of choice.
