I've been working with an entrepreneur incubator — sixteen small storefronts, most of them very young businesses, sharing one site, one landlord, and one goal: get people to come back.
It's the kind of project economic development work produces all the time: a physical home for entrepreneurs who couldn't otherwise afford a storefront. And it has been teaching me something that applies far beyond one incubator, to every organization responsible for many businesses at once — libraries, municipalities, entrepreneurship programs, community development organizations.
The lesson is this: the difference between supporting sixteen businesses and building an ecosystem is whether the help is delivered as sixteen favors or as one infrastructure.
This is one project, so hold it as one story rather than a proof of anything universal. But the pattern it shows up is the exact question the ecosystem work always comes down to.
What does ecosystem infrastructure actually mean?
Ecosystem infrastructure is support built once, in a repeatable form, that every business in a community can stand on — instead of custom, one-off help delivered business by business until the program runs out of hours.
At the incubator, that principle is concrete. Websites aren't being built as sixteen separate projects with sixteen separate looks, stacks, and logins; they're being stood up as one repeatable build — fourteen of the sixteen businesses now have completed sites, and the only two that didn't go live belong to businesses that have since moved on from the incubator. No one-at-a-time approach would have reached that this season. Programming works the same way: a youth program that runs on a defined cycle, events that repeat on a rhythm, an indoor space nearing completion so the rhythm can survive winter.
None of that is glamorous. All of it is the difference between a place that hosts businesses and a place that grows them.
Why "sell experiences, not just products" is an infrastructure decision
The most interesting shift at the incubator isn't technical at all. It's a change in what the businesses are being coached to sell.
A tiny storefront selling products competes, whether it wants to or not, with the entire internet. Anything a visitor can buy there they can buy from their couch, often cheaper. If the incubator's value is products, it loses that fight on price and convenience every time.
So the businesses are being guided toward selling experiences: the thing you have to be there for. The visit, the making, the tasting, the event, the person behind the counter. Products become what you take home from an experience, rather than the reason you came.
Here's why I call that an infrastructure decision rather than a marketing slogan: an experience model only works if the ecosystem can support repeat visits. It needs programming that changes, spaces that work year-round, ways to tell people what's happening this week, and web presence that can announce and book things — not just list them. The individual business can't build that context alone. The shift from products to experiences is really a shift in what the shared infrastructure must do — which is the same lesson event systems teach: the attendee's reason to return is designed, or it doesn't exist.
What organizations that serve many businesses can take from this
A few transferable observations, from watching this work up close.
Repeatability is what makes fairness possible. When help is custom every time, the businesses served first get the most, and the program's capacity decides who thrives. When help is infrastructure — a repeatable website build, a standard programming calendar, a shared model for what to sell — every business gets the same floor, and the program's effort compounds instead of resetting with each business. A community's shared directory is the same idea in another form: one piece of infrastructure that raises visibility for everyone at once.
The businesses still need to own their piece of it. Shared infrastructure must not become a new dependency. Each business standing on a shared build still needs to hold its own keys — domain, access, ownership — or the ecosystem has simply replaced one landlord with another. Building the infrastructure and transferring the capability to hold it are two halves of the same job.
And progress needs to be visible to the people who fund it. Ecosystem work answers to councils, funders, and boards, and what they can see is what gets sustained. Part of this project's health is that its milestones — how many sites are up, what's running, what's next — exist as a reportable rhythm, not as a feeling. If your program can't show its infrastructure growing, it will be treated as a collection of favors, and funded like one.
The question underneath all of it
Every organization that serves many businesses eventually meets the same question: how do we help the next hundred the way we helped the first five, without burning down our staff?
The incubator's answer — one I keep seeing hold up — is: stop scaling the favors; scale the floor. Build the pieces every business needs as infrastructure, keep the human help for what's genuinely particular to each business, and coach the whole community toward a model the place can actually win with.
That's what ecosystem infrastructure means in practice. Not technology for its own sake — a floor sturdy enough that sixteen very young businesses, or sixty, can stand on it at once.
If your organization is responsible for many businesses and the help still leaves one business at a time, that's an architecture problem with a known shape: explore ecosystem infrastructure.