Building Your Product on Top of an Existing Prototype — Are You Crazy?

Nowadays you hear it so often: We are moving our business online. Or maybe you are based online from day one already. What it actually means is that you are dealing with a software service platform. Not a technology — as software is not technology. Software is a complex system that enables you to open your Internet browser and accomplish a certain task, while someone charges you for using the system or maybe gives you the access for free. The technology can be added on top of your software service at a later stage but that’s another topic. As soon as you, as the owner of the software or of the software concept in the making, have decided to provide this service, you have to build it from scratch, maybe with the help of other 3rd party software and mini-services.

And here comes the most interesting part: how to build it faster, cheaper and better than any of your direct or indirect, future or existing competitors? While ideas might not worth much, what is exciting as well as stressful is the execution of the idea. How much sweat, pain and time could you have saved if you knew in advance the nuts and bolts of building something really fast with minimal or available resources?

I have heard this too many times — we will outsource this thing to [insert yourself a country here you are currently considering — Bangladesh, Russia, Serbia, etc.] and in 3 months and $100K later we’ll have it, it’s that easy. No. I have been there in the past and it does not work like that.

Here are important data points for you to consider before opting to outsource it to someone else, instead of doing it through your internal development team:

• Internal technical PO, who writes down specifications and requirements. It has to be a technical person with experience in the development of software architecture, who can write decent requirements and specifications for what you originally had in mind.
• Pick an outsourcing company that provides you with a remote team that is yours. We at Nanos work with StartupSoft but there are also many others.
• You might still need to hire a senior developer who checks the coding and guides juniors of the outsourcing company (you will inevitably end up with those from the outsourced team and without a warning.)

You might have in mind building a sophisticated, scalable and beautifully looking product that will face millions of happy users. But you need to understand upfront that when you negotiate the cost of your product’s development, the more you push down, the more your outsourced team will be trying to save on all fronts. What usually comes at a high price are:

• Any other testing in addition to “unit testing” which can be done automatically and should be included in the price.
• User scalability — can 100 users be fiddling around with your product at the same time? How about 100 000 users?
• Design and usability — how many design iterations can you do and how many UX/UI iterations are included in the price when you realize there is a serious flaw?
• Security — minimal requirements and testing are already very costly. If you take your newly built product to an external security service, prices start from $20K.
• Additional environments — testing, production, etc. You would want to have a minimum of two environments and servicing already set up, which then your internal DevOps person needs to pick up and be onboarded with.

Now imagine the prototype is delivered and you have noticed its limitations, whether in its scalability, a major fault in the design of the software architecture, or an issue that can’t be easily band-aided on top. You have 3 options:

• Keep putting bandaids on. Each and every new feature will take a l-o-o-o-ng time to develop. Service and maintenance cost in terms of money, effort and time is enormous. This also means that you have to stick to the same programming languages which can easily become obsolete within the next 3–4 years.
• Refactoring in modules. Slowly replacing the old bricks of the house with new ones, one at a time. A smart choice. You will end up maintaining two systems for quite some time before fully switching to the new one. Difficult and costly, but doable.
• Rebuilding from scratch. This can be painful as it throws you back in many months and you can’t introduce any new features while still needing to maintain both the old and the new systems.

Rebuild from scratch — yes, go for it but under two conditions, when both are present:

• If you trust your own internal development team, that they are capable of designing the system, and writing the correct specifications and requirements list (in the case one or more of your key people leave).
• If you have business proof of the concept already, in the form of returning customers and you are gaining new ones. Starting from scratch throws you back several months or more but it is, in fact, faster than applying more and more bandaids to the old system or dealing with the spaghetti code.

There is a reason why SAP, a large company with a rich history who continues to provide its services across all industries for the last 50 years, is still keeping their first few senior engineers on payroll.

As you can see, there is no perfect solution. But at least I have informed you about the potential outcomes for some of your decisions, as well as the ways to avoid and mitigate the potential risks that might come along. Being informed means you have already won.

Written by Sasha Schriber

CEO of Nanos AI

www.nanos.ai

Originally published at https://www.linkedin.com.