Should you build it, reference it or buy it? Making software decisions
Category : Uncategorized
When starting a business, you often start with a vision of a product which you believe in. But in order to make it work, you need to take your concept from the idea phase to the prototype/MVP phase as quickly as possible. For many, the reason for this is obvious, but for those hopeful newbies this is because once you get your Prototype/MVP you’ll be well positioned to get funded and make this your full time job. Until then, you’re working multiple jobs and your business is in the highest risk position it could be in.
So how do you build your prototype as quickly as possible? You typically end up with three options:
- Build everything yourself (this is the instinctual draw to the new entrepreneur)
- Find aspects of your prototype which are either free or open source
- Buy aspects of your prototype from third parties
With these three options in mind, what should you do? How do you make the best decision for your startup?
Through my experience I’ve come up with the following approach to making these decisions. My principled approach is to: Find open source options. If that’s not available or doesn’t work, find something you can buy that will work. If you can’t find it or buy it, then you’ll need to build it. While these three simple sentences make sense generally speaking, I’m going to walk through a little more detail as to how you figure out which option is best for you.
Free or Open Source Options
Finding a free or open source solution isn’t always free or inexpensive. Typically, you need to keep several things in mind. The main contributors to this is that you will have to potentially build, configure, deploy and problem solve the issues with your free or open source system. These systems often have a community approach to support and documentation, meaning that there’s a lot of other people out there who are using it, and you can ask them questions, but there’s no true authority on the software. This can be a blessing and a curse. While most of your support aspects are free, it really depends on how active the open source community is that determines how responsive people are to answering your questions.
After you find a potential open source or free solution, identify what you plan to do with it. Is it a server component, a client component or an app? Are you planning to sell it to consumers or third parties? The reason to ask these questions is to check what the limitations of the usage license associated with the component. If its a server side only component, you’re typically safe using it (as no one is really going to dig through your back end looking to see if you’re compliant with licenses at this point in your business). If anything is being used in the client, make sure you follow the license strictly. Generally speaking I look for MIT or LGPL licensing. If I’m planning to make my client or project open source, I’ll look at other licenses.
The second part you’ll want to look at is what type of support it will take to deploy it. Typically this is a question you’ll be asking if you’re making server side components.
- Does the license make it impossible to do your business?
- Does it require a specific operating system? (Windows operating systems are more expensive and can require more hands on efforts)
- Will you be able to deploy it to your servers or to the cloud you plan to use?
- What type of knowledge do you need to have to get it setup? Do you have it?
- Will the answers to these question be sustainable for the immediate future?
If you answer these questions, and the result are good then you have a solution. If the answers indicate it won’t work, start looking at other options or purchasing.
When purchasing, you need to consider what solves the problem at hand, ensure that you have the budget to purchase it if it does work, and finally understand when to buy. The strength of purchasing software is that you get a fully tested and qualified product which you should be able to rely on. In essence you are purchasing the time and effort those others put in, so don’t expect it to be cheap. At the same time, approach all purchases with skepticism. Businesses which sell software tend to oversell what they can do.
When purchasing non-SaaS (Software as a Service) software, first look at their documentation, support and community presence. If they’re missing the community presence, it’s not a huge deal as long as they have the other two. Understand what the costs would be based on having a significant number of issues which you wouldn’t be able to handle by just reading documentation. Next see if you can use a free trial period or a low cost option to prove your concept, rather than the full version. You can always upgrade later once you’re funded. If you’re on a free trial, make sure to purchase it only at the point you absolutely need it, and make sure you implement the most important features you’re going to depend on before the trial expires.
The preferred approach to purchasing software is to purchase a service rather than a licensed product you have to deploy, scale and maintain. When approaching any SaaS purchase the first step is to ask for their software road map. This should be a technical road map of what they’ve done and what they’re planning on doing in the future. Assume anything being done in the future won’t be done in time for you unless it’s in the contract that you put together with significant penalties. Review the road map, and ask questions to their technical staff, rather than just the sales person. I’ve gone through negotiations with CDNs where the sales person affirmed that I would be able to do http puts to their service, to later find out that they couldn’t technically support that functionality by their technical staff. Avoid this headache and do a feasibility discussion with their technical staff around where they are now. All promises need to be in writing and must have penalties associated with missed deadlines. Make sure to get a free trial period for evaluation and integration. Expect any time put in here could be wasted if the deal falls through.
Build It Yourself Option
This needs to be the last option you look at. The reason for this is that is that this is the slowest, most costly option at your disposal. The cost you’re looking at is that every second you’re delayed from getting your product live and funded, the more likely your competition will move beyond you and capture the funding which would have been available. You also will spend more time testing and supporting a variety of functionality which will take on a life of its own.
In an ideal world your product would connect existing pieces from a variety of other previously developed software products, either open source or purchased. This isn’t to say that your product isn’t unique, but rather that your concept’s various aspects tend not to be new problems to software in general. You’ll know that you will need to build something when you are not able to find any other way to get it built. In these cases, make sure you understand what functionality in your system this component will affect and verify that it’s absolutely necessary to prove your concept’s minimal viable product. If you can delay it, you should.
More and more investors expect a product to exist and be functional before they invest in the seed round of your company. Since more and more startups are able to get apps, services and solutions developed, the investors see their role as accelerating a viable concept. The approach I’ve outlined is intended to focus your efforts on building your user experience and solution, rather than low level system development. If there’s something that long term you want to build yourself, great, but first purchase something that you intend to replace to get your initial product built. Your goal should always be to prove your concept, and iterate on building your MVP and then features on top of that, rather than building the ideal product.