From 0 to $1,000 per month: Coding when I am certain that customers want a feature

In this blog post, I will share how I always made sure to start building features that my users wanted, not those I imagined – Even if they felt like a “must-have.”

Today, my side project GetMyMFA generates more than US$ 1k in Monthly Recurring Revenue(MRR). I consider it a good example of the “build things that people want” mantra.

As someone close to many “entrepreneurs,” I have always been amazed and frustrated to see close friends and people around the world code for hundreds of hours features and projects that end up never being used. When I came up with the idea for GetMyMFA, I promised myself only to start coding when I was CERTAIN my code would be used by actual customers (which shouldn’t be friends and family).

Although GetMyMFA is just a side project, I have tried to work on it following the same principles I would if I were building a real startup.

TL;DR – Confirming user needs before coding

1. Make it easy for your users or prospects to express their interest in a product or feature (either through a neat landing page, feature/plan upgrade buttons, etc.)
2. When receiving a customer request, contact them directly to confirm the need, the pricing, the urgency, and the onboarding process.
3. When receiving a confirmation, provide an estimated availability date and start coding. You are almost sure that your user will use your service!
4. Onboard your newly acquired customer. Congratulations! You have coded a feature you were certain at least one customer wanted, and you only started coding when you were almost certain someone would use your product.

Introduction: "Build things that people want" to the extreme

I am a big fan of Paul Graham (PG) and the entrepreneurship ecosystem around YCombinator (YC) and similar organizations. Even if it might look like an obvious statement, what struck me the most when reading PG’s essays or listening to YC podcasts was that startups that succeed would (mostly) always follow this simple sentence: they built something people wanted.
When the idea of GetMyMFA was discussed and felt like product potential, I wanted to ensure that I was building something people wanted and not something I wished people wanted. I wanted to make sure to fail or succeed quickly and safely while building this product.

If you wish to understand what Multi-Factor Authentication Flows are and how GetMyMFA helps test these processes, you have some information on the product landing page and the user problems described in the following Apple developer forum question.

Although parts of GetMyMFA were initially developed to fulfill an internal business need (which gives a good indicator that other people might have the same need), I still wanted to make sure that I would only start building the product when I would be completely certain that people would be willing to pay for it.

This article will describe my steps to minimize failure and “waste” while growing GetMyMFA from scratch to an enterprise-ready SaaS product generating more than US$ 1K MRR.

"That is a good idea" vs "I am willing to pay for this feature"

A common mistake I see from close friends and people online is asking, “Do you think that X or Y would be a good idea?” or “If I build this, would you be willing to pay for it?”. There are two main problems with these kinds of questions. Firstly, those questions are very hypothetical and allow anybody to imagine whatever they want. On top of that, you are asking those questions to human beings who do not like saying “no” or discouraging people from their projects. The (obvious) result that you will get by asking these kinds of questions is people (almost) always replying, “Good idea!” and “Yes definitely” that will end up saying, “Eeeeh, not a good timing” when you ask them to pay for the service once developed.

With that in mind, I wanted to ensure that people interested in GetMyMFA would be willing to pay for it before even creating the product. My actions always had the same purpose: “How do I make sure that a potential customer proves to me that he’s willing to pay for my product without having developed any of it?”

Objective #1: Making sure people want the product: Getting potential users' attention

Since the beginning, I assumed that the users willing to pay for GetMyMFA were people with the same problems as me: Publishing an MFA-enabled iOS Application without compromising security and automating End-to-End tests with MFA flows.

Step 1: Showing a fully functional and enterprise-ready product

Without having developed anything, the first step I decided to take was to purchase a US$ 10 landing page template and present GetMyMFA as a private-beta SaaS product with the classical “Standard,” “Premium,” and “Enterprise” plans and the associated pricing. The features presented in the plans felt like “obvious” improvements, but the objective was to get the first users to purchase the standard plan.

The only thing a visitor could do was click on the Sign-up or Subscribe to beta buttons and share an email address to be part of the special list of “waiting users”:

By building a webpage with these characteristics, I wanted to make it look like the product was fully developed and ready to use (and used by many users).

It is worth noting that although a considerable amount of time was invested in Search Engine Optimization and ensuring that the website would be correctly crawled and seen by people, it was mostly accessed by the posts shared in Step 2.

Step 2: Sharing with the supposed target audience

Since the two main target audiences were the iOS App submitters and test automation users, I decided to share the website through the most appropriate channels: An Apple support comment and multiple Discord channels for iOS developers.

After posting those comments, I simply promised myself only to code something once I had an interested user who would explain their use case.

By September 30th, 2021, I would have an up-and-running landing page, a domain name, and the shared comments in the appropriate forums.

Objective #2: Making sure that interested users are ready to pay

Step 1: Confirming the user's interest

Ten days after my comments were posted, I received the first user signup requests. The next step consisted of contacting those users to ensure they were actual humans wanting to use the product. Here are the first emails I sent to the interested users:

