# MVP as Research

> Published 2026-05-09 · By lawted (https://x.com/lawted2) · Published on HA7CH (https://ha7ch.com)
> Canonical: https://ha7ch.com/writing/mvp-as-research

## English

In the AI era, how should we ship a product?

Traditionally, when we want to build something, we start with user research. Then we write the requirements, draft the idea, do the design, develop it, test it, and finally release it. That was how big tech worked. And it made sense at that time, because the cost of development was high. If a product direction was wrong, the cost was serious. You couldn't really afford to be wrong.

But now I increasingly feel that for normal people, especially people who can use Claude Code and do vibe coding, this process is just too slow. At least fifty times too slow.

So what is the better way? I think it is: MVP as research.

Don't think too much at the beginning. Just build the thing you want to build. Build the ugliest version. Or build a version where you can at least look at it and say, "Okay, I understand what this thing is."

Because if you want to build it, that already means it is attractive to you. You want to use it, or you believe it might be useful. That is enough. Just build it.

Some of my friends always say, "What if I build this thing and someone has already done it?" Or, "What if I build this and someone comes after me? What if I get into legal trouble?"

And I usually say: after you build it, if someone really comes after you, then hire the best lawyer and fight the case. But if you don't even have the money to hire the best lawyer, why would they come after you in the first place?

A lot of the time, we are not blocked by reality. We are blocked by tiny-probability events inside our own head.

For example, I built Raily Friend in maybe two hours. I built CV.PRO in three or four hours. Raily took a little longer because it is an app, maybe a few days. But even so, compared with the traditional product development process, this speed is fucking insane.

I saw one data point before: Flighty spent about two years in beta, from 2019 to 2021. And I basically replicated the core feeling of it in around twenty days. This is AI coding. This is the AI era.

So I think the new process should not be: research first, then development. It should be: develop first, then use the launch itself as research. That is MVP as research.

You build the thing first, then post it on WeChat Moments. Because people in your Moments know you. They have some relationship with you. Many of them live in a similar environment, share similar interests, or have a similar mindset. So when you publish it, someone will jump out.

Some people will say, "This is wrong." Some people will say, "This is pretty good." Some people will give you suggestions. Some people will directly say, "Fuck it, I want to use this." Anyway, all of these are signals.

And the most important thing is: if you do user research first, you don't even know who you should research with. You don't know which motherfucker in your Moments is actually interested in your thing. But when you drop a real product out there, the interested people naturally come out.

At that moment, you can pull them in. Let them become your early users. Let them give you advice. Let them analyze it. Let them talk shit about it. Let them tell you why it sucks. That is much better than sitting there and imagining user needs by yourself.

And another thing I think is very important: don't make the product too perfect at the beginning. I know a lot of people talk about this, but I mean it in a very practical way.

You can build the product to 40 points, then package it like it is 60 points. If someone uses it, if someone complains about it, then you can hire another person, or hire an agent, or invest more time and money to push it to 80 points.

I once built a tool that could import my school timetable into iCloud Calendar. At the beginning, it was extremely simple. You had to run it with Python. That means if you didn't know Python, you basically couldn't use it. It was just a CLI.

But somehow, a few people were actually using it. And even more surprisingly, someone submitted a PR. That was the signal.

So I kept going. I reverse-engineered the school login system so students could log in directly with their student account and password. Then I posted it on the school forum. After that, hundreds, even thousands of students started using it.

So my understanding is simple: you should first drop the food on the ground and see if anyone eats it. If someone is willing to eat it even when it is on the ground, then you can give them a plate.

## 中文

在 AI 的时代，我们到底应该怎么去 ship 一个 product？

传统来说，我们做一个产品，可能会先做用户调研，然后写需求，做设计，开发，测试，最后再发布。以前大厂里面都是这么干的。因为当时开发成本很高，一个产品如果做错了，代价会很严重。

但是我现在越来越觉得，对于普通人来说，尤其是对于会用 Claude Code、会 vibe coding 的人来说，这套流程实在是太慢了。至少慢了五十倍。

现在更好的方式是什么？我觉得是：MVP as research。

你不要一开始想太多。你直接先把你想做的东西做出来。做一个最简陋的版本，或者说，做一个你自己觉得「OK，我能看懂这是什么」的版本。

因为只要你想做这个东西，就至少说明它对你自己是有吸引力的。你想用，或者你觉得它可能有用。那就够了。先把它做出来。

我有些朋友经常会说，哎，那如果我做了这个东西，别人是不是已经做过了？如果我做了这个东西，会不会有什么影响？会不会有人过来找我麻烦？

我一般就说，你等你做出来以后，他真的过来找你麻烦了，你再请最好的律师去跟他打官司不就完了吗？那如果你连请最好的律师的钱都没有，人家为什么要过来找你麻烦呢？

很多时候，我们根本不是被现实拦住了，而是被脑子里那些极小概率的事情拦住了。

比如我之前做 Raily Friend，可能就花了两个小时。做 CV.PRO，也就三四个小时。Raily 时间稍微长一点，因为它是一个 App，可能花了几天。但即使这样，这个速度跟传统产品开发比起来，还是快得离谱。

我之前还看到一个数据，Flighty 的 beta 阶段做了两年，从 2019 年做到 2021 年。

所以我现在觉得，新的流程不应该是：先调研，再开发。而应该是：先开发，再用发布本身来做调研。也就是 MVP as research。

你先把东西做出来，然后发朋友圈。朋友圈里面的人是认识你的，跟你有关系，很多人的生活环境、兴趣、认知结构也跟你比较接近。这个时候你发出来，就会有人跳出来。

有的人会说，你这个做得不对。有的人会说，你这个挺好。有的人会给你提建议。有的人会直接说，我想用。Anyway，这些都是信号。

而且很关键的一点是，如果你一开始就去做用户调研，你根本不知道应该调研谁。你也不知道你朋友圈里面到底谁会对这个东西感兴趣。但是当你把一个真实的产品丢出去以后，感兴趣的人自然会冒出来。

这个时候你就可以把他们拉进来，让他们成为你的早期用户，让他们帮你提意见，帮你分析，帮你骂你。这比你自己坐在那里幻想用户需求啥都不做要好。

还有一点我觉得挺重要的：一开始千万不要把产品做得太完美。

有的时候，你需要先把产品做到 40 分，然后把它包装成 60 分。如果真的有人用，有人骂，有人给你提 PR，那你再去招一个人，或者拉一个 agent 进来，把它做到 80 分。

比如我之前做过一个学校课表导入 iCloud 日历的工具。一开始那个东西非常简陋，甚至必须要用 Python 跑。也就是说，如果你不懂 Python，你根本用不了，因为它就是一个 CLI。

但这玩意儿还真的有几个人在用，而且竟然还有人给我提 PR。

所以我就开始继续往下做。我去逆向了学校的登录系统，让大家可以直接用账号密码登录，然后再把它发到学校论坛里面去宣传。后来，几百个人，甚至上千个人都开始用这个东西。

所以我现在的理解是：你应该先把食物丢在地上，看有没有人吃。如果丢在地上都有人吃，那你再给他安排一个盘子。