Building a minimum viable product — something that can show what you want to do to prospects and perhaps even start bringing in a little money to help you fund the development of a bigger product — makes a lot of sense. It’s especially useful when your product is solely the result of the hours you spend at the computer: minimizing those hours to test the basic concepts means that you can discover what does and doesn’t work a lot faster.

But deciding on just what you’ll offer as your MVP isn’t always easy. Some projects have a small core component that you’ll have to build anyway to get started, making for a quick decision. But many projects have a lot of moving parts and it’s not always simple to decide which parts need to be tested first. These tips can help you make a decision.

1. Make some lists. It may seem old-school to just sit down and think about your product, but write out a list of the reasons the full product will be attractive to your customers. Create a list of the smaller pieces of the project that you could complete without building the whole structure, and note the pros and cons of using each piece as your MVP. Don’t limit yourself to what you can build, by the way. If you can mimic the function of an app by hand for your users or rely on a couple of APIs to get started, include those options.
2. Schedule interviews with your ideal customers for the full project. Unless you are also a member of that audience, it’s hard to tell what you’re assuming to be true and what that audience actually believes. Take your list and start asking questions. You may find that one small piece of your project is exactly what gets that audience excited.
3. Put together a short plan for actually building each of your contenders for MVP. Some options will be more minimal than others, at least in terms of what you need to build to make it available. Consider details like whether you prefer test-driven development and how they might slow certain options down.
4. Plan how you can test and gather data about the finished product. If you can’t find out how audiences respond to your MVP and what you need to change, then you’re not looking at a practical MVP. This needs to an experience you can easily learn from.
5. Decide what part you’re excited about. The coding always goes faster when you’re working on something you actually want to finish. If a lot of your potential MVPs aren’t exciting you, skip over them to something that you’ll be happy to put extra hours in on.

Image by Flickr user Gangplank HQ

Thanks to all of our users for bearing with us this week with our downtime and database issues. We've worked nonstop the past couple of days to make sure the site is up, functional, and behaving like it was before the downtime. A very small number of users are still affected, and we're working with each and every one of them on a case-by-case basis to make sure they're happy with their profiles. We thought our downtime could be a learning experience for everyone - I wanted to let you in on what happened in the aftermath as well.

RECOVERING FROM DATA LOSS

After we had our database issue, we pieced together the data from last week using backups and with the help of some of our external service providers that had cached copies of submissions, posts, achievements, and more. Our entire engineering team worked shifts for 36 hours straight to pull data out of our backups and prepare a fixed version of our database for when the site came back online.

Thursday evening at 6 or 7pm, after a little more than 5 hours of downtime, we decided not to bring the site up until we were confident we had restored the majority of users' progress, points, and badges. We spent the next 11 or 12 hours working on that (all hands on deck).

Thursday morning, we brought the site back with almost all of the data we were able to restore. Most users were unaffected and saw no issues after the site came back up. Linda and Karen, our community management team, designed a form for people to report issues. Ryan, Codecademy's cofounder and CTO, put up a blog post explaining the reasons behind the downtime. Lots of users reported no problems and offered to lend a hand to help out - thanks! It's amazing to work with such a receptive and helpful community.

SWEATING THE SMALL STUFF

After bringing the site back online, we dedicated Thursday and Friday to working with our users to recover their data based on the feedback we got through email, Twitter, Facebook, and the form we designed. We know how important progress, points, and badges are to our users, so we have spent the past couple of days getting everything back to normal. Tonight, we're running a final script and the site will be down for 15 minutes as we add in a small amount of data that should affect only a handful of users.

We know downtime is not good for our users and we are not proud of it. That said, it happens to everyone. Great companies we admire like Etsy and Twitter have had downtime issues in the past. What's most important is how they handle themselves afterwards.

Everyone who was affected by data loss will get a special Codecademy badge.

BUSINESS AS USUAL

Thanks for bearing with us after this outage. Going forward, we've implemented a lot more policies internally to make sure this never happens again. We've increased our daily backup schedule and, in some cases, started backing data up more frequently. Our backups are redundant across several data sources. After this experience, we've practiced how to recover from many circumstances - data loss, downtime, etc. We want you, our users and learners, to be confident that Codecademy is the best place to learn to code whenever you want to learn. We're back to building new features and working on old ones - check back next week for more announcements!