Why PoC is actually your best money saving idea, not an unnecessary splurge

The PoC (Proof of Concept) is required to see whether an application or some of its functionality is implementable and to which extent it is implementable or feasible.

PoC isn’t always a must. Customers don’t ask for it more often than not. However, some of them (especially big clients) initiate PoC themselves before investing money into a project. Such a decision may stem from a previous negative experience when a client invested into a product development that didn’t work for them. There could be multiple reasons behind the software project failure – technical design or execution was wrong, lack of or poor system analysis so the system couldn’t support the real number of users against the projected number of users, etc.

So, PoC is usually a small working application which may not even have a UI/UX or have a very primitive UI/UX that would test technical implementability of the application/feature/service. For example, a PoC may test

• whether a specific 3rd party system can be integrated into the application to enable some sort of functionality or
• whether a specific 3rd party system is a best match for implementing functionality required for the project or
• whether a specific 3rd party system suggested by the customer has all necessary functionality to cover project features without customization.

MVP stands for a Minimal Viable Product, and as it comes from the term, it’s a ready to go software system. Not a feature or a feature set, but a finished piece of software that has a bunch of functions and brings some value for the real users. If put short:

• MVP has a UI/UX;
• You can show it to the investors;
• If it’s a well done one, you can even deploy it into production.

 

Let’s summarize it – an MVP is an application that has all the must have features, but doesn’t have some nice to have’s. It has all it requires for a complete user’s flow without optional improvements.

First, you have an understanding of whether you should invest your money into an idea. Second, you have a document containing:

• an expert conclusion why the idea is implementable/feasible or not;
• several development approaches for the implementable idea with pros and cons of each;
• a set of technical solutions for the idea which would make the system implementable, if the technical solution chosen by the customer is a no-goer.

 

Let’s have a look at an example to make it clearer for you.

A client approached Symfa for a PoC project. What they wanted was:

1. A mobile application for video chats
2. The app would use WebRTC (the tech solution was the client’s choice)
3. The number of concurrent users in one video call should be 12
4. The video resolution should be X.

 

The PoC showed that the solution was feasible only for the Android system using the mobile SDK’s suggested by the customer. The iOS system would kill it because it would take 100% of the processor's capacities. It would hurt to hold the phone while making a video call because it was getting so hot.

After our team did the PoC, we made an expert conclusion for the client that only 6 users can participate in a video call if the app would be developed using the technology of the client’s choice. The resolution should also be changed for a lower one, as it seems unfeasible to have a high resolution video chat on a mobile device even with 6, let alone 12 users.

We handed the expert conclusion to the client and they now will make their own decision whether to go on with the project.

Thus, PoC saves the client the money they would have otherwise wasted on a no-goer. Moreover, you don’t have to pay the whole team during a PoC. It’s only one talent – usually a Senior Developer – that does all the job. The development team usually reuses created PoC code for later jobs, so it also saves the client some dollars in the future.

There are three major factors that may signal you that the PoC is unnecessary.

1. The vendor has a proven success track record in some development areas and they know well how to implement that kind of solution you want.
2. It’s a more or less typical system (online store, dating website/app, messenger, etc.) that has been out there in the market for decades.
3. There are no uncertainties in terms of technical implementation or feasibility of the chosen technologies and tech approach.

 

In all other cases (a vendor has limited previous experience in the given solution type; the solution you want is unique and few companies in the world (if any) did it; you aren’t sure about the technical implementation of the system) PoC is a must.

Another example for you.

A client turned to us to check if the video streaming is possible for a specific model of a video camera chosen by the client.

• The video should stream from camera directly to the browser.
• The video stream should be in a format that’s new to the market (the tech solution was the client’s choice).

 

Our team needed to check if the data could be converted on the fly. For this project, we wrote a custom converter in C++. The question was how long it would take for the converter to do the job with a resolution that the client wanted.

After a PoC, we made an expert conclusion that the client would have to wait 5-15 minutes for the video to be converted under the suggested conditions. Thus, real-time streaming would be impossible. In our conclusion, we also offered the client a solution with a different technology and different video resolution that would be a nice fit for their project. The client saved the money that they can spend on a workable solution in the future.

Nice question. It’s a tricky one, though. We’d say, you shouldn’t skip PoC only because your project is small. If an uncertainty about the chosen technology/approach exists or your application is unique, our answer is NO.

Have a look at one more case.

A client contracts Symfa for a 2-month project on which only 1 dev and a part-time QA will be engaged. But it isn’t the project size that matters here.

The client wants a mobile app that connects to the Apple watch. The Apple watch sends the physical activity data to the mobile app that launches deep-learning algorithms to generate charts and graphs based on the sports sessions for the user.

Why PoC here? The client came to us with the ready-made DL algorithms. The application is supposed to be running without a backend on a mobile device. As the DL algorithms were not written by our team and the application architecture isn’t a standard one, the PoC is a must.

Actually, this is how it’s supposed to be. If the client doesn’t have a deep understanding of the subject and is unable to detect some risks about the application, the vendor must speak up.

It’s only logical that PoC is initiated by the experts who will be in charge of the project execution and bear responsibility for the outcomes. The vendor must study the client’s idea (described verbally or in some docs) and if there’s some technical uncertainty or inconsistency, run the PoC.

Even if the client is in charge of the system architecture, but we as a vendor aren’t sure that the technology chosen by the client will allow implementing the solution under design, we’ll initiate a PoC. The decision is always up to the client, whether to spend a week’s time on the idea validation or not. But in some cases, a week-worth of effort saves months of unnecessary fixing and spending.

Hope you don’t mind me sharing one more story, because I simply can’t keep this one to myself.

Our client, a major US insurance player, wanted to implement a low code ETL platform on their projects. We did a PoC for two projects where it seemed feasible to use the platform.

In one case we agreed with the client’s suggestion that the solution is implementable. It will pose certain limitations in terms of UI/UX, as the platform allows using only the ready-made blocks to implement UI/UX. As it is a system for internal use solely, the client’s primary goal is the functionality, not look and feel. So, the decision was made in favor of the low-code platform and after the PoC, we embarked on the project.

The second PoC showed that the client’s processes for that given product were too complex to implement the low-code solution. Thus, the client continues with the custom solution for the time being.