Validating my indie SaaS (enough to invest in an MVP)

by Andrew Askins 2 months ago 8 min read

Picking an idea to validate

When my then co-founder Matt told me about his idea to create a chart builder, I immediately got excited. We had decided to work together on a new bootstrapped startup and were trying to pick an idea to start with.

I was excited because the team at Krit had started a free chart builder years ago that we never finished (we jokingly called ours hippoplotamus). We built it because I was frustrated with trying to make modern, on-brand charts within Google Sheets.

Meanwhile, Matt had worked at Customer.io and Zapier in the past.

At Customer.io, he built automated report emails. Generating images of charts for the emails was a massive pain, and every time the marketing team wanted to change the design or content took time from the engineering team.

Then at Zapier, he learned about a couple of existing options the Customer Success team recommended to users, but both were very developer focused.

Matt saw the potential for a no-code chart designer paired with an image generation API so users could design charts and send them in automated emails.

At first, there were several reasons we liked the idea.

Pros to the idea

Founder / Product fit - Matt and I both liked the idea and had personal experience to draw from.
Competition - Existing competitors indicated an existing market, but there were only a few, so it wasn’t overcrowded.
Differentiation - We had an idea for a clear wedge to differentiate us from the existing players.
High Intent Searches - There was search volume for people looking to solve the specific problem we were building for, but the keyword difficulty was low. Plus, there were more generic terms with high volume we might be able to leverage.

At the same time, we still had concerns about the idea.

The con of small competitors

The size of our competitors was the biggest concern. There were three close competitors:

Nifty Images
QuickChart
Image Charts

Of these three, QuickChart and Image Charts appeared to be run as side projects by their founders. Nifty Images was the only one that appeared to be successful enough to support a full-time founder and team, and they a broader focus.

Still, there were enough positive signals to explore further. Matt set to work building an MVP, and I focused on thorough validation.

The risks of building while validating

Note: We decided Matt would start building while I did more validation. Our logic was that Matt had less runway and would need a job sooner. As the technical co-founder, it would be good to leverage this period when he could be full-time building.

But in the future, I’d have both co-founders work on validation unless you can build an MVP REALLY fast (like 2-3 weeks).

The sunk cost fallacy is hard to fight. I think I’ve made good choices about ChartJuice, but can’t deny a part of the drive to keep going is a desire to finish what I started.

Our $700 landing page test

The first thing I did was a landing page test. I knew there were search terms that seemed promising, but I wanted to prove we could get and convert search traffic with them.

A landing page test is what it sounds like. You stand up a landing page, direct traffic to it, then measure conversion rates (although you likely won’t have anything of statistical significance).

I built a simple 4-page site in Webflow:

Homepage - Tease the idea, elaborate on the pain, introduce the solution, call to action.
Pricing - The primary call to action was to select a plan. This took the user to a pricing page where I offered a free trial, but only if the user picked a pricing plan. I wanted to make it clear they would be paying to use the product. On the pricing page, I outlined three plans: one for $49/month, one for $99/month, and an enterprise plan.
Schedule a demo - As a secondary call to action, I offered the option to schedule a demo with a Calendly link. I was hoping to talk to potential users this way.
Join our waiting list - If a user tried to signup I let them know we were still working on our MVP and offered them the chance to join the waiting list.

From there, I setup an ad campaign in Google and sent traffic to the site. In total, I spent $689 on 770 clicks, with an average CPC of $0.89.

Most keywords were generic and drove the majority of traffic due to their large search volume. But I got some traffic from more focused keywords.

Results

According to my analytics, 10% of the ~700 Google users clicked through to the pricing page, 7% to the demo page, and 1.7% tried to start a free trial.

I found that the average visitor to free trial conversion rate for Paid traffic is 7% or 2% depending on whether your trial is opt-in or opt-out. I made the initial site look like an opt-out trial. So, I felt like 1.7% for an unoptimized site with no screenshots or social proof was solid.

Concerns and questions

