- App Type
Technical decisions for your MVP app
To improve your odds at launching a successful product, understand the high-level programming decisions.
Sure, it may be overkill to learn how to code. But understanding the basics will go a long way.
78% of the successful folks we've helped had a solid grip on the tech under the hood. Of the unsuccessful, only 4% had any technical input.
Why the correlation? We have two explanations:
- As the visionary, only you understand the intricacies of your idea. Your developer could define the application, if you don't weigh-in on translating idea to code.
- Not that developers are malicious, but sometimes incentives diverge. In order to adequately vouch for yourself, you have to have some idea of what's going on'.
As a metaphor for the second point: imagine you are in a taxi concerned that your driver is taking a convoluted route. In a country where you didn’t speak the language, you would have basically no recourse.
What language do you speak?
Much ado is made of the programming language. We’re of the professional opinion that this conversation is over-hyped.
Assuming that your product vision doesn't involve some hyper-optimized technical advance*, then our advice is to reach for a mainstream language. Any of the those profiled in our report card should be fine.
*If conversely, you are trying to build a better image compressor, then you should already have your technical ducks in a row.
Our programming language report card.
We define power generally as how much you can accomplish with a fixed amount of code, ecosystem as the quality and quantity of tools written for that language, learning curve as the ease in picking up the language – which may be important if you're hiring a junior developer or trying to learn yourself– developer market as the ease in finding a developer with experience in that language, and scalability as a score inversely proportional to the frequency of unwelcome rewrites.
These scores are based on our experiences using them for different projects. You should try to optimize the metrics that matter most for your project, whether that be developer accessibility or scalability.
|Language||Power (1-5)||Ecosystem (1-5)||Learning curve (1-5)||Developer market (1-5)||Scalability (1-5)||Other notes|
|Python||4.5||4.5||4.5||4||3||Great for machine-learning applications.|
|PHP||2||5||2.5||3||3||Power frameworks like Laravel and WordPress are built on PHP. PHP powers some of Facebook.|
|Ruby||5||3.5||4||4.5||2||A developer framework that powers Shopify.|
|Java / Kotlin||2.5||3.5||2||4||4.5||The language of native Android applications. Also often chosen for robust enterprise applications.|
|C#||2.5||4||2||3.5||4.5||Optimized for Microsoft's Azure.|
|Swift||4.5||2.5||2.5||2.5||4||The language of native iOS applications.|
|Go||2||3.5||2.5||4||4.5||The fastest mainstream language. Well-designed and elegant.|
Great resources: [Popular tech tools] and [The same app written in 30+ languages and frameworks]
Our recommended frameworks
A framework is an opinionated tool meant to optimize for building software applications and minimize boiler-plate code. You should absolutely use a framework when trying to launch a tech product.
SQL vs NoSQL
We can talk until we're blue in the face about SQL vs NoSQL ("Not only SQL").
Generally, SQL requires less set-up and has a smaller learning curve for scalable applications. But SQL has its limits. SQL is a column-based solution whereas NoSQL tends to be row-based. This means that for a gigantic dataset (>> 1,000,000 rows), you can't effectively break-up a SQL database into a searchable cluster of databases like you can with NoSQL. If you have lots of global data, then NoSQL usually makes more sense.
With Getcho, SQL works fine because users are not connected to each other and we can simply create new databases for future sets of users.
On the other hand, you need to be able to search all 2 billion users in Facebook with a single query, so a SQL database definitely wouldn't work.
API: REST vs GraphQL (optional)
Both of these are great options with differing advantages that exceed the scope of this guide. Feel free to look into our technical consulting packages if you need guidance.
Hosting and infrastructure
Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) comprise the "big three" in cloud providers. Digital Ocean is also a great option, known for writing great documentation and how-to guides, if you're one to get your hands dirty. AWS has the largest market-share and probably the most robust services, but has a steep learning curve and sometimes hazy documentation. Azure's services integrate great with Microsoft products like Github. And GCP probably has the most friendly offering for MVP apps, with services like Firebase.
Again, you can't go too wrong here. Here's our advice from our extensive experience:
- Make a decision and go with it. Concerns of "vendor lock-in" have mostly just slowed companies down.
- If you're building a traditional web application, host a single-page application (SPA) on either Firebase, Netlify, Cloudfront R2, or an AWS S3 with a Cloudfront in front.
- Make sure your development team has experience with continuous integration.