开发者增长档案 · 003

6 年磨一款,第二款 MVP 只用 1 天

从体育卡到宝可梦卡,Kyle 如何复用同一个问题模型,而不是重新猜一遍需求。

查看本期 8 张图解
6 年磨一款,第二款 MVP 只用 1 天,开发者增长档案第 3 期封面
约 6 个月Cardstock 从想法到完成,包含三个月暂停
1 天Kyle 提到的 Scanémon MVP 开发时间
同一闭环扫描、识别、估值与收藏整理

The story

故事从哪里开始

Kyle Fowler 收藏体育卡时遇到一个长期摩擦:离开家以后,他无法快速知道自己拥有哪些卡、每张卡值多少钱。App Store 里没有让他满意的工具,于是 Cardstock 从自己的需求开始。

第一款产品并不快。Kyle 表示 Cardstock 前后约用了六个月,其中还暂停了三个月。几年后,他把同一个“扫描—识别—估值—整理”模型迁移到宝可梦卡,借助 AI 工具在一天内做出 Scanémon 的 MVP。

这里真正产生复利的不是生成代码的速度,而是已经验证过的任务结构、数据处理经验和用户理解。

From idea to revenue

产品走过的六个阶段

1

想法

从自己的体育卡收藏出发,发现离开实体卡册后无法查询持有情况和价值。

2

验证

Kyle 自己是第一个用户,先锁定扫描、查询和整理三个高频任务;访谈没有提到正式预售或落地页测试。

3

开发

Cardstock 使用 Swift、SwiftUI 和 Core Data,后来接入 AWS EC2;第二款产品复用了任务模型和大量已有认知。

4

上架

完成后在 Reddit 发布进展并获得首批下载,让垂直社群直接看到解决方案。

5

增长

用 TikTok 轮播展示视觉性强的卡牌内容,先在自有账号验证观看和下载,再考虑扩大分发。

6

变现

扫描、价值查询和持续整理形成长期使用理由,两款产品都通过应用内购买收费。

Growth mechanics

增长为什么发生

记录长期摩擦

不是追逐临时热点,而是把自己反复遇到的问题沉淀成产品线索。

复用问题模型

第二款产品更换用户和卡牌数据,但保留已经跑通的核心任务。

渠道匹配题材

收藏卡本身适合视觉展示,轮播内容可以直接呈现识别和估值结果。

What to learn

给独立开发者的结论

从这个开发者故事里,我们可复用的是:

记录自己长期反复遇到的摩擦,先打通一个高频闭环;当任务模型被验证后,再迁移到需求相似的相邻人群。

但不能照抄的是:

“一天 MVP”建立在多年产品、数据和用户理解之上;没有前一款产品的积累,AI 生成代码并不会自动带来同样速度。

1

今天就能做:列出你产品里最稳定的三个动作,找一个用户不同但任务相同的相邻场景,画出一版迁移后的最小闭环。

Visual story

用 8 张图看完整故事

开发者增长档案第 3 期图解,第 1 张 01 / 08 开发者增长档案第 3 期图解,第 2 张 02 / 08 开发者增长档案第 3 期图解,第 3 张 03 / 08 开发者增长档案第 3 期图解,第 4 张 04 / 08 开发者增长档案第 3 期图解,第 5 张 05 / 08 开发者增长档案第 3 期图解,第 6 张 06 / 08 开发者增长档案第 3 期图解,第 7 张 07 / 08 开发者增长档案第 3 期图解,第 8 张 08 / 08
来源与数据说明

开发周期、收入和渠道效果来自 Kyle 的 Starter Story 访谈。访谈标题中的合计收入与分项数字不能完全对应,因此本文不把它作为核心结论。