I was concerned that most traffic came from generic keywords, making it hard to tell if users were interested in our product or thought we were selling a generic chart designer. Still, they saw the pricing and clicked through.

I was also concerned that no one who went to the Demo page scheduled a call and no one who clicked the Free Trial page signed up for the waiting list. We presented the product as ready on the homepage, but told users it wasn’t ready on other pages. So I could understand users not wanting to waste time on a non-existent product.

Expanding on initial validation with user interviews

From there, I wanted to start getting qualitative feedback on the idea. I posted on LinkedIn about ChartJuice (then called ChartKit) and got a couple bites. Then, I made a list of founder friends and started reaching out to ask if they’d be down for a discovery call.

I had about 12 conversations with friends, and two showed interest in becoming customers later. More importantly, I started to pick up on patterns and refine how I talked about the product.

Feedback

I noticed that people who found the most value were running high-touch B2B startups where the buyer was different from the user. The pain they felt was around renewals and proving value to the buyer during renewal conversations.

We initially thought our ideal customer was a tech-savvy marketer, but most people responsible for email reports were founders or product managers. Although that’s also who makes up my network.

We planned to build the product in a way that it required no engineers to implement. We imagined users would store the necessary data in their email automation tools. They would then drop a ChartJuice link into an email template and use mail merge-style tags to pass us the information.

But no one I talked to wanted to keep this data in their email tool. They’d rather integrate ChartJuice into their existing transactional emails. So our messaging started to change from, “no developers required,” to, “reduce development time from weeks to hours.”

Concerns

While getting helpful feedback to focus our positioning, I also heard some concerning things. Everyone used a different set of email tools and a different data stack. So integrating directly would be a challenge.

More importantly, while automated report emails were on several teams’ roadmaps, they kept getting delayed due to other priorities, and there wasn’t much interest in adding charts once they were done. It became clear that catching customers at the right time would be a challenge. The already small market wasn’t very liquid.

Deciding to invest in an MVP

In early March, my co-founder had to step away from the project, forcing me to make a decision. I had data from the landing page test and user interviews. I had to decide if it was worth investing the time to build an MVP myself or if I should move on to a different idea.

Pros

Founder/Product Fit - I still liked the idea. And if I was going to get back into development, this fit my skillset well (I’m better at frontend development than backend, and this was a frontend-heavy idea).
Conversion rates - The rates were close to average with a totally unoptimized website.
Stickiness - It seemed like the product would be really sticky if I could convert people to customers, meaning LTV was likely to be high. And no one had balked at the price.
Potential customers - Out of 12 user interviews, 2 showed interest in adopting the product soon, with one in active sales conversations. It’s not a signed LOI, but like the conversion rates, it’s a decent signal.

Cons

Small, illiquid market - It was tough to catch users at the right time. And unless I could find another use case unrelated to software companies, the market was small.

Decision

Ultimately, I decided to build the MVP because I felt like there was enough signal to warrant more investment, and in the past I had given up on ideas to quickly. I wanted to test if the signals were red herrings or real, and improve my product sense. I aimed to launch the MVP by June 1 and started brushing up on programming again.

Where I am now and what comes next?

I finished the MVP by mid-June, close to my original goal. You can create an account and start designing charts right now.

I’ve really enjoyed getting back into programming, especially designing in the browser and moving fast to implement new features. The early stages of building are really fun.

I’m also testing a productized service designing and building automated email reports for customers. I’m cautiously optimistic that this service could solve the market’s liquidity problem, making it easier to adopt the product and generate revenue more quickly. If I’m right this could make the business sustainable much faster.

I still have concerns about the market size and the severity of the problem. But both of those issues have silver linings as well.

I’m working on implementing billing, and plan to ramp up ads and outbound email in the next couple of weeks. I’ve given myself until the end of August to test the market with a real product. If I’m not seeing traction by then, I will reposition the product or start looking for a new idea.

Sign up for my newsletter for honest, transparent content on the ups and downs of building a bootstrapped startup. Monthly issues include:

3 links about bootstrapped startups
1 original essay
3 fun links