Assessing the Technical Feasibility Of An App Idea
After long and arduous brainstorming sessions, you came up with a great idea for a product.
You even went a step ahead, and did the necessary steps in order to get your idea as validated as you can at this step.
This means that you did your market research, through surveys, interactions with people in the industry and even a small sketch to showcase your idea.
And then it hit you: but what if it can’t be built? And if it can, what if I don’t have the budget for it?
Bashing yourself for being overly enthusiastic on the business side of the idea and not thinking about this earlier, you start researching its technical feasibility.
Then you find out that before being able to start conducting your research, you need to base it on tangible aspects of your product.
This means that you need to create the contour of your product.
Molding your idea into an MVP
The best way to mold your idea into a product is to think of it as an MVP.
An MVP is the minimum viable product based on your idea.
This means that you think of the minimum features that would make your product a product that can be released to the market.
For this, it’s important to sketch down the details of it.
But the degree of details depends on the particularities of the idea.
You might find out that you must go in detail for each feature, or that just sketching the major ones is enough.
For example, for a Chat feature, it can be enough just to name it or, if you want an end-to-end encrypted multi-group Chat, then it’s good to try and sketch down as much as you know about the feature.
Either way, you now have the fundamentals on which to base your technical feasibility research.
Researching the technical feasibility of the MVP
Now, you get to the hard part, which is actually figuring out if your MVP can:
- Be done at all
- Be done inside your budget
To get it out of the way, you have the option of delegating this task to a competent technical person, if you don’t consider yourself qualified.
OK now, let’s head on over to the process.
Since you broke up the product into the different features that make it whole, it’s easier now to spread out your technical feasibility inquiry on each feature, rather than on the whole idea.
So, you take a feature, for example the end-to-end encrypted multi-group Chat we mentioned before and either try to break it down further into different parts, or screens, or you take it as a whole and think about how much time it would take to develop it.
Now, since some of you out there are not that technical oriented, you should start researching on your own on different tech sites and avenues, such as StackOverflow or Reddit.
Moreover, you can create your own topics on forums that specialize in helping people get up and running with their startup, such as HackerNews.
Or, you can take matters into your own hand with a software estimation book and try and figure it out by yourself.
Keep in mind that it’s one thing to know if a thing can be done at all, and another how long it will take.
After you get a rough idea of the implications of the feature, you rinse and repeat for the rest of them, to reach a grand total.
What if the idea isn’t technically possible?
Although this is a possible outcome, you shouldn’t be discouraged as there is almost always a reasonable workaround that might not affect your original idea that much.
For example, let’s say that our end-to-end encrypted multi-group Chat isn’t technically feasible in the budget we have.
Well, there could be a number of tradeoffs we could take, such as:
- Not encrypting it
- Moving the encryption on the server-side
- Keeping the encryption but only for 1 to 1 chats
- Etc.
It’s important to gauge the priorities and really think hard if this tradeoff is going to take away from the original purpose of the idea.
Plus, if you play your cards right you can not only get another perspective on the issue, but also have it weigh less on your budget.
Conclusion
Usually, technical feasibility comes after business feasibility, meaning that your idea has business potential.
We wrote a whole chapter in our book, From A to App Success: How to turn ideas into apps that make a difference, about the ideation and the validation phase, so make sure to check it out. It’s free.
That’s it for this week, join us next time for more insights on the world of mobile apps!
