The Many Paths to an MVP are Fraught with Buzzwords
With the explosion of no-code tools, the non-technical founder, as well as the discerning and optimizing founder looking at a Minimal Viable Product (MVP) and beyond, have great options to choose from. Typically, some strong form of lock-in is involved, while on the other hand, the leading solutions continue to augment the extensibility and scalability.
Often, for a newly formed startup, minimal tools, such as email, Notion and Airtable, will be enough to realize an MVP, and will be the best choice before throwing money at a potential solution. Here are a some of the document-centric solutions used to build web apps:
When a deeper MVP is needed, there are solutions like the highly popular Bubble.io and new y-combinator upstart, WeWeb. Without a doubt, MVPs built with the first group of document-centric no-code solutions will need a post-validation rewrite, but with much more clarity at this point. And for no-code tools like Bubble.io, it’s possible the resulting app will continue to be applicable for a good while after validation. A more definite advantage is the opportunity to leverage well tested component integrations. A small selection of no-code (and low-code) solutions follow:
These new tools can take time to pick up, so much so that one can find trainings lasting several weeks to develop the requisite proficiency and understand the trade-offs and workarounds involved. There are several agencies available with trained no-code experts ready to realize your application. As one could imagine, the timeline is much, much shorter than what you’d typically expect to have it developed by programmer consultants.
Regardless, so many will still feel the necessity to employ software engineering to develop the MVP, whether due to strict requirements around the mobile experience or due to more exacting implementations. At this point, outsourcing and in-house development becomes the next decision point. Post-validation, there is hardly a guarantee that a re-write won’t still be required, but typically, that is not the case. In cases where a re-write is still needed, it may be regarded to have been worthwhile when the alternative approaches were deemed not feasible in the first place.
Other decision points emerge when opting to engineer a solution—on premise vs cloud, and in the cloud case, serverless or serverful. Next comes the question of tech stack along with a myriad of other architectural decisions. The tech stacks typically revolve some form of Model-View-Controller database-driven architecture. There are some other approaches that warrant consideration and include some combinations of Domain-Driven Design (DDD), Microservices and Actor Model, though apart from DDD, the others would typically be seen as antithetical to the spirit of an MVP. It helps to separate how much of the product goes into the MVP vs how involved the implementation is, as well as consider that with some of the available frameworks, a lot of the complexity is mitigated by the system and that.
Before taking those on, it helps to consider the Lean Methodology that informs so much product development and engineering effort. The Minimal Viable Product is all about carving out just the right chunk of experience to determine whether the application’s aim to delight the user is on target. When we consider DDD, it is about getting to the essence of the domain. That should really be understood before carving out a chunk of experience to test the user, because as Tim Meeuwissen says here:
You need help to make things small, discover all aspects of the problem and apply validated learning over the most valuable parts of the hypothesis. You need to know which are the right things to build to get the biggest bang for your buck.
A fully fleshed out domain provides a schemata for product management and software engineering functions and delineates the essential complexity for the solution domain. VLINGO’s XOOM platform and AxonIQ go as far as providing DDD at its foundations along with microservices. Microservices are a useful discussion point with respect to Lean Methodology, because when done correctly, they can provide optimal, lean solutions by componentizing the essential services with light-weight implementations that can be composed within the microservice-based architecture. Along with VLINGO, Eventuate and AxonIQ are leading solutions here.
The Actor Model is also very relevant to Lean Methodology and DDD, because it incorporates distributed stateful processing in a natural way for identified components. The only way to affect state in these components is to send them messages from other actors and APIs. This restriction helps keep the architecture detangled aside from the parallel computation gains. The first solution that comes to mind regarding actors is Erlang/OTP, which employed for many years in mission-critical, fault-tolerant implementations for the Telecom industry. Akka, Swim.ai and Microsoft’s Orleans are other Actor systems worth checking out. It should be noted the Actor Model is orthogonal to microservices, and the two can leveraged together, as with VLINGO, which provides a type-safe Actor Model. Below are some notable representations of microservice and actor frameworks:
As can be seen, we have gone from no-code and low-code to microservice and actor systems. Here I’ll mention that VLINGO offers XOOM Designer, which to borrow their words:
The VLINGO XOOM Designer to guide you in rapid delivery of low-code to full-code Reactive, Event-Driven Microservices and Applications using DOMA, DDD, and other approaches. -- https://github.com/vlingo/xoom-designer
Appmancy comes to this discussion with an affirmative yes, let’s specify the system without the code, but also, let’s push back on mobile and web UX initially, along with all the layout labor that is entailed, and instead, take a conversational approach to app backend building that will also generate efficient reference templates for UX along with the backend code. Furthermore, Appmancy pushes its “MVPs with a Future” mandate that seeks to minimize vendor lock-in and prefer open-source as much as possible. In the meantime, when generating against proprietary cloud platforms, there should be a means to target as many of those platforms as is feasible and to provide automated migration to the various proprietary clouds and on-premise containerizations, as well as the ability to auto-migrate the application in response to pivots or simple schema migrations. Appmancy is at an early stage and currently generates applications for AWS with NodeJS and NuxtJS, making use of Lambdas and Serverless where appropriate. The UX will be evolving, but you can try it today: