PoC or MVP: What should you test first?

PoC stands for proof of concept. It is a focused experiment to find out whether a proposed approach is feasible. In a software project, it often examines technical uncertainty rather than building the whole product.

Suppose a business wants customers to book appointments online, while an older system still manages the calendar. Before building the website, developers need to know whether they can retrieve available times from that system. A PoC could test the connection, read availability and check updates without building all the screens or reports. This is a hypothetical example.

The result should state what was tested and what remains unresolved. Reading availability does not establish whether a slot can be reserved when two people choose it at once. A successful test connection also does not confirm production permissions and operating conditions. Record untested areas so a limited result is not mistaken for readiness of the whole system.

MVP stands for minimum viable product. It is a limited version offered to users so the team can learn whether the product meets a need by observing what people actually do. The purpose is to learn from real behavior, rather than relying only on whether people say they like the idea.

In the booking example, the business could offer one service to a limited customer group. Customers choose a time, submit their details and learn whether the appointment is confirmed or pending. The team can observe completion, points of difficulty and reasons customers still call, then use those findings to improve the service or consider expanding it.

Minimum does not mean removing so much that users cannot attempt the task being tested. If the question is whether customers can complete a booking themselves, a promotional page and a button alone will not answer it. Some steps behind the scenes can be manual, provided the results are interpreted accurately and user information is handled appropriately.

A limited scope still needs appropriate data protection, failure handling and support for participants under the agreed conditions of use. Record any substantial staff assistance. A completed booking does not establish that the same operating model will serve a larger customer base.

Choose according to the uncertainty that could undermine the project. A PoC can investigate whether the proposed connection, processing or technical conditions are feasible. If the main question concerns whether people need, use and benefit from the proposed service, an MVP is more suitable for learning from actual use.

Retrieving available times from the old calendar addresses a technical question, not whether customers will book online instead of calling. Conversely, if staff check the calendar and assist every customer manually, the exercise may reveal demand but does not establish that automatic integration works.

Not every project needs a separate PoC followed by an MVP. If the technology is established and demand is the main uncertainty, a standalone PoC may add little. If an uncertain connection is essential, investigate it early before investing in features that depend on it.

Before starting, agree the question, trial scope, time, budget and who will review the results. For the booking PoC, specify whether the work covers reading availability only or reserving slots as well. For the MVP, identify the participating customers and what counts as a completed booking.

Prepare data, access permissions and support contacts too. If the real calendar cannot be used, record how test data differs and what cannot yet be concluded. Decision-makers need to understand the conditions behind the result.

To propose a useful trial, the partner needs to understand your current work, intended users and systems that must connect. If you are unsure where to start, What should you prepare before a Software Project? explains what to bring to that discussion, so the trial is grounded in a business need rather than just a feature list.

Beyond checking that a connection works, you may need to know how quickly availability updates or what happens if the connection is interrupted. Agree these conditions and how to measure them before testing. What are non-functional requirements? explains how to define performance, reliability and operating requirements alongside features.

Return to the original question when reviewing results. A PoC report should identify what worked, what did not and the remaining dependencies. For the booking MVP, examine completion, user difficulties and the amount of staff assistance. Comments such as “the demo worked well” or “customers found it easy” do not replace that evidence.

If the connection is inadequate, consider another approach or reduce the scope that depends on it. If customers stop because suitable appointments are unavailable, review service capacity before blaming the interface. If completion requires extensive staff intervention, reassess operating effort before expanding.

The next decision may be to continue, revise and retest, or stop the current approach. Record the reasons and the work that follows; a successful trial alone should not authorize the whole project.

Before investing further, weigh this idea against other IT needs awaiting attention. Your IT roadmap: What should come first? helps you consider delivery priorities in light of business needs and practical constraints, rather than giving an idea priority simply because its trial went well.

Before broader development, review what can be reused, what needs rebuilding, which tests remain and who will operate the service. PoC code is not automatically production-ready, and an MVP does not establish readiness for a scale beyond what was tested. Further investment should account for those limits and the work still needed.

If you have a software idea but are unsure what to test first, discuss the work you want to improve and your main uncertainty with Fenix. A clear question helps identify whether a PoC, an MVP or another form of investigation best fits the need.

Discuss your project with Fenix