In the last article, we looked at what AWS programs offer startups. Today our focus will shift to how a startup can properly build an MVP on AWS and the conceptual stuff that is the AWS Core Foundation.

...

What’s an MVP?

MVP is a product that you can enter the market with. It consists of three simple concepts: Minimal-Viable-Product.

First of all, Minimal means a product that contains the minimum number of necessary features, but at the same time it is not a PoC (Proof-of-Concept, or a Proof of Concept — Startup Jedi) or a sketch, but a product that can work from start to end and attract users.

Viable means the product can live. But it is also assumed that this is a usable product, that is, it can already be used, loveable — the first users of the product will love it, testable — it can be tested.

The real Minimum Viable Product is when you started by building a skateboard, then worked it up to a scooter, then a bicycle, then a motorcycle, and you ended up building a car. This is the natural evolutionary path for building a product.

It is appropriate to mention Reid Hoffman, co-founder of LinkedIn, who said: “If you are not embarrassed by the first version of your product, you’ve launched too late”. And this is very much so, there is no perfect product, you always need to work on the product and constantly refine it.

...

MVP creation process

If we are talking about development iterations, then the first version of your product can be far from perfect, but it has to be something you can show to the user. To do this, it must go through a whole life cycle: from registration to receiving the result. It shouldn’t be a small prototype that solves one business function without a complete environment.

Product iterations that you will use to improve it after receiving feedback from users each time is an important path any startup goes through. And such iterations, or sprints, must be integral and complete, so that at the end of the sprint, a complete feature or complete functionality is issued that can be applied and delivered to users.

Iterations also need to be continuous and short — it doesn’t make sense to develop something for 6 months without realizing if users need it.

What is important to remember when planning your iterations?

Planning

If we think of planning as a graph, then it has an axis of high and low influence (vertical) that is the result your users get, and the axis of slow or fast construction (horizontal) that shows the time spent on development.

These axes form 4 squares:

Distraction. If you have something that you can build quickly but it has little impact on your users, then it’s just another annoyance that distracts from building your MVP.

Focus Area. You should focus on something you can build quickly that has a big impact on your users. It’s very important.

Break Down. If you have something that will have a good effect on your users, but you cannot build it quickly, then you need to break it into several parts and deliver it to the user in parts.

Undifferentiated. If something takes a long time to build and has a low impact on your user it is best to ignore it in terms of your resource usage.

Minimize Task Size

To reduce the size of the tasks performed, it is better to break them down into smaller ones, which:

• 1–2 engineers can perform,

• Can be closed in 1 sprint,

• Add incremental value to your MVP,

• Are easy to prioritize, simplify, and make more understandable.

For example, notifications for users. The first version is a simple email message without nice formatting, as long as it is informative. The next iteration is to add markup, details, time estimate or some kind of result, and after that you can add push notification, SMS — this is the iterative process to reduce the size of tasks that need to be worked on at once.

Standups

It is very important that your entire team — from developers to tops — communicates. No matter how many of you there are on the team, 2 people or 20, it is important to sync and stay connected every day. Make communication quick and easy. Communication will add clarity to everyone as for who is working on what and what tasks are in priority, because startups are moving very quickly and the priorities you had last week may no longer be relevant this week.

Continuous delivery 

The system helps to constantly update the product with new releases and new features. The tools that AWS uses include CodeCommit, CodeBuild (continuous integration system), CodeDeploy. All of the above is converted into CodePipeline.

These are simple and easy tools that manage themselves, you do not need to subscribe to other resources or keep track of adding users. Everything is in one AWS account and you only pay for the resources that you use.

...

What is also important to consider — Core Foundations

“It is worth investing once in those things that will be very difficult to change in the future.”

Security

One of the main conceptual things when creating a product is information security.

Amazon has the concepts of “one way door” and “two ways door”. The first is when you make decisions that will be difficult to change in the future, and the second is when it is quite easy to change the decision made.

That is, if you do not invest enough in protecting your system, then in the future you can be hacked and you will lose user confidence. Therefore, it is best to set up the most optimal security from the very beginning.

Security is the very first priority on Amazon. We operate with a model called the “Divided Model for Security” when we take responsibility for the security of data centers, server equipment, the hypervisor itself or the operating system, and you are in charge of the applications that you build and deploy on our environment. We have a lot of tools you can use to keep your application secure: Amazon Cognito, Amazon CloudFront, AWS Secrets Manager, AWS Systems Manager, AWS CloudTrail, and more.

Integration Point

We have implemented documentation capabilities on the AWS platform and have extensive documentation: tutorials, videos, quick starts that you can use.

Data Model and Store

Data Model and the Data Store are difficult to invest in. We recommend that you think about choosing a database from the very beginning in order to optimize the system that you are building as simply as possible for the type of storage that you choose.

If you have chosen a relational database, while your business and your product imply connections between data, if you need transactions, then we have Aurora and RDS. If you can activate your data in order to store it in memory, then it is usually super “hot” data, session data, or others that involve working with very fast millisecond data, but in very small amounts — in this case you can use ElastiCache. If you need Key-Value in Storage or Document in Storage, then I advise you to look at DynamoDB or DocumentDB. We also have special databases: Graph, Time-series, Ledger, which are intended for very specific use cases.

There are currently more than a dozen different types of data stores on AWS, and if you have difficulties choosing one at the very early stages of creating a product, it is better to contact us for help so that you do not have any problems with re-architecture in the future.

You can watch the full video with Yegor’s presentation here:

In the next final article, we will explore Amazon Web Services cloud architecture solutions.