把截图API背后的运营做成生意：ScreenshotOne

客户看不见的告警

2025年7月17日，运营ScreenshotOne的德米特罗·克拉孙（Dmytro Krasun）收到一条奇怪的告警。通知说，用真实浏览器打开网页并截图的巡检任务出现了超时。其他监控项都没有异常，客户的请求也在照常处理。为了找出这个客户看不到的问题，克拉孙好几天没睡好觉。

他检查了请求量和服务器负载，回滚了最近改动的代码，还排查了网络连接。把范围缩小后发现，问题出在用作巡检目标的外部网站访问不稳定。把截图对象换成自己的服务介绍页后，一切恢复正常。经过这件事，他确认了巡检环境需要由自己掌控，并完善了诊断工具。

一张截图背后的处理工作

克拉孙在2022年5月推出ScreenshotOne，这是一个API：其他程序把网页地址或HTML发给它，它就返回截图或PDF等结果。创业之前，他做了十多年服务器和高并发请求系统的开发。他选择了人们已经在付费使用的截图市场，决定由自己承担浏览器管理和页面生成过程中的各种问题。客户只要为自己产品需要的图片发出请求，背后的工作就可以交给ScreenshotOne。

开发者自己做截图功能，可用的工具早就有了。用Puppeteer或Playwright自动操作浏览器，就能打开网页并保存图片。但要截取整个页面，就得把滚动后才出现的图片也加载出来；Cookie同意弹窗挡住正文时，还得额外处理。再加上要按客户要求调整窗口尺寸和保存位置，最初短短的代码就长成了要应对各种条件的服务。

ScreenshotOne把这些处理经验积累进了产品。根据官方产品介绍，用于处理Cookie横幅的规则和识别方式超过5万个。客户可以隐藏广告和聊天窗口，必要时还能调整页面的样式和行为。这种结构让各个开发团队不必各自解决相似的问题，而是共用专业服务积累下来的处理方法。

协作反馈工具BugSmash的案例，能看出开发团队愿意在哪个环节付费。用户输入要评审的网站地址后，BugSmash需要生成用于仪表盘和分享链接的预览图。这张图会直接展示给用户，所以被弹窗遮挡或者生成太慢都是问题。BugSmash把这项工作交给了ScreenshotOne。相比之下，另一项网站评估功能用的是Puppeteer；在2025年4月公开的案例里，BugSmash提到服务器管理和同时处理多个截图带来了负担。

记录用户留下意见那一刻的页面时，BugSmash用了另一种办法。因为要连浮动元素的位置和已经打开的弹窗一起保留下来，它选择在用户浏览器里截图，或者借助浏览器扩展。同一个产品里，生成预览图和记录用户当前画面的要求并不一样。ScreenshotOne负责的部分，是在服务器上反复打开网页，稳定地产出产品可用的图片。

接入流程也尽量替开发者省时间。快速开始文档里给出了带上网页地址和访问密钥发起请求的示例，还提供各种开发语言的集成代码。客户可以在仪表盘的试验页面里调整选项、查看结果。出错时会同时返回程序可识别的错误码和人类可读的说明，客户的开发团队排查失败原因也更方便。

让用量和成本对得上的基础设施

定价的设计是从很小的用量起步，再按实际需要增加。截至2026年9月，每月提供100次免费截图；每月17美元的基础套餐包含2,000次，每月79美元的成长套餐包含1万次。超出套餐包含的用量后，按各套餐的单价支付额外费用。基础套餐也能使用整页截图、屏蔽广告和Cookie横幅、生成PDF等功能，客户可以围绕自己需要的处理量来决定支出。

计费规则也把失败和复用考虑了进去。因为网络或浏览器错误而失败的请求不计入用量，直接返回已保存结果的缓存响应也不算作新的截图。在这种结构下，降低失败率和复用已经生成的图片，会同时影响客户的满意度和运营者的成本。这个关系，克拉孙是在实际运营中学会的。

最初，请求通过Cloudflare转发，已经生成的截图存进缓存里复用。但缓存中的图片一旦消失，同一个请求就得重新启动浏览器来生成。当时免费提供给客户的缓存请求实际上产生了页面生成成本，克拉孙说自己因此在亏钱。于是他把文件存储服务R2加为第二层存储：即使近处的缓存里没有图片，也能从存储中取出并返回。

