App vs Ecosystem:Decide Before You Design a Database

App vs ecosystem is the one question to answer before you design a single database table: are you building an app, or an ecosystem? An app serves one kind of user doing one job. An ecosystem serves several kinds of users whose data connects and flows between them. The answer changes everything about your database — an ecosystem's design is roughly 10x more complex — and it is far better to know before the foundation is poured than after.

This is the question I answered before writing any code for my own platform, and it is the reason the database ended up the size it did. Here is how to ask it properly, what each answer commits you to, and the exercise that surfaces the truth in twenty minutes.

The question that decides your whole database

Databases are foundations, and foundations are shaped by what will stand on them. A garden shed and an apartment block both need concrete — but nobody pours a shed's slab and then decides to add twelve floors. Software is the same: the shape of your data model is set by the most ambitious version of what you are building, and it is the one part of your product that is genuinely painful to change later. (New to what a data model even is? Start with databases explained for non-technical founders.)

So the first design act is not drawing tables. It is deciding what you are actually building. Not the features — the vision.

What “just an app” looks like

An app has one kind of user doing one job. A time tracker. An invoice generator. A habit builder. Its database is refreshingly small: a users table, a projects table, a tasks table — done. Simple.

There is nothing wrong with this. If your vision truly is a focused tool for one audience, a small, clean database is a strength: faster to build, easier to reason about, cheaper to maintain. The mistake is not building an app. The mistake is building an app's foundation under an ecosystem's ambition.

What an ecosystem looks like

When I started my platform, I did not sit down to build “an app.” I sat down to build an ecosystem. The vision: a platform where startups run their entire operation, accelerators manage their programs and portfolios, VCs track deal flow and investments, and affiliates promote and earn — all of them connected, all of them talking to each other.

That one paragraph transformed the database. Instead of a users table, I needed organizations of fundamentally different types — startups, accelerators, VCs, affiliates — with users attached to them in different roles. Instead of one product's tables, I needed ten products — OS, HUB, CAP, Money, People, Score, Pitch, Accelerator, Affiliates, VC — sharing data that flows between them: the startup a founder runs is the same startup an accelerator coaches and a VC evaluates. Relationships between all of them, everywhere.

That is why the platform runs on 964 tables. Not because I wanted complexity — because the vision demanded it. An ecosystem's database is not a bigger app database; it is a different kind of object, the way a city's road network is not a longer driveway.

The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →

App vs ecosystem: the practical differences

Note the asymmetry in the last row. Choosing “ecosystem” when you only needed an app costs you some wasted structure. Choosing “app” when your vision was an ecosystem costs you the foundation itself — retrofitting connections between user types onto tables that were never designed to relate is the kind of surgery that stalls products for months.

Why you must decide now, not later

Because 10x complexity is perfectly manageable when you know about it upfront, and brutal when you discover it halfway through. Better to know now than to realize it after you have built the wrong foundation.

Deciding “ecosystem” early also unlocks the single most important structural choice that makes ecosystems possible: designing for multiple organizations from day one, with every row of data belonging to exactly one of them. That pattern — multi-tenancy — is nearly free to build in at the start and nearly impossible to bolt on later. It is the first concrete consequence of the app-versus-ecosystem answer, which is exactly why the question comes before the tables.

And to be clear, this cuts both ways: if the honest answer is “app,” build an app. Do not gold-plate a focused tool with ecosystem plumbing because it feels more ambitious. The sin is not smallness; it is mismatch.

The exercise: write the vision, not the features

Before your next table, take twenty minutes and write down the vision. Not the feature list — the vision. Three questions do the work:

Who are ALL the users? Not just the obvious one. Who else touches this — admins, partners, reviewers, buyers, promoters? How do they connect? Which of them need to see, share, or act on the same records? What data do they share? Which pieces of information flow between them rather than living in one person's silo?

If the answers are “one user type, no connections, nothing shared,” congratulations: you are building an app, and your database can stay beautifully small. If the answers involve several kinds of users exchanging data — you are building an ecosystem, and every table you design from this moment should know it.

12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →

Frequently asked questions

Is an ecosystem better than an app?

No — matched is better than mismatched. A focused app with a small database that fits its vision beats a half-built ecosystem every time. The point is not to aim bigger; it is to make your database honest about what you are actually building.

Can I start with an app and grow into an ecosystem?

You can — if the foundation allows it. The compromise that works: scope the features like an app, but make the handful of foundational choices (multi-tenancy, organizations as first-class records, proper references) as if the ecosystem vision might come true. Features are easy to add later; foundations are not.

How many tables does an ecosystem need?

There is no magic number — 964 is what one real, ten-product ecosystem demanded, not a target. The honest answer is: however many the vision requires, which is exactly why you write the vision down first and let the table count fall out of it, rather than the other way around.

Will AI ask me the app-versus-ecosystem question?

No — and that is the danger. Ask AI to “build me a platform” and it will happily produce an app-shaped schema, because apps are the statistical average of everything it has seen. The vision lives in your head. State it explicitly — all the user types, the connections, the shared data — and AI can design for it. Leave it unstated and you get a shed slab under your apartment block.