Matthew Wolfe

Speedrunning Product: Idea to Revenue in 4 Days

Sun, 15 Jun 2025 00:00:00 +0400

Building a revenue-generating SaaS now takes hours, not weeks. That changes the earliest phase of startups.

I decided to give myself a challenge. How fast can I turn an idea into a product and get someone to pay me for it?

Coming up with an idea was the hardest part. Given that my goal is to earn revenue quickly, taking a “solution” and trying to find a customer is not a good approach. Instead, the customer and their problem must come first. [1]

Admittedly, it took me a few weeks of aimlessly learning about topics I found interesting before I came across one worth working on. At some point during this process, I stumbled upon Dia-1.6B, a new text-to-speech (TTS) model. It supports voice cloning. Could I build a product that does this? [2] After searching the internet, it seems like there are a lot of existing products that do the same thing. I don’t see what I have to offer. Moreover, I am concerned about copyright issues.

While learning more about the TTS model space, I saw a post on X where the guy said he wanted a TTS API specifically to use for an online survival game he was developing. That intrigued me. I slid into Martin’s DMs to learn more about his use case.

Imagine playing a game where every NPC has a deep backstory and a unique personality. Or every player has their own Jarvis/AI assistant to answer questions and provide useful tips. That’s something I think should exist.

So given that:

Someone else has this specific need,
I think this would be awesome,

I want to do this.

Day 1 (June 7)

Martin and I discussed the current state of TTS products. Notably, many companies are using this technology for automated customer support. [3] ElevenLabs appears to have the best general-purpose TTS API offering. Their API is nice, but the pricing is ambiguous. Paying for credits upfront and being charged for overages seems to be a turn-off for game developers. Additionally, hyper-realistic voices aren’t necessary for most games, especially if building an in-game AI assistant.

With these ideas in mind, I wanted to put together a landing page that communicates my idea of what a good product in this space would look like. With one prompt, DeepSite generated the raw HTML for a nice landing page. Most of the design and style seen on the currently deployed landing page was generated by DeepSite using the following prompt.

`1`	`you are a startup founder CTO. Design the landing page for your realtime text-to-speech API for video game developers.`

I have some notion of how to build and deploy a product fast, but I used o3 with Deep Research to sketch out a plan with the full tech stack in order to get another data point.

You are a startup founder CTO. You have a product idea and want to validate it with potential customers. To do this, you want to build a landing page with a text-to-speech demo and an email waitlist. What tech stack will you build this landing page with? And how can you deploy it as fast as possible without much money?

I received some follow-up questions, including Should the TTS demo use your own model or can it rely on existing APIs?. I decided to use the ElevenLabs API for the demo (and eventually the v1 product). There’s no sense in spending months developing a custom model if I don’t know this is something people are interested in. And willing to pay for it.

o3 outlined a plan and long justification. I then opened up Cursor. I started a new project and added only the raw HTML from DeepSite into index.html. I added this to Agent Mode context with Claude 4 and gave the following prompt:

1
2

Using the provided @index.html as the design/template, turn this into a Next.js project using the following plan.
[Insert response from o3]

In a few minutes, the landing page was mostly implemented. It took some extra prompting to update it with my own branding, fix fonts, and tweak the copy. [4] The generated README included simple instructions for deploying the project to Vercel. [5] I sent the landing page to Martin and waited for his feedback.

Without these tools, the same work would have taken me up to a week to complete. The bulk of that time would be spent on design, where my skills are most lacking. DeepSite did this better than I could have done, with one quick prompt. The generated text content was also nicely written and saved me time.

Day 3 (June 9)

Monday morning, I woke up to a DM from Martin. It was exactly what he was looking for and he signed up for the waitlist. I started working on a usable API for him to work with. Additionally, I learned more useful information from Martin:

His use case involves each player having their own AI assistant. He uses another LLM to maintain the context of the user’s recent actions and respond to their questions on the fly.
Voice streaming is important. Waiting for my API to generate the entire audio clip and return it to the client is not feasible. This adds tremendous latency. Time to First Byte (TTFB) is the metric to optimize for.

To solve the first point, I used one of ElevenLabs' built-in robotic voices. To solve the second, the ElevenLabs API already supports streaming. I co-opted my landing page’s demo to also support an API endpoint [6]. It took some prompting and manual work to wrap ElevenLabs' Streaming API with my Kikashi streaming API. Claude kept generating code that processed the entire request at once but told me it was streaming chunks. Eventually, it worked.

