The issue of speed and quality is particularly acute in development. We are used to thinking that the more time 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 abandoning testing, using crutches, often sacrificing architectural purity. 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 development speed. In this article, I will offer several options for working on an MVP that will allow you to speed up the process and get a product that can be developed for many years later.

Method 1. We reduce the capabilities of the product

The main task of MVP, as well as of almost any feature, is to solve a client’s problem. Think about whether all the functionality you planned is important? What can you give up to reduce development time? What will still have to be implemented in the MVP?

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

Method 2. We reduce the number of supported platforms and options

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

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

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

Method 3. Simplifying testing

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

I highly recommend describing unit tests, but not running them. Even if you just describe the test cases, you can see the flaws and get non-obvious insights for further manual verification. This is a great example of how you can get 80% of the results with 20% of the work, especially in the short term. For example, it looks like this 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. We use a simpler architecture

It is almost always possible to opt out of using three different databases, microservices, or queues without any loss. BUT: it is important to separate the logic in loosely related parts of the program. It is not necessary to complicate things too much – most often there will be a fairly simple division into functions or modules.

Regarding architecture, two main rules can be noted:

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

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

And three more important tips:

• Don’t complicate it — most of the product ideas will not be implemented at all, and among those that will be, a considerable part will turn out to be unworkable.

• Productivity can be neglected — of course, you shouldn’t put clearly inefficient solutions into the architecture, but the difference between one second and five, although noticeable, is often completely unimportant.

• Don’t try to solve problems with libraries — they will create much more problems for you. The worst is if you try 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 stuck.

Conclusion

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

If you do not make gross mistakes and balance correctly, then you will be able to create an MVP that will save you a lot of resources both in the development process and further support.