Why PoC is actually your best money saving idea, not an unnecessary splurge
How many times did you decide to abort some project because you realized it wouldn’t come up to your expectations? Life happens, but in order to eliminate any guesswork and get you insured against software development failures in the future, have a quick look at this blog post we’ve prepared for you. Here we talk about Proof of Concept – a mini-project that will save you time and money next time you won’t be 100% sure about the software you’d like to build.
What is PoC and why do you need one?
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
PoC vs MVP: which one do you need?
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:
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.
What do you get after a PoC?
First, you have an understanding of whether you should invest your money into an idea. Second, you have a document containing:
Let’s have a look at an example to make it clearer for you.
A client approached AIS Novations for a PoC project. What they wanted was:
- A mobile application for video chats
- The app would use WebRTC (the tech solution was the client’s choice)
- The number of concurrent users in one video call should be 12
- 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.
When can you skip PoC?
There are three major factors that may signal you that the PoC is unnecessary.
- 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.
- 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.
- 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.
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.
Can I skip PoC because my project is small?
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 AIS Novations 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.
If a client doesn’t want a PoC, can a vendor initiate it themselves?
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.
I chose to use infographic instead of concluding lines here, because I know visuals work better than letters. If I didn't know that (but thankfully I can always consult the Internet on such issues), I’d do a small blog post and go test it on someone. I hope you do the same with your software ideas. Cheers!
Many thanks to Alex Tsuranov, VP of Delivery at AIS Novations, who shared his deep insights on the topic and made this blog post possible.
Here are a few more posts that may be interesting for you which cover other why’s of software development:
Why you might need a QA? Seriously, if the developers can check their code themselves!
Why can restaurants do no longer without technology? For sure they can, but not for long.
Why outsourcing may result you in higher costs (but higher quality as well).
Stay in touch