After letting Martin try out the API, I got more feedback. He wants a specific voice. He sent me 20 example audio files which ElevenLabs allowed me to easily clone and add to my API.

First Revenue (June 10)

Martin is happy with the API. Some latency issues could be improved, but it’s already good enough.

“Will you pay me for this?”

“I’d love to.”

I sent a payment link for $50/month and Martin paid. [7] Choosing this price was somewhat arbitrary. I chose a fixed pricing model to ease concerns about ambiguous usage-based pricing. The price was chosen because it’s more than I’m currently paying ElevenLabs. Realistically, I expect two pricing tiers: One for the development phase and another for production. That is something I made up in my mind without talking to any developers or potential customers. The most important thing to keep in mind is that pricing is difficult. I do not know the answer, but I will continue to experiment and see what my customers are willing to pay.

Reflections

Could I have done this faster? Definitely. Much of the time I spent, not detailed in this post, was talking to more indie game devs. That didn’t help me get revenue quickly, but it did point me toward what I need to work on next. The point of this exercise was not simply to get paid quickly, but to do so in a realistic manner that allows me to turn Kikashi into something more.
I made an API wrapper. So what? From talking to more game devs, I can see that the major value proposition does not lie strictly in TTS, but rather in joining an agent/brain function with text-to-speech capability. Working with the ElevenLabs API provided me with a quick way to provide minor value and get feedback.
AI tools enable fast, high-quality code generation. The bottleneck for a lot of companies is no longer building product, but rather knowing what to build, go to market, and growth.

What’s Next?

More broadly, I think it is worth thinking about how viable this is as a business. Learning more about the gaming industry brings rise to some concerns.

Game dev is a hits-based business. Similar to Hollywood, there are few very large studios that make most of the money. Some indie game devs I talked to have been working on the same game for 4+ years without seeing revenue.
The most common monetization strategy is “buy-to-play,” where the developer sells their game for a set price and that is it. Popular games might extend this later on with DLCs or microtransactions. The important implication here is that the ongoing cost of maintenance (paying for servers & APIs!) becomes harder to justify for a lot of games.
Vendor lock-in. It’s a scary idea for indie developers to build a game around a third-party API. This is especially true if that API becomes a core part of the game. Open sourcing parts of the product could help alleviate some of the pain.
Latency is huge, particularly regarding AI capabilities. That makes the difference between an awesome implementation and a terrible one. I think this can be solved. If companies are already replacing customer support employees with AI, we can probably reduce latency enough to support gaming.

One company whose business I find interesting is Clockwork Labs, the creators of SpacetimeDB. Martin’s game is built on top of this DB/Server product. It is open source, well-funded (presumably), and generates revenue from hosting the service. This appears to provide a counter-example to most of my concerns.

Notes

[1] Solving a specific problem for a specific person is generally a better way to go about deciding what to work on. If you solve the problem well enough, you automatically have your first customer.

[2] It made me think of my current favourite Instagram account @fullstackpeter, which involves a TTS model generating speech that sounds like Peter and Stewie from Family Guy.

[3] Some great examples are Phonely and Bland.

[4] I still had to update some environment variables with my Supabase, ElevenLabs, and Google Analytics keys. The worst part about that was figuring out how to create a new “property” in GA. Lesson learned, always use PostHog for analytics.

[5] I used a domain I’ve been sitting on for a while because I thought it sounded cool. I have too many domain names.

[6] With a single hard-coded API key.

[7] First I tried signing up for PayPal and creating a subscription through them. Apparently, the business needs to be approved before that works. Instead, I signed up for Stripe as a sole proprietor and set up the payment link. The process with Stripe took about five minutes. Again, lesson learned.

About

Sun, 07 Aug 2022 00:00:00 +0400

Matthew Wolfe is a University of Waterloo alumni, former YC founder, and software engineer.

A Simple Ruby Gem Supply Chain Attack

Mon, 08 Aug 2022 00:00:00 +0400