后来，在前端处理请求的Cloudflare Workers承担的职责也变多了。它先检查格式错误的请求和无效的访问密钥，再判断是否超出了允许的请求量，避免不必要的任务传到浏览器服务器。主服务器过载或页面生成失败时，请求会被转到其他数据中心。客户只是发出一个网页地址，服务内部却在判断该在哪里处理这个请求、该复用哪一份结果。

进入客户业务流程的API

有了这样的基础，同一个客户的合作才能持续多年。制作销售个性化视频的RepliQ在2026年7月公开的案例中表示，他们使用ScreenshotOne已有约4年。用途是把潜在客户的网站或个人主页做成图片和动态GIF，放进视频背景。RepliQ说，这样减少了维护自建截图系统的工作，可以把精力放在视频个性化上，自家服务增长期间也一直保留了这套集成。

克拉孙还公开了自建截图API的方法。他的开发指南涵盖了请求校验、Cookie横幅处理、整页截图，一直到上传存储和部署。读者既能看到自己可以实现到什么程度，也能看到还需要额外管理哪些工作。这类文档在向潜在客户解释技术的同时，也提供了判断该自建还是交给专业服务的材料。

持续公开开发过程也影响了产品的采用。AI任务自动化服务Toolhouse的联合创始人奥兰多·卡洛萨卡斯从早期就在X和Indie Hackers上关注克拉孙的动态。他说，当自己需要网页截图功能时，最先想到的就是ScreenshotOne，几乎没有去比较其他服务。这是一个当时没有购买理由的人，一路看着产品的变化，直到自己业务需要时才做出选择的案例。

在Toolhouse的接入过程中，文档和试验页面再次发挥了作用。卡洛萨卡斯把ScreenshotOne的文档交给AI工具，让它整理实现步骤，又在仪表盘里试了各项选项。接入之后，Toolhouse用户只要连接自己的ScreenshotOne访问密钥，就能让AI工作者截取并分析网页。原来的页面生成功能，就这样扩展成了为AI服务提供视觉素材的用途。

划定独自运营的范围

即使有人愿意付钱，克拉孙也会先衡量产品范围。按时间比较截图的功能他试过好几次，但很难减少把无意义的差异当成变化的误判，而且这更像另一个独立产品。爬遍整个网站并归档的功能，也因为客户的需求和运营方式各不相同而没有加进来。他说，自己选择的是集中精力让现有功能稳定运行。

在销售环节上，理解客户花的时间比预想更长。在2026年的一次采访中，克拉孙说自己用了2年才弄清产品是卖给谁的，这份理解影响了宣传文案、内容、开发事项和定价。之后他按获客渠道分别观察访客注册、注册用户转为付费客户的过程。他说，把访客不足和访客有但不下单这两种情况区分开，从出问题的环节开始修改，对收入增长很有帮助。

要让运营持续下去，克拉孙本人日常的介入也必须减少。他公开说，自己在2024年3月准备了一张专门用于业务支出的卡，并把结算款设置成自动转入这张卡的扣款账户。他还搭好了按请求量扩容服务器的环境，并在另一家云上准备了备用运行环境。这些工作是把支付费用、扩充服务器之类反复要做的事自动化，让自己暂时离开时服务也能照常运行。

需要的专业工作，他也会借助外部帮助。在目前的官方介绍里，克拉孙说自己一边亲自开发和运营产品，一边在特定项目上跟专家合作。产品方向和客户关系由自己掌握，需要的工作则加上别人的能力，这是一种以创始人为主的运营方式。

2026年3月接受采访时，ScreenshotOne的付费客户超过800名，月度经常性收入（MRR）超过2.5万美元。之后在发布四周年时公布的数字是付费客户超过1,000名，月度经常性收入3.3万美元。累计API调用也超过了1亿次。把网页变成图片的功能进入了多个产品的日常工作，客户的重复使用支撑着这项订阅业务。

在四周年回顾中，克拉孙把几乎没有错过孩子们的重要活动算作自己的成绩。在那一年的采访里，他还说出了自己的目标：希望把运营自动化到能一周不上网去爬山的程度。这门生意替其他开发团队省下了花在截图系统上的时间，而如何为自己争取更多时间，成了接下来的课题。