I Built a Product Using Only AI Coding Tools

Status: Planned experiment — results will be added after the test is actually run.

Hypothesis

AI coding tools can significantly reduce the time required to build a small production-quality product, but the real constraint may shift from typing code to reviewing, debugging, and making architectural decisions.

Experiment

Build a defined product using AI coding tools as the primary implementation method and document where human intervention is still required.

What we will measure

• Total build time
• AI-assisted development time
• Human coding time
• Number of iterations
• Bugs discovered
• Rework required
• Product features completed
• Infrastructure cost
• Final quality

Results

To be completed after the experiment.

What we learned

To be completed from the actual experiment.

Real AI-assisted build data

One of the clearest public examples is BuzzerBee, built by Darren, a product manager from Vancouver.

Darren had a simple personal problem: missing apartment buzzer calls.

Instead of waiting for a technical cofounder, he tested whether the underlying phone workflow could be automated.

The first experiment used Twilio.

Source: https://blog.techforproduct.com/p/how-this-pm-built-an-1800-arr-saas

The build sequence

The product was not created in one perfect AI session.

The process was iterative.

First, Twilio was used to test automatic call answering.

Then a prototype was built in Bolt.

That prototype became messy and had to be restarted.

The rebuilt product moved into Cursor for the production application.

The reported timeline was approximately three weeks from proof of concept to working product.

That is a much more realistic picture of AI coding.

AI shortened the implementation loop.

It did not remove debugging, architecture, product decisions, or rework.

The product

BuzzerBee automates apartment-building access.

When someone buzzes the apartment, the system can answer the call, press the required unlock digit, grant access, and notify the resident.

The workflow is narrow.

That matters.

AI coding tools become much more useful when the problem is clearly defined.

A builder does not need to ask AI to create an entire “smart home platform.”

The builder can ask it to implement one specific workflow.

The business result

The public case study reported:

• 30 active customers
• $150/month revenue
• $50/month operating cost
• Profitability from the start

The numbers are small, but they are real business signals.

Thirty people using a product is more informative than a beautiful prototype.

$150/month proves that money can change hands.

$50/month operating cost provides an early view of the economics.

The product can now be improved based on actual behaviour.

A second real example

ScreenSmooth is another useful case.

The founder built a Chrome extension that automatically adds smart zooms and smooth cursor movement to screen recordings.

The founder described starting as a beginner with Chrome extension APIs and learning technologies such as canvas manipulation, WebRTC screen capture, mouse-path smoothing, and AI-based action detection during the build.

Source: https://news.ycombinator.com/item?id=47306290

The founder reported $239 in revenue during one seven-day period, a 405% increase versus the previous period, and more than $434 in lifetime revenue at the time of the post.

The product was built locally and distributed organically.

The founder also described an important distribution event: Marc Lou purchased the product and shared it, producing a large spike in attention.

What the two cases have in common

Neither story is simply “AI wrote the code.”

Both followed a loop:

problem → prototype → implementation → real users → feedback → iteration

That is the real experiment.

AI coding tools reduce the cost of the implementation step.

They do not replace the other steps.

The hidden bottleneck

When coding becomes faster, judgment becomes more important.

A builder still has to decide:

• What should be built?
• What should not be built?
• Which API is reliable?
• How should errors be handled?
• What does the user actually need?
• When is the product ready to launch?
• What should be fixed before adding another feature?

This is why BuzzerBee's restart is valuable evidence.

The first prototype becoming messy is not a failure of the experiment.

It is part of the experiment.

The builder learned that speed without maintainability can create rework.

What to measure in an AI coding experiment

A proper experiment should record:

• Total calendar time
• Human coding time
• AI-assisted time
• Number of prompts or iterations
• Bugs introduced
• Bugs fixed
• Rework
• Features shipped
• Infrastructure cost
• API cost
• Active users
• Revenue
• Retention

Without those numbers, “built with AI” is mostly a marketing claim.

The business lesson

BuzzerBee reached 30 active customers and $150/month.

ScreenSmooth generated $239 in one reported seven-day period.

Neither became successful simply because an AI model generated code.

The products had a specific problem, a usable solution, and a distribution path.

AI made the cost of reaching that point lower.

That is the real opportunity.

Result summary

The documented cases show:

• BuzzerBee: 3-week build, 30 active customers, $150/month revenue, $50/month cost
• ScreenSmooth: $239 reported revenue in 7 days, +405% versus the previous period
• Both used AI-assisted development as part of a broader product-building process.

Lesson

The interesting question is not:

“Can AI build a startup?”

The better question is:

“Can AI make it cheap enough to run more product experiments?”

That is a much more useful benchmark.

If AI cuts implementation time while the founder continues measuring users, revenue, bugs, and retention, the result is not just faster coding.

It is faster learning.

Sources

• https://blog.techforproduct.com/p/how-this-pm-built-an-1800-arr-saas
• https://news.ycombinator.com/item?id=47306290

Why “only AI coding tools” needs a careful definition

There is an important measurement problem in AI-building experiments.

What counts as “only AI”?

If a founder uses Cursor for code but manually designs the product, configures infrastructure, reads documentation, fixes production incidents, and writes the product requirements, the experiment is not actually measuring autonomous software development.

It is measuring AI-assisted development.

That is still valuable.

In fact, it is probably the more useful experiment for most founders.

The relevant comparison is not human versus AI.

It is:

traditional workflow versus AI-assisted workflow.

Measure the time required to reach the same product quality.

Measure the amount of rework.

Measure the number of bugs.

Measure the cost of AI usage.

Measure whether users actually care about the result.

BuzzerBee is a strong example because the builder still made the product decisions and had to restart a messy prototype.

ScreenSmooth is another useful example because the founder had to solve difficult technical problems around recording quality and cursor movement even while using AI-assisted development.

The data suggests that AI can compress implementation, but it does not eliminate product judgment.

The best AI coding experiment therefore measures learning speed, not just code-generation speed.