Introduction
A team of talented individuals embarks on a journey to build something cool for the rest of their colleagues to help them in day to day life at the office. This bright idea of a super powerful, social-network-like app for company employees emerged. User flows are quickly sketched out, dozens of features planned, technical diagrams are drawn, we had it all figured out and were super motivated to start. On top of that, we'll build it and host it ourselves on some VMs on premise!
You may have guessed - it didn't see the light of day.
In this blog post, I'll share why this approach failed and how, in a second attempt and by adopting AWS and Serverless helped us successfully develop and deploy a functioning MVP on a limited time and budget.
The First Attempt: A Lesson in Complexity
One piece is missing and that's IoT Core, but I just wanted to use
This was especially important as we knew our time to work on this project is quite limited - new assignments in the company were looming around the corner.
User Feedback Or Where Are The Emojis And Reactions?
We are building something for our colleagues, for internal use, basically solving our own problems, and that gives us good insight in which features we need to build first, right? Surprisingly, the feedback from every single person from our first group of pilot users was that the chat needed to be richer, more precisely to support emojis and emoji reactions on messages. On the other hand, people are really used to rich chat features, since they have them in every actual chat app. Even if it wasn't considered crucial from our point of view, we realized that missing this could lower the chances of anyone using our app. It was the first thing on our backlog the following week.
So, we missed an important feature, but the fast feedback enabled by our cloud powered development setup makes it easy for us to quickly iterate and add the missing value.
Next Steps: Preparing for Production
We are still working on a few quick wins that our first group of users suggested, while aiming to tighten a few more knots before we open the app to all users. Currently, it's deployable and we believe it is functionally OK, so next step is validating that it's secure, reliable and performant.
Security will be checked by penetration testing and to make sure the app is reliable and that we spot any performance bottlenecks quickly, we've setup CloudWatch monitoring dashboards and alarms. Having an overview of metrics like number of API requests, latency, error count, and alarms on any server error enables us to react pro-actively. AWS makes this fairly trivial compared to what we'd have to do if we were running this on-prem.
Conclusion
This story is an example of how AWS and its Serverless services can save time and resources when building under constraints. Apart from that, it touches the subject of scope-creep and the importance of keeping it under control when building an MVP. Also, discussing the steps to take after, like ramping up security and considering ways to measure the general quality and success of the product as it evolves.
Not to get ahead of ourselves - we still have some work to do before we can think about measuring if the product is successful. However, for things like basic monitoring, alarming and automation - AWS makes this ridiculously easy to do that it's a no-brainer.
SOCIAL SHARE CARD GENERATOR