Hello,
Thank you very much for the interest you are showing in GetMyMFA!
As mentioned on our website, we are accepting new users at a safe pace and in a responsible manner to ensure the maximum service quality is delivered during the coming weeks.
Before we can onboard you, we would like to ask you a couple of questions to better understand your business needs and expectations!
Could you please share with us some information regarding the following topics:

• In what context are you planning to use the solution? (for instance: external testing, iOS application submission, etc.)
• What features are you planning to use?
• How many virtual phone numbers are you expecting to actively use?
• How many SMS messages are you planning to receive per phone number?
• What billing plan are you expecting to request upon acceptance?

Please, do not hesitate to get in touch shall you require any additional information or if anything crosses your mind.
All the best,
Jonathan from the GetMyMFA Team

Let's focus on what I believe are the key elements of this email:

• I try to be transparent with the user regarding his request being noted, and some delay has to be expected.
• I do not explicitly share with the user that they are the first to request service access. However, I explain that we need time to ensure their onboarding meets certain quality rules.
• I request additional information to understand what the user wants and what they expect from my service.

As you can see, the email tries to show that the service is actively being used and is highly requested, which helps in comforting the user that he will not be “the first one” while also creating this “must join the club” feeling. I am convinced this approach is viable on “simple” projects such as GetMyMFA. If your product requires a high level of integration with your customers, I recommend being transparent with them as soon as possible during their onboarding.

I received my very first reply one day after sending that email 🥳:

In addition to the required elements, this first user was even friendlier and shared how they got to know GetMyMFA. This helped me know that posting through technical forums is the right approach(es) to getting to my target audience.

After receiving 2 replies from unknown customers, I decided that it was finally time to code a product that would match real user expectations (i.e., an iOS submission module).

Step 2: Coding

For those of us who have a tech background, this is the easy step. However, I kept something in mind, which can be summarized as follows: “What are the minimum features required to meet the expectations of my users as quickly as possible?”. This is the classical “MVP” approach which allowed me to list the following key features:

• A user should be able to purchase one single phone number;
• This phone number should be shared with Apple Reviewers for iOS validation purposes:
  • This means that I need to develop a module that would allow a user to create (and not even delete) a user linked to a phone number.

... And that is! NOTHING else needed development in my mind: no user settings management, password reset, dark mode, etc.

Step 3: Onboarding the first customers two weeks later

After completing the development of the MVP on October 25th, I onboarded my two very first customers, who ended up buying their phone numbers and using them to submit their iOS Apps to the AppStore. The “starter plan” concept was validated by strangers unrelated to me or my friends and family.

It is worth noting that the first customer that got in touch found an alternative solution since they could not wait for two weeks. Of course, getting a reply from customers can only minimize the risks up to a certain point! You shouldn’t forget that they do not owe you anything!

Objective #3: Growing the feature capabilities with the same approach

The sections and steps described previously allowed me to validate the concept and make sure that I built something that people do, in fact, want!

The next step involved applying this same approach to ensure product development and new features followed the right direction. I asked myself the following questions: How do I ensure that the next features I develop are the ones that my users want? In other words, how can I easily allow my customers to tell me what they would like to use next?

To answer those questions, I made sure that all the features were always visible and one click away from my users:

Step 1: Showing features that you believe should be developed

Below are screenshots showing some features displayed as available while still not developed. Since then, all the features have been developed as users have requested to use them:


When a user selects the required feature or plan upgrade, the following appears:


Step 2: Confirming the user's interest

Following the same logic, the next step was ensuring I understood what the user wanted when clicking the Upgrade button. In other words, I had users explain to me their actual use case:

Closing up

Final notes

This has been a successful side project because it met my main objective: All the coded features and plans were only developed after having clearly understood my user needs. In addition, I was able to push this logic further by only developing stuff that my users were willing to use and pay for.

This approach also helped me clarify the GetMyMFA use cases into three main categories, which all come from actual needs shared by customers:

• iOS and Android App submission
• Multi-Factor Authentication Test Automation
• Robotic Process Automation (RPA)

This article is presented as a story I can express and write coherently 2 years after starting the product. Note that many approaches were tried in between that either failed or did not work.

It is also important to note that although this approach feels great for side projects, I am still unsure if it is viable for complex projects such as regulated businesses or when targeting larger B2B contracts.

Finally, it is worth noting that applying this approach can also limit your ability to have users pay for features in a “self-service” way. I am convinced that I might have lost customers by not allowing them to easily access features and access plans (at least as long as one person hasn’t )

I hope this article inspired you to build things people want.

Current status

Currently, GetMyMFA has the following stats:

• ~90 users use the Starter plan
• 3 users are currently paying for the Pro plan
• 2 users are using the Enterprise plan
• 1010€ Monthly Recurrent Revenue