Quality means long? How to build viable MVPs quickly

The issue of speed and quality is particularly acute in development. We used to think that the more time was spent on product development, the better the result, and vice versa. But is it really so?

On the one hand, it seems logical that speed is achieved by refusing testing, using crutches, often having to sacrifice the purity of the architecture. Let the service be written with errors, but quickly.

On the other hand, this is a possible, but far from the only way to achieve speed in development. In this article, I will offer several options for working on an MVP that will speed up the process and get a product that can later be developed for many years.

Method 1. We reduce the capabilities of the product

The main task of an MVP, and indeed of almost any feature, is to solve some kind of client problem. Think about whether all the functionality that you have planned is really important? What can be omitted to reduce development time? What will still have to be implemented in the MVP?

And it’s not just about the obvious excesses. You can also refuse the features that are considered standard. For example, instead of supporting custom profile pictures, you can connect Gravatar or replace user registration on the site with authorization through Google.

Method 2: Reduce the number of supported platforms and variants

For example, at first you can only release a desktop application for Windows, or refuse to support images in any format – limit yourself to JPEG. I emphasize that here I do not mean product features as such (they were discussed above), but rather their technical implementation.

At the same time, provide support for future functionality, just return NotImplemented more often – in this case, you will spend less effort on development. For example:

def normalize_image(filename):
  if not filename.endswith(".jpg"):
    raise NotImplementedError()
  ...

Method 3. Simplify testing

The most obvious option is to reduce the testing time. Yes, thoroughly testing the product in this case will not work. But, perhaps, for MVP it will be enough to conduct only the necessary minimum of tests – to check the code locally and in the staging environment before release.

I highly recommend describing unit tests but not running them. Even if you just describe test cases, you can see flaws and get non-obvious insights for later manual verification. This is a great example of how you can get 80% of the result by doing 20% ​​of the work, especially in the short term. For example, this is how it looks in Jest:

test.todo("form shows error messaage for invalid credentials")

test.todo("form redirects on success login")
test.todo("redirect supports _next query param")
test.todo("_next query param validates url")

Method 4. Use a simpler architecture

You can almost always stop using three different databases, microservices or queues without any loss. BUT: it is important to separate the logic in loosely coupled parts of the application. Don’t over complicate things – most of the time, a simple division into functions or modules will suffice.

With regard to architecture, two basic rules can be identified:

  • The correctness of the architectural decisions themselves is not so important as the ability to change them later

  • The more basic a component is, the more important its quality is, and vice versa

And three more important tips:

  • Keep it simple – most product ideas will not be implemented at all, and among those that will, a large part will turn out to be non-working.

  • performance can be neglected. – Of course, you should not lay obviously inefficient solutions in the architecture, but the difference between one second and five, although noticeable, is often absolutely not important.

  • Don’t try to solve problems with libraries – they will create much more problems for you later. Worst of all, if you are trying to compensate for the lack of knowledge by installing a library (for example, for graphs). Libraries are not magic, but a tool. If you do not know at least the basic principles of their work, it is very easy to get into a dead end.

Conclusion

Remember that an MVP is as much a test of a hypothesis as it is often an initial version of a product. Therefore, when creating it, it is important to strike a balance between technical tasks and business expectations and avoid extremes. There is no need to reduce functionality too much or release code that is 100% covered by tests.

If you avoid gross mistakes and balance correctly, then you can create an MVP that will save you a lot of resources both in the development process and in further support.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *