From your dreaming, preparing businesses plans, and pitching, you have a pretty solid idea of what your MVP will be. It’s important to maintain that as a point of reference, but part of the world of software development is knowing that will change as you get more feedback about your product, its fit in the marketplace, and involve more people. Keeping that in mind you need to consider how you maintain a development environment which is flexible to your changing needs. The last thing you want is your application to be a black box of unfamiliar, inflexible, or proprietary tech. You know you need to work with outside vendors to build your app, but don’t let them dictate to you how your MVP will be built, and certainly don’t let them put you in a situation where you are locked in for later phases of the application.

A great way to make sure that flexibility is being maintained is to request that work on your MVP be completed in small deliverable pieces. Instead of building the entire app, you could focus on a user’s dashboard view first – even just putting in static data to start. This opens the possibility of testing the waters with multiple vendors. You can evaluate how you work together, their output, and real costs far better than just reading some pitches and looking at estimate numbers. It’s a great way to figure out who is really going to be a good fit as a technical partner.

Image c/o http://www.jopwell.com

The first step is to adjust your focus; you’re no longer pitching and selling the idea but transitioning to delivering on expectations. It’s no less demanding, but requires a different mindset to succeed. You have to move from conceptual thinking to more pragmatic thinking.

The primary goal you have now is to build the smallest possible version of your product you can launch with, your minimum viable product (MVP). You (and your friends and advisors) probably have a huge list of features you want to support, but that will extend the time it takes to get to market, and if you estimate or plan poorly you may run out of funds sooner than expected. If you are out of runway you might need to ship whatever product you have, and that product may not have the key feature or timing the product needs to win the marketplace.

We strongly recommend avoiding these problems by creating a prioritized list of functionality and then building your app in such a way that value can be delivered incrementally. This is a good place to leverage your value proposition or mission statement; to really target what it is that makes you unique or you do better than anyone else.

Getting in the market (or at least in front of testers) faster allows you to get more feedback and respond to issues quickly. It’s better to find out early if you have made a bad assumption. Even working with well designed software it is much easier to change a small app than a large one; this is a big part of the philosophy behind what is called Agile software development. It’s beyond the scope of this article, but building in an Agile way aims to plan and build in response to market needs, delivering iterative versions of working software.

By focusing and building the smallest thing you can, you’ll get to market quickly and begin to really test the waters with your ideas.