Awin
What should you consider before deciding to build code yourself or to buy an off-the-shelf solution? Well, it depends.
Here are some of the factors you should consider, with examples.
What aligns with your priorities?
Get your priorities straight. If you are just starting to build an app, the priority should be to figure out ways to get your first customers.
Focus on first things first. Eliminate anything that sidetracks you from your plan of action.
The first versions of many apps did not even have a feature to charge users.
How far away are you from getting the first customers or moving the needle on your north star metric? Does what you are doing now, align with these priorities?
Maybe, coding your landing page - will not align with it, and you would rather buy, or use a service for your landing page.
If you are just starting out, your focus should rather be on the copy / messaging to your customers.
Design and the “looks” of it is secondary to some extend (unless it is a barrier to conveying your message). The standards are pretty high these days, but getting something should not be difficult.
Is this your core business?
During initial stages of building your app focusing most of your time on your core business is the way to go. Any time spent otherwise is a case for finding a tool that does it for you.
That being said, delegating something that is highly coupled to your core business, is a bad idea. This adds dependency to external systems which you have no control on.
How much time and money?
This one is a very obvious and straight forward question.
How much time and resources does it take you or your team to build a system versus how much time will it take, to just integrate an off-the-shelf product.
To a great extend, the frameworks that we build on - like Django or Ruby on Rails - offers a lot of in-built features, and comes with an ecosystem of packages that can be readily integrated without much effort.
What are the risks and/or future costs?
When you are building a feature from scratch, consider the probablilty of throwing away the code in the future. The risk involved in shelving a feature or product, and along with it the time and money lost should be evaluated.
This is also worth considering for the buy option. There is risk involved in the product not existing anymore, or the product pivoting into something else. Having a Plan B, or a list of alternative products is always handy.
Building or integrating is not the only step. There is also costs involved in maintaining it.
Lets consider the example of a billing system. Not only is creating a billing system a very complex affair, but also the time and costs of maintaining it with the complexities of regulations, and changes in your own pricing logic is very high.
Maintenance costs are relatively small for integration of products, but well, it depends. Breaking changes in API, in external services (though not very common), would have your team working on fixing your system for days.
Does it eliminate code?
With the advent of SaaS and services that focus on doing one thing really well, you can delegate parts of your application to external apps. Having no code to maintain for aspects you are not interested in, is a great investment.
For example, using services like Stripe, Auth0, will make payments and authentication “not my headache anymore”. You can just make use of these great tools - allow them to do their thing very well - and focus on what is important to you.
Do you get any superpowers?
Most times the tool you are considering to buy, will have 10 other features; other than the one that you are most interested in. Will you be able to leverage those options as well?
For example, if you are considering to use Webflow for your landing page, may be you can use it to create a one off store as well using their e-commerce features. So that kills two birds in one shot!
This will be true for most of the tools that you are evaluating. Don’t just stop at evaluating the only feature you are interested in - get a wholistic view of the tool/product and brainstorm ideas on how you can use some of its other features.
In this day and age, we have a plethora of tools for creating apps and projects. Its all about standing on the shoulders of the right giants. Creating and following a set framework to evaluate tools early enough in your startup journey will definitely help. These questions will help you weigh your options carefully, and find out the ones that best fits your needs.
Finding a name for your app