- Part 1: Choosing a Partner
- Part 2: Planning the Project
- Part 3: Building the Site
- Part 4: Iterating
You’ve found a partner you are excited to have build your core product. The next question is what to build? You have the vision, but should you attempt to build out your entire vision or shoot for an MVP? What platform should you build on? How will you market the site? This post attempts to help you answer these important questions.
Building an MVP
New business owners often want to realize their entire vision in the first project. This approach has two primary benefits:
- Your go-to-market includes all of your differentiators and benefits
- You can get more done in less time with a longer period of heads-down development as opposed to a more iterative approach
The drawbacks, however, are many:
- High up front cost
- Large investment occurs before the business model is proven
- Putting all your eggs in one basket means an initial project failure can be catastrophic
- The entire product is built without real customer feedback, allowing for important requirements and considerations to be missed
Most investors today will push founders to build a Minimum Viable Product (MVP). An MVP is the simplest working product that allows the business to ensure that:
- There is in fact a market for their product or service and customers are willing to pay for it
- The business’s understanding of the market’s needs are accurate
- As much of the development scope as possible is based on what is learned from the market and customers
The idea here is to build something simple quickly, get it in front of customers, and build out the rest of the product based purely on customer feedback and what is learned from the market. For more on building an MVP, check out Eric Ries’ book, The Lean Startup.
Choosing a Platform
A platform must be selected for any web project, whether or not it represents an initial startup project. Some of these tips are general best practices, while others are specific to startups building a web application:
- Make sure your platform is intended for how you’ll be using it. For example, don’t try to build a complex interactive web application in Joomla (an open source news/magazine CMS).
- Use a widely used, open and robust platform like C#, Java or Ruby. Avoid anything bleeding edge (e.g. there’s no major player using it in a big way) or with a small developer community.
- Use a widely used, open and robust framework like Microsoft MVC.Net, Spring or Ruby on Rails. Frameworks save a lot of development time and ensure that you’ll be able to easily find developers who can quickly jump in, understand and work on your code base.
- Don’t get caught up in religious debates between equally viable platforms. For example, Java vs. C# is a fairly meaningless debate in most cases. You’re safe with either choice.
- Beware of your agency partner pushing you into the platform they know if it’s not a good fit with the considerations above. If your agency partner builds everything in a home grown PHP framework or ColdFusion, find another partner.
Your Application is not your Marketing Site
Finally, a common misunderstanding we’ve seen with entrepreneurs is that their application website should, in most cases, be a different product from their marketing website. This may not be intuitive at first, but consider these reasons to keep them separate:
- Your marketing site serves prospects and people who don’t know who you are or what you do. Your application serves customers who want to use your product or service. These are very different audiences with very different goals and expectations. Neither should have to muddle through a site that isn’t built for them to achieve their goals on the site.
- Especially as your business grows, you’ll have different teams working on the marketing site and web application. Its good to avoid having these teams needing to coordinate changes with each other.
- The best marketing website platform is not the best application platform, and vice versa. Building a marketing website in MVC.Net is as foolish as building an enterprise data warehousing application in WordPress.
If you agree or disagree with any of these tips, or if you’ve run into any of these or other snags, be sure to leave a comment. I’ll be back in another few weeks with the 3rd installment of this series, Building the Product.