Let’s say you intend to build a minimum viable product (MVP) to validate your tech startup idea, but you’re not a tech person. The obvious solution is to outsource it, but with so many freelancers and companies on the market, each having different tech stacks, portfolios and offers, how can you tell which ones are trying to rip you off? We made a list of top hidden struggles our clients had in the past with outsourcing their web or mobile app MVPs.
1. Tech stack costs long term
You want to build a social media website. There are multiple ways to get an MVP done, and each team usually has experience in a few of them. Each one will try to sell their preferred programming languages as the best choice for your product. But you’re not a software engineer, you can’t differentiate between their preferences, and why does it really matter if they get it done?
Few months pass by, your MVP is on the market and your startup idea proves to be a success. You now want to take your product a step further and implement new features, but you find it hard to assemble or find a team of developers to continue working on your MVP because it’s based on obscure or old technologies. You find yourself forced to rewrite the MVP from scratch, which costs money and delays any additional features for some months. The same thing happens if you decide to stop collaborating with your chosen company: it will be hard to find another team willing to continue a project on a poorly chosen tech stack.
But how can you know which tech stack is better? Let’s say one team tries to sell you Angular, while another one is promoting React. Start by looking into their popularity growth in the past years.
If the programming language is too obscure, you’ll find it hard to replace the dev team. If it’s too old, the candidates are old seniors, which are also hard to find and don’t justify the cost. Young programmers are cheaper, easy to find and usually prefer new stuff, made for developing faster. New programming languages usually become popular only if they are better or faster than their predecessors with the same purpose. You want new, popular technologies.
2. Diversified tech stack portfolios are bad
You come across a team that made video games, a hardware device, a social media platform and something involving blockchain. You see they have a very exhaustive list of technologies they’re good at, they must really know their stuff, right?
A diversified portfolio could mean the company is a master of all tech stacks, with many tech departments or with extremely versatile developers. But only in a perfect world. More often than not, a diversified portfolio translates into a “jack of all trades, master of none” team, which builds things that just work. This approach is common in companies that don’t have enough clients to justify being picky for projects using the same technology stack. Using similar tech stack on multiple projects means faster and more qualitative products, which translates into more revenue, and companies rarely choose to have a diversified tech portfolio if they have the option not to.
If their sales person is using the diversified portfolio as a reason for increased prices, you’re probably getting ripped off.
3. Unspecified requirements become paid additions
Anything “not worth mentioning” can become something you’ll pay extra for. One aspect clients sometimes omit and teams intentionally leave unspecified is whether you’ll receive the source code or not. Once the project is done or you consider to stop working with the company, you’ll want the source code of the project so you can let another team continue working on it. But the company is not forced to give you source code if it’s not specified anywhere in the contract, forcing you to either continue working with them for maintenance/development or to rewrite the MVP from scratch.
Other examples are features you consider so straightforward, they must be automatically assumed. You then find yourself with an MVP that has a login form, but no password reset option, which costs extra. It can be either an intentional shady tactic or miscommunication from both parties, but it’s an issue which happens often and can be solved simply by making your list of requirements as exhaustive as possible.
If it isn’t in the contract explicitly, don’t expect it to get done. Any small feature or detail you want, put it in the contract. Don’t let anyone hand-waive that away, there’s no such thing as a “too long requirements list”.
4. Tools are double-edged when poorly researched
Like you outsource your project to developers, they usually outsource some parts of their projects to online services, called APIs (Application Programming Interfaces). Instead of being forced to implement everything in-house and to reinvent the wheel, they create your project faster by using already written components. Let’s say your project involves online payments, your developers could either implement their own solution in a few weeks and maybe face some legal issues, or implement a solution using Paypal/Stripe APIs in a few hours. It’s a no-brainer! How can APIs ever be a bad thing? Usually, they’re not, but there are some corner cases that can cost a lot if neglected.
APIs can be free or paid, based on their usage. Even when paid, their price is low enough to justify using them instead of implementing your own solution. API providers don’t give you access to their source code, they expose some black box functionalities to be used over the internet. This means that your project relies on their long term lifespan: when an API goes out of business, any component that depends on it must be rewritten. An example is Facebook severely limiting or shutting down parts of their APIs for Instagram [source: TechCrunch], making any product that relied on them suddenly useless. This kind of event happens rare enough with large companies to still justify using their APIs, but allow any obscure APIs into your project and there’s a high chance it will suddenly stop working a few months after it’s finished and you paid for it.
Some companies will sometimes try to sell you some of their APIs with your project. They will deliver faster and a more qualitative product when using their tools than by being forced to use similar solutions of their competitors, so using their APIs must be a no-brainer, right? If you are satisfied with them and intend to keep working the company, yes. Otherwise, you’ll just force yourself to depend on them even after moving to another team, unless you rewrite some parts of your project, which costs money and time.
A good practice is to always make sure your project is accepted by an API before implementing components based on it. Another common issue is being rejected by Paypal/Stripe payment APIs after implementing them due to bad business model or legal issues, costing you more money to redesign a part of the project’s architecture.
Libraries, on the other hand, are similar to APIs, but they are usually open source, downloadable, editable and don’t depend on their founder to stay in business. They serve different purposes and pose almost no risk in the long run, don’t confuse them with APIs.
5. Cutting-edge tech cuts you first
One of the teams you found is suggesting to use a revolutionary tech released one month ago, which is quickly on the rise and is better in every aspect than its predecessors. Being one step ahead of the competition is another no-brainer, and you can’t really judge experience on recently released tech because nobody had time to use it, right?
While we recommend using technologies which are new and popular, always research the team’s experience with said technology. Most teams must swap to what’s new and popular every few years, and if the proposed tech is too new, chances are they are shoving it just to get their developers warmed up with their new architecture. Even if it’s superior in every way, that new programming language will bring instability and bugs if the engineers are not used to it. They’ll not be able to reuse tested components, the way they can with tech in their portfolio. Sure, it has its advantages, like the code running faster because it’s better optimised and scales better with thousands of simultaneous users, but is this a real issue when you’re a startup? Unless absolutely necessary or the pros clearly outweigh the cons, we recommend to go with the tried-and-true, boring, stable tech stack that’s still new, rises in popularity, but had enough time to be tested on the market.
CTO
Tech guru with a keen eye for solving deep technical problems in software engineering
