MVP Product Costing $100,000+ Without QA Testing. Is It Possible?

Recently, we released the beta version of our platform for crypto traders, which allows real-time analysis of the growth and decline charts of most cryptocurrencies as well as historical data. Currently, the product is undergoing closed testing with a group of investors. We are receiving feedback on the quality of the platform, fixing any bugs that arise, and preparing for the next stage of developing a full-fledged version of the product.

During the initial discussions with the client, we discussed the prospects of launching the project within 3-3.5 months, taking into account the scope of work, and assessed it as unlikely (50% probability of launching a "working" product) and high-risk (90% probability of failure). If you're interested, I can talk about the method of risk assessment in future articles. Here's why we came to this conclusion:

1. Lack of technical documentation: We had a task list with brief descriptions, such as "clicking the button should trigger the console and display specific information." While this may be clear from a business logic perspective, there are difficulties when operating in technical language. Frankly, almost all new projects start with such initial data, and our company, Airkod, always has (and should have) a contingency plan that allows us to achieve the desired result.
2. Lack of code testing: If you thought the client was a "newbie," you are mistaken. The client is a large holding company with extensive investment experience and a track record of creating new products for over 30 years. I can't disclose the exact location, but it's a very wealthy region in East Asia.

The scope of work involved a team of two frontend and two backend developers. More than 1,500 hours of work were planned, with a limited budget covering development and project management but not including testing, which should have allocated an additional 30-40% of time, depending on the specific project.

To avoid risks and preserve our reputation, we used our standard working method:

• Breaking tasks into two-week sprints with daily meetings. Within one hour, we could review the current state of the project, ensure it is aligned with the requirements, and make adjustments at control points.
  Tools used: Trello, Gantt charts, Notion, Google Spreadsheets, meetings.
• Daily meetings with the design team. Here, it was important to strike a balance between impressive design layouts and the realism of their implementation. The more animations and effects, the more work for frontend developers.
  Tools used: Figma, Notion, meetings.
• Prioritizing tasks and deferring secondary tasks to a post-MVP stage. It's easy to lose focus and add too much functionality, so we always stick to the initial market entry strategy and use common sense to understand what we can temporarily forgo or how to replace certain features.

Regarding Code Delivery: TDD (Test Driven Development)

We could have started the project by writing code for testing immediately. This method is called Test Driven Development (TDD) and is crucial for large and complex projects. However, due to limited time, we used a simpler scheme:

• Code delivery on GitHub with preliminary review by our team > client review and task creation with status indication on GitHub > debugging > review. Framework used: GitHub.

Summary

The project was released with a one-month delay. The reasons for this delay were twofold:

• Addition of several new tasks to enhance functionality.
• Bug fixes. The client initially anticipated that the absence of technical documentation and testing could result in a delay of 1.5-2 months, as we had advised.

Conclusion

I still recommend including a product testing phase when launching an MVP, as it guarantees the release of the project within a specific timeframe. Without testing, the likelihood of success significantly decreases. Alternatively, be prepared to postpone the release date by several weeks or months, depending on the project and the developers' expertise.

Best regards!