Beno Rudolf
Early-stage Product Tech Lead at d.labs
Rapid application development has always been burdened by assumptions of unmaintainable and unscalable output. Rightfully so; cutting corners and fast pace are risky in engineering and too soon do errors start to pile up and refactoring discussions begin.
Web applications, however, come in a much more flexible environment and cater better to agile approaches. Lean, agile, and similar methods have all been created mostly around web-based products and while there is a continuous stream of resources regarding the whole product development process, the engineering seems to remain the oxymoronic obese bottleneck that prevents many products from receiving a fair validation. Early-stage products, MVPs if you will, should not be condemned to being fully fleshed out behemoths but should act more as a sort of medium for learning more about the problems, solutions, and users you are trying to help. Through iteration, the software must remain adaptive and lean to be able to maintain this stream of information.
At d.labs we know that most products have a much higher chance of being unsuccessful when companies burn all their money on development and ignore any kind of validation. Realising this we created our RAID and RECON services which provide highly efficient execution and data-driven product shaping respectfully, keeping the focus on learning and costs in control. Specifically, the RAID service was created based on being able to produce a minimal viable product in less than 10 days. Yes, less than 10 days.
We also had great success with this approach when we built LineScouts; a d.labs product that was created literally over the weekend.
Throughout these endeavours we've learned what are some of the things that can immensely help with efficiently building very agile products.
Discover, embrace, and adopt cloud-based solutions. The plethora of available tools is quite frankly impossible to keep track of and some will, without exaggeration, reduce your development resources to a single developer. Tools like Google's Firebase and Amazon's Amplify offer full infrastructure as a service for an absurdly low cost. Building something as complex would take months and probably burn the development budget halfway. Granted, you might not need all that functionality but it actually makes your software much more agile as you can quickly create any kind of feature that you've validated as needed or just want to learn more from it. As these are mostly convenience interfaces for Google and Amazon's individual services it means the software can easily be extended. Does it scale? Please.
The two giants are not the only players offering viable solutions. There are many that offer easy to set up and scalable infrastructures such as Netlify and Render, or if you require more fidelity, Hasura. A lot of these services offer serverless solutions, the explanation of which surpasses the scope of this article, but in short offer much easier composition and consequently agility.
These are just a couple, and might not even be completely comparable, but the key takeaway is you have a lot of affordable infrastructure available which you can set up and change quickly.
Another important technical aspect to embrace is integrating with other services that provide more distinct solutions e.g. analytics, messaging, content management, file storage or processing, machine learning, scheduling, etc. Providers can have years of experience in the specific domain and trying to replace that with custom solutions that can be feeble. There are however diminishing returns to consider as delegating too much to third parties will start to increase rigidity. Far from an exact science, as is all software engineering thankfully, considerations need to be made. Being comfortable juggling these services will make it much easier. Again, favour agility, not features, and keep the integration code decoupled as much as possible to allow a smooth provider change if needed.
Integrating different services does require time as each has its own implementation details, so if you're relying on many providers favour a service like Zapier that streamlines the process.
Recently there has been a surge of low-code and no-code tools. Some of the tools mentioned probably fall into the low-code category. The low-code category is in my opinion the optimal of the two as it saves time with repeated and mundane tasks while still allowing specific actions and options via actual code. The no-code tools, as the name suggests, mostly use a graphical interface that can allow the creation of not just user interfaces but whole data flows. As history has told us these kinds of solutions can hit limits very fast. However, their efficiency is much more appreciated when creating internal tools e.g. administration and when prototyping. Definitely worth the consideration.
What about team composition? The overall composition will always be based on what is being built and who are the best people to work on it. However, piggybacking on all these solutions does decrease the engineering resource need. As mentioned, some services can easily lower this need to a single person and that is mostly the case. In such a setting multiple developers do not directly increase the velocity unless the project includes multiple distinct products or segments that can be worked on independently.
One of the most important things needed for this to be optimal is empowering your engineers. Empowered engineering deserves its own blog post (hint, hint), but essentially it comes down to having an experienced, highly autonomous, broad scoped and mostly product-focused engineer. Experience is needed as they can anticipate and abstract better thus producing more agile solutions, while the given autonomy allows them to make the best decisions with their expertise in the field. Couple that with a broad knowledge of available technical solutions while always being product-centric and you have a person that will break the engineering bottleneck. Please excuse the hubris.
At this point you might be thinking this all sounds great but don't all the services add up to a large monthly cost and you're still paying for the team to glue everything together?
Short answer: no, relative to the cost of a custom solution with a larger team and wasted time.
More than the cost itself, with a custom solution you are losing valuable time and effort on execution when you could be using that time for learning, validation, and consequently iteration.
A quick and somewhat dirty number comparison is self-evident; a team member costs on average 6.6k euros per month and infrastructure roughly 40 euros per month for a single service. With a 5 member team (3 engineers) and 2 services, building your custom MVP for 2 months comes to around 66k. With that burnt, you've only just started validating and since the solution is probably rigid - otherwise it would take more time to build - you're looking at every iteration taking 10 days, costing an additional 15k. So at 80k and almost 3 months in you haven’t iterated once, probably learned very little about your product or your customers and have a costly foundation for every change you make. Nearing 100k, marketing hasn't even been mentioned. Hitting the nail in the coffin, most of these numbers (cost and time) are probably too low.
Comparing this to a leaner approach you can easily remove 2 engineers, use about 5 services, and a timeline of 10 days and you've built your product for around 9k. At this point, you can start learning and iterating, and as the infrastructure is very agile every iteration takes 3 days, costing around 3k. At 66k you've done around 18 iterations of the product and hopefully gathered so much knowledge you're essentially a unicorn ranch.
All that said, it is crucial to remember that great custom engineering solutions remain marvels and should be respected in every way. There are not many things in the world comparable to an engineer's will and passion to create and surpass themselves each time. Unfortunately, a lot of these feats become rusting rocket ships on bicycle lanes due to bad decisions that were made.
To rephrase Steve Blank, instead of focusing on execution, focus on learning so you'll get to the point where you know what to execute. There is far more motivation in creating something you know has a purpose.
The COVID-19 situation has fast-forwarded us to a farther digital age and there will be an increasing need for more digital solutions that improve our future lives. While we have already optimised most of the product development process, engineering should follow so we no longer fail to deliver on those potential solutions.
Want to chat more about how we can help you scale your tech venture? Get in touch at sales@dlabs.io.
.png)
