CARLOS · five questions
Five questions an investor asked, answered straight. Who the customer is. Who we compete with. Whether you start fresh or migrate. What you keep. What you can build, honestly.
Companion to the funding deck · draft 1 · September 2026
Michael's five questions, 2026-09-08. The shapes of the answers are the founder's; the page states them plainly and marks what is measured versus what is the founder's figure.
1 · who is the target customer?
And who want what AI-built, AI-driven software promises: faster shipping, less dependency, software they own.
Runs a small team. Uses AI, but shipping is still slow and customers still wait. Wants a values-driven business and is reliant on big tech for everything.
Hears about AI; his team still ships slowly. Wants the promised rapid iteration, quicker turnaround, and a more secure product for his customers.
Uses AI, builds on the status quo. Sells to health providers, so needs stringent security, but a small team can only balance so much security against features.
Product manager boxed in by tools and today's engineering. Figma, whiteboards, prototypes. Should be shipping features.
One-person side business. Wants to run a production-grade service alone. Cannot sell to enterprise as things stand.
Wants to build an app for her kid. Doesn't know where to start, doesn't want to pay much, could never maintain it.
Six shapes, the founder's. Paul is the founder. Each maps to a deck: Paul, Tony and Jeroen to the adopter and vendor decks; Vicky to the prototype-in-production slide; James to the incubator; Maria to getting-started and hibernation economics. Initial target only; the plan's year two and three widen it to public bodies and regions.
2 · who is your competition?
Not one competitor. The stack itself, and CARLOS's argument is that none of that stack is needed at small-operator scale.
Founder's framing: these are not competitors per se; CARLOS argues that this level of complexity is not required at small-operator scale. Say that sentence out loud before the table.
3 · start fresh, or migrate?
CARLOS encourages many small apps. The marginal cost of one more approaches zero, because idle apps sleep.
A new app that slots into what you have, sharing your existing sign-on.
As an on-prem edition of your product, or by moving customers one at a time. Data isolation makes it not all-or-nothing.
The CARLOS router can route to CARLOS apps and to other machines. Or keep your existing router and add CARLOS behind it.
Tito took the fourth route: an existing Rails app behind the CARLOS edge, unchanged, then data home region by region.
Founder's four options. Tito's Rails-behind-edge proof of concept and restore rehearsal are the evidence for the fourth and for "data home".
4 · what about services you keep, or we don't provide?
The platform is one binary on a host you control. It does not need the box to itself, and it does not need your other services to move.
A CARLOS host is anything that can reach the storage bucket; the agent is one systemd service. Routes can point at a socket, a TCP upstream, or a static tree, so non-CARLOS services are first-class targets. Services CARLOS does not provide yet (search, media, error monitoring) are on the roadmap in the funding deck's appendix.
5 · what apps can someone build? any app? really?
A unit is a team, a person, or a thing. The unit's traffic must fit one Go process, and its data must fit one SQLite file. That is a lot of apps.
An app whose users all write to one shared thing at once: a global auction, a single world-wide leaderboard, a ledger every customer contends on. If there is no unit to draw a boundary around, CARLOS is the wrong shape and says so.
The 3,000 requests per second figure and the SQLite envelope are the founder's working numbers (2026-09-08), not published benchmarks; say so if pressed. The honest "what does not fit" panel is the answer to "I don't believe you": the boundary is the whole claim.
5 · the proof: where the boundary sits in real apps
| boundary | the unit | apps | note |
|---|---|---|---|
| Per team | one team, one instance | Eleven · Tito · Jelly | Eleven runs teams of up to about a thousand people |
| Per user | one person, one instance | Keymail · Woodstar | a Keymail mailbox with search proven over 500,000 messages, twenty years of Gmail |
| App per team | each app in a suite, one instance per team | Oficina: sheets, docs, calendar and more | one team, many small databases |
| Per thing | one repository, one instance | amadan | the unit is the thing people collaborate on, not the people |
Examples growing daily. If you can name the unit, you can build the app.
Keymail's 500k-message import is documented in the keymail repo (docs/import.md). The Eleven team size is the founder's figure. Jelly is in development. Woodstar is per user with a public relay.
next steps
Close with the links; the four decks form one set.