Building Accelerator Platforms

This all started about 14 months ago when we tasked ourselves to go out and start learning a new technology so we decided it was time to start building our own accelerator platform using a new underlying technology. The approach that we have taken does not make any technology or approach a requirement as everything should be interchangeable which made for us learning a new tech a perfect candidate to build this around.

We have been building these types of apps professionally now for over 10+ years so we already had the vision of what we wanted to achieve, we just needed to start with defining the approach and our objectives. Our objectives are to be able to take this platform and after a small refactor, building out business logic for the new product within a day since all of the underlying plumbing, design patterns, tech stacks, data models, etc. have already been developed and field tested.

For the initial project, we decided to use the following technology stacks:

  • Vue 3
  • Naive UI Toolkit
  • .Net Api
  • MongoDb
  • .Net Maui (iOS, Android & Windows Desktop platforms)
  • Azure Dev-ops (CI/CD)
  • Azure Cloud (App Services, Storage Queue, Storage accounts, etc.)

This platform will in no way, shape or form be bound to the starting tech defined above as we will be following this up with a Java API, React Native Mobile platform, etc.. The starting platforms are simply building out the core product and product specs that all platforms will conform to.

So here is the idea for how all of this works, starting from the 1,000 foot view of the vision. The idea is that we can build out virtually any idea using this platform and load it into any cloud environment. We are able to pick and choose the User Engagement tech stack and the backend/cloud stacks to fit the needs of the idea.

We are able to easily do this because we have already built out the plumbing of the accelerators to be agnostic of their environments and products that the must interact with to create a fully functional system.

In order to make this work, we came up with a set of common specs that each technology stack adheres to so-as that they all work in harmony. The scope of the common specs is somewhat small but that is by design; the purpose of this is to ensure that the core operations are in sync where-as business logic for the product are not constrained by this concept.

The illustration above demonstrates how we are able to continue to expand on this concept without having to re-develop the entire system, rather just the missing piece. Currently I have just a Vue front end but am working on the Angular version as we speak. This gives us the ability to quickly turn these products around because I already have a field tested set of specs and only have to build the UI.

Building onto this platform is easy now that the foundation is there however that is not where the big win is for me. The biggest advantage this gives me is how I built each component. I built each component in a way that I can replicate the product within an hour and am ready to start building this out with a new idea in mind. This is the problem that we were originally attempting to solve; not being able to pursue great ideas because I never had the time to build out a proper foundation. Now we can start coding business logic on day 1 against a solid, field tested foundation rather than day 30+ against a foundation that was rushed.