Build Your Startup MVP With Tools You Know
Nearly every system can be automated with software. But, our team builds as many manual systems as we can in order to understand what should be automated. For every idea that our team brings to life, we evaluated three other ideas that didn’t go anywhere. In this article, you’ll read about a variety of startup MVP examples built by non-technical startup founders, who brought their ideas into reality without writing a single line of code. They built solutions using the tools they already know how to use, like email, text, Google Docs, and Google Sheets. By the end of this article, I hope that you’ll have greater confidence knowing that you, too, can build your startup MVP with tools you already know how to use.
For the sake of consistency, I will use the term “startup MVP” to describe the types of prototypes that you’ll be reading about. MVP stands for minimum viable product. If you’re reading this article, you’re probably familiar with Eric Ries and his lean startup philosophy outlined in The Lean Startup. (When I read this book eight years ago, it changed how I think about building products and services.) While a lot of definitions exist for what a startup MVP tangibly is, our team prefers to think that a startup MVP is a process of how to build products and services. In essence, the startup MVP process is no more complicated than a series of trial-and-error experiments used to determine whether to take one step forward or one step back. Because they’re experiments, we’re always trying to test as cheaply and quickly as possible.
Why we teach non-technical founders to build startup MVPs with tools they know how to use
Our Tortoise Labs team teaches free, online classes to help entrepreneurs bring their own ideas into reality by helping them to identify customers, learn about what customers want to accomplish, and go to market with their idea. The vast majority of our class participants are first-time, non-technical founders. But, whether you’ve never written a line of code or you’re a highly competent software developer, building a startup MVP will help you to avoid wasting effort, money, and time building products or services that nobody wants to pay for. While I don’t think that there is a single perfect minimum viable product template, our process has worked well for our team and the startups we have helped to start and grow in Maine and throughout the country.
We especially enjoy working with predominantly non-technical entrepreneurs because it’s necessary for them to rely upon building startup MVPs over fully-fledged software solutions. And because non-technical entrepreneurs do not know how to program solutions, we teach them to manipulate the tools they already know how to use effectively. Generally, the startup MVP solutions we see rely upon a combination of email, text, Google Docs, Google Sheets, Google Forms, and a set of free and easy-to-use visual design tools.
It’s really hard to build something that people want, but we have found that the startup MVP process lowers entrepreneurs’ risk of spending excess effort, money, and time. I have always found that the best way to evaluate an idea is to sell it (and selling something tangible is even better). Bringing your idea into reality allows you to test whether people have a willingness to pay for your solution. People telling you they’ll pay you for your product or service is a sure way to find disappointment. Customers actually paying you for your product or service is a sure way to evaluate your idea.
When the MVP startup evaluation process does yield paying customers, it ultimately provides you a blueprint for an automated software solution. Without the crickets. Allow my previous inexperience to be a cautionary tale. The first time I had an idea that I wanted to turn into software, I spent months and months making something that nobody would pay for. In fact, nobody really even wanted it for free. Crickets for months on months. Eventually, the idea turned into a 6,000-person community, but only after starting over by using the startup MVP evaluation process.
Customers paying you for your product or service also allows you to gather feedback and quickly make improvements to your startup MVP that’ll immediately work (and be appreciated by the customers you’re serving). Because you aren’t reliant on making changes to a codebase, you can simply change how you’re delivering your MVP manually to your customers. Many first-time founders (who are building software) fail to understand the supreme characteristic of a startup MVP--it won’t have bugs. Software is inherently fragile. It breaks. A lot. Startup MVPs are resilient because they depend on you, not technology.
Without further ado, I hope that reading about a handful of minimum viable product examples prompts you to start building your own startup MVP.
How The Cubby relied upon deep customer research to build its first startup MVP
If you live in Maine, you’ve likely read about The Cubby’s recent string of exciting successes. The Cubby is an online marketplace for art made by college students, and they’re the recent winners of the Big Gig pitch competition and Top Gun’s Showcase, two of Maine’s premier startup competitions. But, before The Cubby evolved into one of Maine’s most promising startups, Josh Kim--the startup’s founder--needed to evaluate his idea. Josh started like many of the other non-technical, first-time founders we work with. He wondered how to bring an idea to life without any technical skills.
While The Cubby has evolved into the go-to home for college artists to sell their artwork, Josh initially built a product to help students buy and sell used items to other students on their home campus. Originally, the product was called Sklaza. Tailored to what students (and students alone) buy and sell, Sklaza was where students could find affordable futons, room decorations, coat hangers, fans, and microwaves. Think Craig’s List, but just for college students on their own campuses.
Before he even began building a startup MVP, Josh knew that he needed to become an expert about the people who he was building a solution for. He started by investigating how students could avoid transacting with his campus bookstore. Students buy expensive textbooks at the beginning of the semester. Then, students sell them back to the bookstore for a fraction of the price. The bookstore then turns around and resells the used textbooks at a significant markup back to students.
When Josh started learning about how students circumvent the bookstore to purchase textbooks, Josh was surprised by what he learned. While alternative solutions to the bookstore did exist, students were simply not pursuing them. We always teach entrepreneurs to focus on what people do, not what they say. Josh was surprised to learn that students were actively buying and selling all sorts of items with one another. Futons. Lamps. Wall decorations.
Josh learned that students were transacting constantly, which was unsurprising. What was surprising was the amount of difficulty students were having, despite being in close physical proximity to one another:
The administrator-built campus marketplace was exclusively used by faculty and staff to sell homes and cars. Students seldom even looked.
When students relied upon Craigslist, they often experienced dodgy interactions when they transacted off-campus with strangers. Students experienced similar apprehension when they used Facebook Marketplace.
Students almost always transacted only with friends and close acquaintances. Essentially, students transacted with the students who they could communicate with on their phones (because they already had contact information).
Customer interviews are essential to understanding startup MVP requirements
What did Josh find that students really want? For this, Josh learned about and implemented the Jobs To Be Done framework.
When students wanted to purchase something, like a futon or room decorations, they want to know if another student on campus is selling it, how much they’re willing to sell it for, what the item looks like, and who that person is so that they could purchase directly from instead of paying full-price from somewhere like Amazon or Walmart.
When students wanted to sell something, like a futon or room decorations, they wanted to know if another student on campus wants to buy it, how much they’re willing to pay for it, and who that person is so that they can sell directly to them instead of using market alternatives like the administrator-built marketplace, Craigslist, or Facebook Marketplace.
Before implementing a single line of code, Josh quickly devised a plan to learn whether students actually wanted the startup MVP (or if they just said they wanted it). In his 150 square foot dorm room, Josh collected all of the items that 50 students on campus were selling. He accumulated a small mountain of microwaves, fans, coat hangers, wall decorations, electric kettles, and futons. Josh documented how much students wanted to sell the items for, took a picture of every item, and added a small markup to every item to keep for himself. And then he set out to figure out if other students (en masse) really did want to buy these things.
They did. Before beginning to build an automated software solution, Josh’s startup MVP earned just over $10,000.
How?
Josh made a list in Google Sheets of everything he collected and began to sell what he collected by showing off everything that was available for purchase (and stored images on Google Drive). He posted on social media, shared on the campus-wide message board, and texted and emailed his friends. When students wanted to buy an item, Josh coordinated when and where to meet via text or email. To collect and distribute payments, he used Venmo.
Josh’s startup MVP stack was Google Sheets, Google Drive, text message, email, and Venmo. If you’re a non-technical entrepreneur, you probably use all of these tools everyday. Because Josh manually brought his idea into reality, he understood exactly what needed to be automated.
How Stimulus thinks of every system as a discreet startup MVP
Stimulus collects donations and distributes money to people who need help with basic needs like food, gas, and rent. The business distributes the entirety of the donation it receives, and it earns income through donation tips. To date, Stimulus has collected over $150,000 of transactions in the first three months of operation. Despite the startup’s impressive results, the Stimulus team still relies upon the startup MVP we built together. As their team is currently exploring funding options, they plan to build a fully automated software solution (and they know exactly what they need to build).
Early in 2021, Michael Arriola got in touch with our team about a great startup idea. The federal government was about to distribute $391 billion to American households in federal stimulus. Michael knew that many of the people around him didn’t need the money they were about to receive. Michael also knew a number of people around him who desperately needed an incoming stimulus check in order to afford basic needs like food, rent, or gas. He wanted to create an easy way for people to distribute their stimulus checks to people who needed the money.
Michael shared his idea with our team, as well as a number of app requirements. The description of his intended build was rather complex and feature-rich. We ultimately decided the best solution possible was to build a startup MVP that would allow Michael to evaluate his idea by finding people who needed help with basic needs (as well as donors), experimenting with different ways to raise campaign money, and determining what parts of the product ultimately needed to be automated. Michael understood very quickly that whether he was building a startup MVP or a fully-fledged software prototype that the solution-type would not replace building partnerships, making feedback-based improvements, and ultimately satisfying the basic needs of the people who he set out to help.
Your startup MVP development can start manually then be automated
When we built the Stimulus MVP with Michael, the actual requirements were simple and straightforward. Simply, a visitor who landed on the page needed to understand a few things:
What is Stimulus?
How do I donate?
How is my donation being distributed?
How is my donation impacting others?
We built the first prototype in a week, and it connected a small number of apps:
Carrd served as the web platform
Square was used as a payment processor
Google Sheets was the database where donor and recipient information was kept
Zapier tied it all together.
In addition, we connected AddThis for social sharing, Fathom Analytics for analytics, Slack for donation alerts, and Twitter for posting when someone new donated.
Once the startup MVP was built, Michael’s entire focus was on finding people who wanted to make a donation to the recipients relying upon Stimulus. But, as the number of donations started to accelerate, Michael found himself running low on time (especially since he was still working in his full-time job) to complete tasks he was completing manually. So, we automated tasks one-by-one so that Michael could continue allocating as much of his time toward the things that definitely could not be automated, like building partnerships with nonprofit organizations, talking on the phone with recipients, and building slide decks for fundraising.
Michael is an excellent startup founder. He’s consistent, charismatic, and open-minded. What really stood out about working together with Michael was how he’d think of every facet of his business as a system to improve. He’d build a manual system and make incremental improvements based on customer feedback to the point when it was impossible to go any further manually. When Michael built a manual system that didn’t contribute to more growth or improved efficiency, he’d eliminate it. Because Michael focused on building manual systems instead of jumping immediately to automating software solutions, he didn’t feel attached to experiments that weren’t working. When a manual system did work, we worked with Michael to automate the discrete system. As the Stimulus team continues to grow their business, I’m positive that Michael will continue to think of each respective system as an opportunity to build a startup MVP.
How a startup MVP quickly led to a MVP software solution through cold email
Eariously is a SaaS solution that turns newsletters into podcasts. Our team has built a number of different text-to-speech software solutions for different types of customers (e.g. college students, commuters, and publications) under the Eariously brand to varying degrees of success. With this particular newsletter-to-podcast solution, our team started building a startup MVP, which has allowed us to experiment quickly with cold outreach to potential customers and led to a number of budding relationships with customers.
The Eariously startup MVP is reliant upon Google Docs, Google Chrome, WaveNet for Chrome (which is a Chrome extension), Transistor (which is a podcast publishing platform), Spotify (which hosts the podcast recording), and Square (which serves as our billing platform). Our team relies heavily upon cold email outreach to get in touch with potential customers, and a startup MVP has allowed our team to experiment much quicker with our outreach campaigns. To explain how our startup MVP works, I’ll first explain a bit about our cold email approach.
Whenever we’re working on a cold email campaign, we’re taking a plan-build-measure-learn feedback approach (sometimes referred to as lean startup steps). More simply, we’re guessing and checking.
Guess who the customer groups might be.
Send emails to potential customers with the objective of starting a conversation.
Determine which groups of people care most about the solution and understand why.
Double-down on the groups of potential customers who care and stop messaging the groups that do not care.
As you probably already know, Substack is growing like nothing else in the publishing space, so we assumed that it was a good place to start. It was. But, Substack has a lot of different people writing about a lot of different things. What we ultimately discovered after the first month of experimentation was that Substack authors between 5,000 subscribers and 50,000 subscribers cared most about our solution.
So, how ultimately did we learn this and how did we test our startup MVP?
Dave Gerhardt is one of my favorite people to learn from, and one of my favorite lessons from him is that the goal of a cold email is to start a conversation. The best way to start a conversation is to ask a question that can provoke a yes or no response. That is, the less effort that a potential customer has to put into responding to your message, the more likely that person is to respond. Of course, your message needs to be specific to the person receiving it, and they should feel like it was sent to them and only them.
The additional benefit of this sort of email campaign is that the potential customer can experience the product and determine quickly whether it’s something that they want to pay for. In effect, this cold email campaign is a direct outreach demo. Our team manually converted the potential customer’s newsletter into a podcast with Google Docs and WaveNet for Chrome, added the mp3 to Transistor, and then sent the Spotify link to the potential customer. When potential customers wanted to become customers, we sent them a recurring Square invoice and asked for their newsletter publishing schedule. Whenever they’d publish a newsletter, we’d manually create the podcast episode.
The Eariously startup MVP required constant communication with customers (in order to let authors know when their newsletters were converted to podcasts), which meant gathering continuous feedback and deepening relationships with customers. Very quickly, customers become comfortable with offering critical feedback and asking for improvements. By the time the Eariously SaaS product will be released, our team will have several case studies to show off to potential customers. Case studies are a highly effective way for your potential customers to see how customers like them are benefitting.
Because this particular cold email campaign was so effort-intensive, it took up a lot of our team’s time. But, it was well worth it. The campaign yielded our first customers, allowed us to start deepening relationships with excited customers, and set up the foundation of various partnerships beginning to materialize. As always, through our experimentation of delivering the startup MVP to customers, we discovered exactly what needed to be automated.
Get in touch if you need help building your startup MVP
Ideas are important. But, ideas are the potential energy of building products and services. I hope that this article helps you to convert your potential energy into kinetic energy by starting to build your startup MVP with tools you know how to use. If you’re not sure where to start, I’d love to help.
Happy building!
Below are links to additional reading about startup MVPs that I couldn’t quite fit into the article:
The Business Model Canvas: While we do not teach explicitly about business plans, participants in our classes do use Alex Osterwalder's Business Model Canvas or the lean canvas (which is quite similar).
The Manual-First Startup: Vinicius Vacanti shares exactly why he started building a manual startup MVP, and he shares some examples of behemoth businesses that first started the same exact way.
Do Things That Don’t Scale: You’ve probably heard this phrase before, and this is the original article from Paul Graham. As you’ve read here, a startup MVP most definitely does not scale.
Don’t Serve Burnt Pizza (And Other Lessons in Building Minimum Lovable Products): JZ Zhang’s article is a comprehensive outline of ensuring that the startup MVP you’re building ultimately tests what’s most important.