A supply chain attack is where an attacker seeks to exploit an organization by attacking a weaker link in the supply chain which the organization depends on. No organization writes 100% of the code they use in their operations. There exist many external dependencies like open source projects, standard libraries, third-party vendor products, and the hardware these all run on. Each of these vectors can be attacked and so too can the organizations who are dependent on them. There are countless real-world examples of supply chain attacks where organizations suffer significant damage, including NotPetya (2017), the Target data breach, and the Solarwinds hack.

Motivation

Why am I doing this?

I see supply chain attacks as an interesting attack vector with a relatively low bar of technical knowledge required to carry one out. Note that this only applies to specific types, as “supply chain attack” is a very broad topic.
I want to explore how an attacker could inject malicious code into an open source project and what exactly the impact could be.
I want to share this investigation so I can flesh out my half-formed thoughts on the subject.

In this post, I’m looking into what the process of attacking the supply chain could look like in a Ruby on Rails application. In particular, Rails apps use external libraries in the form of Gems. I want to see how an attacker could inject a Gem with malicious code to exploit a dependent app.

All the code for this post can be found under two repos on my GitHub: the gem and the Rails app.

The Application

First, we start with a simple Rails application that takes input in a text field and checks if the value is an even number. But since checking an even number is “difficult”, we decide to use an existing Gem called evil_gem to do the work for us.

We add it to our Gemfile

`1`	`gem "evil_gem", git: "git@github.com:M4THYOU/evil_gem.git", branch: "main"`

and then run bundle install. Initially, the gem looks fine! It’s simply checking if the input is an even number:

class EvenChecker
    def self.is_even?(i)
        puts "checking if #{i} is even..."
        res = i.even?
        puts "#{res}"
        res
    end
end

Then our controller for this page is

class HomeController < ApplicationController

	def index
		if params.has_key?(:query)
			@query = params[:query]
			unless @query.nil?
				@res = EvenChecker.is_even?(@query)
			end
		end
	end

end

So, except for the error thrown when the input is not a number, all is well!

The Malicious Actor

But now suppose a malicious actor comes along, call her Mallory, and opens a pull request on evil_gem. Or phishes the maintainer and takes over their account. Suddenly, Mallory can update the code this Rails application is dependent on.

Using a crap justification like “using OS commands and capturing the output is more performant than Ruby’s native even?, Mallory updates the Gem.

class EvenChecker
    def self.is_even?(i)
        puts "checking if #{i} is even..."
        res = (`printf "$((#{i} & 1))"` == "0")
        puts "#{res}"
        res
    end
end

Uh oh. Passing user input into backticks in Ruby is bad! The input can escape the quotes and execute arbitrary commands on the system running the app.

Now that the Gem is updated, the application is not yet vulnerable. The application owner must update the Gem in the project. In this case, the evil_gem’s version is not locked so just running bundle update will pull in the new malicious code.

It looks like the app still works:

But now let’s try a different input:

Technically, that is correct. And there is no indication anything went wrong on the user’s side. But looking at the server’s console we see the output of ls! The user has successfully injected malicious code into our application via an external dependency and can now use it to exploit the main application. This could be used to steal user data, get access to the web servers, and a lot more.

Prevention

How can this be prevented?

use a Gemfile.lock. Lockfiles ensure your dependencies don’t get updated without your explicit permission. If you’re secure today, you’ll be secure tomorrow.
Manually review every line of code when you update dependencies.

However, for the latter suggestion, that isn’t practical for most organizations! This would require a certain baseline knowledge of software security and an understanding of how most of that dependency works. This poses a problem because dependencies will often be updated with security fixes of known vulnerabilities so we can’t simply skip updates forever.

Additionally, security issues can still slip by those who have this security and context-specific knowledge. For instance, we might assume in a large open source project, like Rails, that there are already people looking over this code who meet these requirements. But some smaller projects are maintained by much smaller groups who may not know better. Moreover, malicious code can even be injected into the Linux kernel source so there is no guarantee that code is safe.

Next Steps

The next thing I want to learn more about is how to write software that is safer from attacks on the open source supply chain. Minimize dependencies? Just assume breach and work from there? What are the best practices? I think the level of security an organization must have in this regard depends on proper threat modeling, but balancing security and business needs is hard to do.

I think the important takeaway from the investigation is this: You might have the best phishing detection and account takeover protection for your own employees, but that doesn’t protect the open source developers or vendors with access to the critical code you depend on.