Choose your ecosystem

Decide where the product lives

You shaped a product direction in the last chapter. Now decide the shape underneath it: where it lives and what form it takes.

"What kind of app is this?" is really two questions stacked. Where does it live (which ecosystem), and how is it shaped (mobile, web, SaaS, marketplace, wrapper, or no app at all). These choices change UX, infrastructure, distribution, and what customers expect. Get them wrong and you fight the platform for years.

By the end, you should have:

• where the product lives (standalone or an ecosystem)
• the form it takes (web, mobile, desktop)
• the shape (SaaS, marketplace, internal tool)
• whether it's consumer or enterprise
• whether it's a real product or a thin AI wrapper
• an honest check on whether it needs to be software at all

1. Standalone or an ecosystem

Most products live somewhere. Either standalone, a regular web app at its own domain, or attached to an ecosystem: a Shopify app, a Figma plugin, a Slack bot, a Custom GPT, a WordPress plugin.

Picking an ecosystem isn't required. Plenty of strong indie products are standalone web apps. But if you build on one, you inherit both its distribution and its constraints. Be deliberate about which one you join, and whether the actual buyers for your product live there.

Here's a rough map of where products live today.

2. Weigh the ecosystem tradeoffs

If you do build on a platform, weigh what you gain against what you give up.

The strongest ecosystem play is usually one where the platform's distribution outweighs what you give up in margin and control. The weakest is building on a platform purely because you happen to know it, without checking whether your buyers are there.

3. Mobile, web, or desktop

Most products should default to web. It's the fastest to iterate, the easiest to install (just a URL), and the least gated by app store reviews and platform politics. For most early-stage indie products, especially anything workflow-shaped, web is the right call.

Mobile makes sense in specific situations: when the work happens out in the world, when notifications are core, when the user is walking around, photographing, scanning, or checking in, or when your audience genuinely lives on their phone.

Desktop apps are less common but still relevant when the workflow is heavy enough that the browser becomes a constraint (design, dev, audio, video work) or the audience is technical enough to install one without complaint.

The deeper question isn't "mobile or web." It's where the user is when the pain hits. If you can't answer that, the use case isn't sharp enough yet.

4. SaaS, marketplace, or internal tool

Three different shapes, three different problems to solve.

SaaS is the most common form for indie founders and the easiest to start. One repeat workflow that many customers each get value from. You build once, sell many. The hard part is finding the workflow worth charging for, which is most of what this manual is about.

Marketplaces look exciting and are dramatically harder than they look. You're building two products at once, supply and demand, and you need both to grow together or neither works. Rarely a good first product unless you already have distribution to seed one side.

Internal tools live inside one company and don't need polish, marketing, or onboarding the way customer-facing software does. If your idea is solving a problem at a single company, an internal tool might be the right form, and it might never need to become a product. That's a valid outcome.

Be honest about which you're actually building. The shape determines pricing, audience, support load, and growth strategy.

5. Consumer or enterprise

These aren't the same business with different price tags. They're different products.

Consumer products win on speed, simplicity, low friction, and emotional appeal. Users decide in seconds. The cost of confusion is immediate churn.

Enterprise products win on reliability, depth, integration, and trust. They take months to evaluate. But "enterprise" isn't just "charge more." It implies permissions, audit trails, SSO, security reviews, compliance, and account management. If you don't want that life, don't accidentally choose that buyer.

The dangerous middle is mid-market: tools that have to deliver consumer simplicity and enterprise reliability at once, on limited budgets. A real place to operate, but harder, not easier, than picking a clear lane.

6. AI wrapper or real product

A lot of products launching right now are technically wrappers: a prompt with a UI on top.

Wrappers can absolutely work. Good ones save repeated effort, integrate into a real workflow, and produce reliable outcomes the user couldn't easily get from raw ChatGPT. The user is paying for the workflow and the consistency, not the AI itself.

They fail when the value collapses to "this is just a prompt I could write myself." A good test:

What is the product still doing if you remove the AI?

If the answer is "almost everything" (the workflow, integrations, data, reliability), you have a real product that uses AI as one ingredient. If the answer is "almost nothing," you have a wrapper competing directly against the underlying model. That's a hard place to defend.

7. The case for not building an app

Sometimes the right first version isn't software at all.

A landing page describing the outcome with a manual service behind it. A template plus a setup call. A small automation. A spreadsheet you sell. Plenty of products started as something the founder ran by hand for the first ten customers before any code existed.

The advantage is huge: you learn what the workflow actually looks like before committing software to it. You watch real users get stuck, which is usually not where you expected. And the people willing to pay for the manual version are the same ones who'll pay for the software version, and they'll teach you what it needs to do.

If you can deliver the outcome without building an app, do that first and learn. Then decide what's worth automating.

Prompt

This prompt is not here to talk you into the fanciest option. It's here to pick the simplest structure that fits the workflow.

Ecosystem and product type

Take my notes and help me choose the structure for my product.

Please structure it into:

1. Where the pain happens and where the user is when it hits
2. Standalone vs ecosystem, with a recommendation
3. If an ecosystem, which one and why my buyers are there
4. Platform tradeoffs: distribution, trust, friction, margin, policy risk
5. Web, mobile, or desktop
6. SaaS, marketplace, or internal tool
7. Consumer vs enterprise
8. Wrapper vs real product (what's left if the AI is removed)
9. Whether a manual, non-software first version makes sense
10. The simplest structure that delivers the outcome

Then audit it.

Please flag:

- where I'm choosing a shape because it sounds impressive
- where the platform's cut or policy risk is bigger than I think
- where I'm building a marketplace-level challenge by accident
- where I've picked the enterprise buyer without wanting that life
- where this is a wrapper I can't defend

Be direct. If I'm overcomplicating the structure, tell me.

Before you move on