Extension, plugin, or bot: picking the format for product one

Today I didn’t write a line of code. The whole day went into deciding what format the first product should take. The challenge itself starts October 1, but the format decision shapes what I show up with by that date, so I sorted it out early.

Five options on the table

I compared five categories: a Chrome extension, an Obsidian plugin, a Notion integration, a Telegram bot, a mobile app. No specific idea behind any of them yet — I was comparing formats, not products.

Six axes: build speed, distribution, how much friction a new user hits, monetization, competition, and expertise I already have.

Chrome extension

Pros: distribution is built in — the Chrome Web Store is a ready-made storefront with search and reviews, no ad budget required. Low friction for the user: install it and it already works on top of sites they already use.

Cons: Google’s review timeline is unpredictable, and Manifest V3 policy occasionally breaks what worked yesterday. Monetization inside an extension is awkward — no built-in subscriptions, so you end up wiring an external billing backend. I have almost no experience here: week one goes to platform quirks, not the product.

Obsidian plugin

Pros: the audience is small but paying and active — post in the plugin directory or the community forum and people actually looking for a tool find it fast. Technically simple: TypeScript, a local API, no backend, no server costs.

Cons: the Obsidian crowd skews technical and likes free, so plugin monetization tends to be donations, not subscriptions. The plugin market is small and mostly saturated already — notes, tasks, graph views are covered by dozens of existing tools.

Notion integration

Pros: Notion has an API and a growing integration marketplace, and the audience is used to paying for automation around their workflows.

Cons: the Notion API isn’t a runtime platform — an “integration” usually means a separate backend hitting Notion’s API. That’s closer to its own service than a plugin you build in an evening. Competition among Notion tools is real, and plenty of niches are already held by teams with budget. No expertise with the Notion API either.

Mobile app

One pro, but a big one: the widest potential audience of any option, purely by phone ownership numbers.

The cons outweigh it: the longest build cycle and the highest friction for a new user — store install, permissions, maybe a signup, for a product with zero reviews yet. App Store and Google Play mean review queues, a developer account, and either two native codebases or Flutter/React Native on top. None of that fits in fifty hours, ever. Monetization is possible but needs the stores’ payment infrastructure set up first — one more layer before the first payment. No direct mobile development experience.

Telegram bot

Pros: distribution is a link, not an install — someone clicks and the product is already open, nothing to download. Payments are built into the platform: Telegram Payments and local providers cover billing without a separate card-processing backend. Friction for the user is lower than a mobile app and comparable to an extension.

Cons: competition in the popular niches — reminders, trackers, assistants — is high, so this needs a narrow, specific pain, not a clone of an existing bot. The whole thing lives on someone else’s API: if Telegram changes bot policy or bans in bulk, the product depends on decisions I don’t control.

This is where I have the most experience: I’ve built Telegram bots in Python both at work and in side projects. I know the architecture and where week two usually gets painful.

What I picked, and why

On paper, mobile has the biggest audience and plugins have the lowest build bar. But I’m using the same principle as the idea filters from the last post: fifty hours per product means time spent learning a new platform comes straight out of that budget.

Telegram bots are the only format where the fifty hours go to the product, not to learning the platform. Experience removes the risk on three of the six axes at once — build speed, distribution, and user friction are solved by the format, not by me. So that’s the default for the first few of the twelve — not because it’s objectively the best format, but because it doesn’t burn time on things I already know.

I’m not ruling the others out completely. If one of the ideas fits a Chrome extension or an Obsidian plugin objectively better, I’ll build that one — just accounting for a first week that goes to the platform instead of the product.

What’s next

The start date hasn’t moved — October 1, as I wrote earlier. Until then I’m looking for places to validate ideas: niche forums, Telegram channels, YouTube. The next post is probably about where the ideas for bot one come from.

← All posts