CARLOS
Fund the foundation that helps organisations own their software.
Funding deck · draft 12 · September 2026 · carlosframework.com
Kawasaki role: title. Motif introduced: the owned instance, one binary and one file inside a boundary, with a copper hostname bar. It recurs on slides 4 to 10 and 15.
the problem
Convenience came with dependence: on someone else's software, prices and decisions.
Kawasaki role: problem and opportunity. Give the practical reasons their due; the grievance list is gone. Spoken: each of the three labels is a real reason a sensible team chose SaaS. The next slides show how CARLOS answers each one.
Affirmation. Aimed at vendor excess, not at the legitimate problems on the previous slide: enterprise features nobody asked for, AI badges on everything, a trust centre instead of a database you can inspect, per-seat pricing forever for software used a few hours a week. Say it, pause, move on.
the answer
One app binary and one database file, with updates and operation still managed.
Kawasaki roles: value proposition and underlying magic, together. The mechanics (Go, SQLite, channels, hibernation, residency) are in the appendix. What matters here is the boundary and the three rights.
evidence
Its own cloud account, hosts, storage and domains, on the published deployment modules.
Kawasaki role: current status and key metrics, brought forward as the first evidence. Tito is the reference third-party self-hoster (own AWS account, three regions with separate data buckets, restore rehearsal from tito/carlos-infrastructure/README.md). Jelly is not on this slide; its on-prem edition is in development and sits in the appendix catalogue.
what ownership includes
Pin a version, or pick the moment you move.
Kawasaki role: differentiation. Specific to Eleven, which has this today; platform-wide user-facing update choice is next and lives in the appendix with the channel mechanics. The point for a funder: ownership is not just where the data sits, it is who decides when the software changes, and that includes running your own fork.
economics
A parked app runs no process. Its data waits in storage until the next request wakes it.
Kawasaki role: financials, as operating economics. Carloku is one provider; a self-hoster pays for their own hardware and storage only. This is an illustrative operating cost with its assumptions on the slide, not a customer-savings claim. Detail (the $7.30 incident, the heartbeat rewrite, backhaul) is in the appendix.
deployment
Hosting is a choice made outside the instance's boundary.
Kawasaki role: competition, framed as the choice rather than a feature checklist. Spoken: rented software offers the first of these only. Mechanics (outbound-only boxes, buckets, the edge, residency enforcement, two-box availability, the physical-security caveat) are in the appendix; region moves are specced and in progress, so do not promise relocation on stage.
go to market
The consultancy would walk an organisation home and stay afterwards.
Kawasaki role: go-to-market. Target customers, not deployment evidence. The four-step migration path (edge in front, data home, idle parts asleep, hot path rebuilt) is in the appendix.
Affirmation. The bridge from one customer's benefit to the public asset a foundation should hold: every CARLOS app has the same shape, is open, and can be forked with its sign-on, edge and trust tier intact.
the organisation
A foundation would hold the code and the mission, with a golden share in both commercial arms. proposed structure
Kawasaki role: business model and public benefit. Nothing is incorporated; the golden share terms (veto on sale, purpose and licence change; distribution share; board appointment with no seat for builders or sellers) are proposed and in the appendix.
the team
To build, verify, and bring CARLOS to the organisations that can use it.
Kawasaki role: team. This is a hiring plan, not an existing team; the proposed 6/3/3/2/2/2/2 split and the €250k loaded average are in the appendix.
the plan
Kawasaki role: timeline. Plan labels, not achieved results. Detailed proposed milestones (ten migrations, three regions, self-sustaining by year three) are in the appendix. A 5-to-10-year loan cohort will not have fully repaid by year three; year three tests the record so far.
status
AI helped a handful of people build this. The software and the organisation are young.
Kawasaki role: current status, stated once, plainly, without apology. Product-by-product caveats (Ocho and Jelly in development, Dineraya a proof of concept, correomona shipping this week, no enterprise SSO, prices Carloku-specific) are in the appendix beside the claims they qualify.
the ask
Take your software home.
Kawasaki role: ask and use of funds. Proposed line items, grant-versus-capital instruments and return terms are in the appendix and need the founder's numbers. No direct funder distributions are promised here.
appendix
Mechanisms, numbers, status and assumptions behind the fifteen slides before this one. Every unfinished thing is labelled.
Divider. Everything after this is reference material for questions, not the pitch.
Appendix · architecture · two shapes
the framework · rastrillo
A Go program that compiles to one static binary and talks to one SQLite file. Five source files, a templates folder, server-rendered HTML, about 130 lines of JavaScript in total. Every app looks the same, so every app can be read, forked, and driven.
app = 1 binary + 1 database file + 1 hostname
the platform · carlos
An object-store bucket holds all durable state. Hosts run the carlos binary and converge on what the bucket says. A shared edge routes traffic. Idle instances park into the bucket and wake on the next request.
deployment = 1 bucket + N hosts + DNS
The framework is the shape of a CARLOS app the way the platform is the shape of the substrate it runs on. Apps that fit the shape get hibernation, residency, rollback, and an agent interface for free.
"One deployment is one object-store bucket + N hosts running the carlos binary + DNS" is verbatim from carlos/platform/README.md:10-13. Five-file app shape from oficina/calendar/AGENTS.md:8-22. 130 lines of JS from the rastrillo README.
Appendix · architecture · is it seismic? a thesis
Each row is a mechanism that exists in the code today. "Seismic" is the claim that all four, combined, change who owns software worldwide. That is a thesis, not a result: it holds if dormant instances stay cheap under real load, forks stay maintainable, organisations actually migrate, and independent operators succeed.
Honest evaluation slide. Scoping doctrine ("there is no team_id column") from rastrillo/docs/site/scoping.md. "Most software is used a few hours a week. The platform bills like it." from the platform site. The build-with-AI row is the movement's stated position.
Appendix · distribution · channels and versions
A customer who wants their own remix of a deployed app forks it, ships to their own channel, and points their instances at it. They keep the upstream sign-on, the edge, the hibernation and the trust tier. Upstream keeps shipping. The two never have to merge unless they want to.
That is an app store for organisations: one catalogue of apps, many channels per app, every instance deciding which one it follows. The pipeline that gates a promotion, with bake windows, passkey step-up and approvals, is what makes a channel safe to trust.
Mechanics from site/platform/index.html:211-216 (content-hashed releases, channels as pointers, instances subscribe and roll at the next natural boundary, "a channel with one subscriber") and pipeline.go (bake, passkey, approvals). Per-user pinning and choose-when-to-update is Eleven's feature per the founder (2026-09-07); it is not a platform-wide user-facing verb yet. "App store" is the deck's framing, not a term the repos use.
Appendix · development cycle
There is no staging system to keep in sync. A dev environment is a channel with one subscriber. One command from a branch builds, ships, makes a channel, spawns an instance and hands back a URL. Every push exercises the same path a release will take.
A canary instance sits behind production sign-on, on a production hostname, with production data shapes. A product manager no longer prototypes in an abstract external tool and then argues about what was meant. They open the canary, use the real thing, and say yes or no.
Canaries ship continuously in seconds, and a canary nobody is using hibernates like everything else, so ten open experiments cost roughly nothing. Promotion to a wider channel is gated by the pipeline: bake windows, passkey step-up, approvals. Rollback is a pointer.
The gap between "an idea" and "a thing real people can click, behind real auth" closes to the time it takes to compile. That changes who gets to try ideas, not just how fast.
"The dev pipeline is the prod pipeline" and "a channel with one subscriber" from site/platform/index.html:216. The canary verb landed on main 2026-09-04 (PR #384); Tito's go.tito.io has followed a canary channel as a live production channel throughout (internal/release/laddercheck_test.go). Pipelines: pipeline.go. "Product managers prototype in production" is the founder's framing (2026-09-07).
Appendix · security and trust
There is no team_id column in a CARLOS app because there is no second team in the database. Isolation is the operating system's boundary: an ephemeral system user per instance, its own SQLite file, its own hostname. Inside an instance, a row that is not yours answers 404, never 403. It does not exist.
Keymail, Eleven, Woodstar, Kass and amadan are end-to-end encrypted. Keys are made in the browser and never leave. The object store holds parked databases and blobs but no plaintext of any E2EE app. amadan proves it in CI: push a marker string, then grep the server's raw database bytes for it.
An app that must read data says so. Correomona reads every address it holds because an address must be plaintext to go in an envelope. Its named leaks are listed in the README and pinned by a test that fails when a new plaintext column appears without a dated reason.
The test for every app is the same: publish the database and see what leaks.
What that test proves: nothing readable is stored at rest. What it does not prove: key handling, authorisation logic, or a compromise of a live host. Those are the certification arm's job, later in this deck.
Sources: rastrillo/docs/site/scoping.md (404 not 403), internal/host/units/carlos-app@.service (DynamicUser), amadan/amadan/README.md (canary grep), correomona/AGENTS.md (plaintext test), pegamento/docs/doctrine.md:33 (publish the database).
Caveat for later drafts: the platform itself does not encrypt parked databases at rest. Sealing is done by the app using the framework's crypto, keyring and sealed-blob primitives. Secrets are sealed client-side before upload. Phrase as "no plaintext of E2EE apps", never "everything encrypted at rest".
Appendix · speed and durability
The wake figure is anecdotal across the family's apps; request percentiles are not yet benchmarked.
Numbers: RSS 20–60 MB from carlos-edge.service:66-68; binary sizes from the rastrillo README (fresh scaffold 21.3 → 14.7 MB raw, 10.6 → 5.1 MB compressed). Cold wake under 500 ms and the 1–2 s replication interval are the founder's figures (2026-09-07), not in any repo; worth a measured benchmark before the deck ships. No p50/p95 request figures exist.
Appendix · deployment modes
A member of an account brings an app live with a login alone. The console writes the manifest, pins the hostname, and the boxes converge in seconds.
A CARLOS host is anything that can reach the bucket. A remote host is outbound-only: port 443 out to storage and the edge tunnel, no inbound port, no SSH required. Your data bucket, your box, our routing.
The same OpenTofu modules the flagship uses are published for anyone. Two of the platform's first three deployments are self-hosted, so anything the flagship needs that a self-hoster cannot have is a design error, caught immediately.
No UX compromise because there is no second product: same hostname, same pages, same sign-on, only the bucket's address changed. Residency is enforced where the instance wakes, not promised in a policy PDF. And leaving is the design: point new boxes at your bucket and the platform is elsewhere; point them at another cloud's bucket and so are you. Who runs the bucket, the edge, sign-on and backups is a named choice in each mode, not a hidden dependency.
Sources: infra/remote-host.md (outbound-only), fleets.go and README.md:404-429 (customer fleets with own bucket), infra/README.md (published modules), tito/carlos-infrastructure/region-*.tf (per-region data bucket, IAM-enforced), platform site (residency quote).
Appendix · any host
A CARLOS host is anything that can reach the bucket: a cloud instance, a rack in a cupboard, a laptop, a board on a shelf. The platform depends on an S3-compatible object store and DNS, and that store can be a cloud's or one you run yourself. Everything else is optional; how many cloud services you use is a decision per deployment, not a requirement of the software.
Two hosts watching the same bucket survive the loss of either: the survivor claims the lease and wakes the instance from parked state, with no cluster software or quorum to run. What it still depends on is the bucket, DNS and the edge being reachable. And the caveat is physical: whoever can touch the box can read what is awake on it, so the trust tier and the room both matter.
Because a host is outbound-only and disposable, contributed machines can join a fleet from anywhere: a community's members, a university's departments, a co-op's offices, meshed through the edge tunnel. The bucket stays the source of truth; the compute is whatever people bring.
Nothing stops a deployment from using what the clouds do well. Latency-based routing sends a user to the nearest armed edge. Per-region buckets keep data where the law wants it. Same binary, same app, with or without the extras.
The floor is very low and the ceiling is very high, and it is the same software at both ends. Instances move between regions with their data following, two-phase, over a push-only staging prefix specced, in progress. The box is disposable, the bucket is not.
Sources: "a CARLOS host is anything that can reach the deployment bucket" and outbound-only hosts from infra/remote-host.md; lease claim and wake-on-any-eligible-host from the activator and platform site; latency routing via carlos steering ... latency (docs/site/cli.md:307-331); per-region buckets from Tito's infra. The two-box HA statement and the physical-security caveat are the founder's (2026-09-07). Pooled contributed compute and meshing are theoretical and marked so.
The flagship's bucket is AWS S3. Per the founder (2026-09-07) there has been extensive research into S3-compatible object stores for both blob storage and the replication stream; that research lives on the founder's laptop, not in these repos. The slide states S3-compatible as the target; keep "depending on use case" until a non-AWS deployment has run end to end.
Appendix · driveable by humans and agents
No bundled LLM client. Choosing a provider is your business. No MCP server in the platform. The agent interface is the app's own actions, exposed as typed tools, so it works with whichever model or none. A person using CARLOS without AI loses nothing. A person using it with AI gets an operator that can only do what the UI already allows.
Sources: rastrillo/docs/site/agents.md, docs/site/reference/tools.md (Dispatch through the mux, ConfirmSentence), carlos/platform/skills.go (well-known agent skills), skillmd_test.go (18,000 byte budget), AGENTS.md:49-53 (every command for a user with no infra access), completion-design spec ("MCP does not exist anywhere in the platform").
Appendix · scale · a hypothesis
An app moves along that curve by changing its manifest, not its architecture. Because the unit is an instance, growth is horizontal by construction: many users means many small databases waking when needed, not one database that must never fall over. Dineraya is built on exactly this: one instance per buyer, asleep in a bucket, so the network can fill in behind real purchases instead of needing a user base first.
This is a scaling hypothesis, not a load test. The largest fleet today is hundreds of instances. The next test is thousands, then the routing, storage-operation and fleet-administration limits at each step. Hibernation default is 15 minutes idle, tightening to 90 seconds.
"Scale is a declaration, not a rewrite" and the five-step curve are from the platform site. Idle window from internal/activator/activator.go:76,90; the 90 s target and "ten times a day" from the 2026-08-30 scheduled-ticks spec. The "billions" framing is a shape argument, not a load test; say so if asked.
Appendix · economics detail
Rate sheet defaults from internal/economics/scenario.go:141-164 (AppMonthUSD 5, InstanceHourUSD 0.01, free tier). $7.30 story from the scheduled-ticks spec §1 and PR #371. Heartbeat numbers from internal/lease/lease.go:26-36. Backhaul from docs/site/cli.md:681-684. The $5 and 1¢ are Carloku's rate-sheet defaults in code; Carloku is one provider in the ecosystem, and the flagship's real bill lives in the private infra repo.
Appendix · energy · conditional
Most software is used a few hours a week. The industry runs it twenty-four hours a day, sized for peak, on three continents, just in case. CARLOS runs it when someone is using it.
The saving is the app's own compute, which is most of a conventional deployment. The bucket, the edge and DNS still run for everyone, and no kilowatt-hour figure has been measured yet. Energy stays a conditional claim until it is.
74-of-300 from the scheduled-ticks spec §1 sizing measurement. Agent RSS from internal/cgroup/cgroup.go:71. "Scheduling is deliberately dumb" from the platform site. Energy is the moral bonus of the cost argument; the deck keeps it honest by flagging the absent kWh number.
Appendix · migrating existing apps
A conventional Rails or Django app runs behind the CARLOS edge unchanged, keeping its own sign-on wall. Tito's proof of concept did exactly this. You get the routing, certificates and fleet view first.
Give the app its own instance record, a per-region bucket, and a pool. Residency and restore rehearsals come with it: Tito restored seventeen databases in sixteen seconds from the bucket.
The admin screens, the reporting, the once-a-week job: split them into CARLOS instances that hibernate, and stop paying for them at 3am.
When a feature is worth owning outright, write it as a CARLOS app beside the old one. Same hostname family, same sign-on, faster, and it is yours.
Each step is reversible and each step pays for itself. The order is a real sequence, which is why it is numbered.
Step 1 from the rails-behind-carlos-edge POC spec (docs/superpowers/specs/2026-08-11-...) and Tito ID SSO proxying in apimode.go:153. Step 2 from tito/carlos-infrastructure/README.md restore rehearsal (17 DBs, 16.4 s). Steps 3 and 4 are the argued path, not yet a documented migration guide.
Appendix · the app catalogue, with status
| app | what it is | replaces | trust posture |
|---|---|---|---|
| Eleven | Team chat. One instance per space. The code quarry the platform came from. | Slack, Teams | End-to-end encrypted |
| Keymail | Email where keys live in the browser, one database file per inbox, and strangers pay proof-of-work for first contact. Also the family's sign-on. | Gmail, Outlook, Okta | End-to-end encrypted |
| Ocho in development | Personal messaging, forked from Eleven. Lives at ocho.chat. | Signal, iMessage, WhatsApp | End-to-end encrypted |
| Oficina | Office suite: docs, sheets, calendar, memory, files via Slopbox, single sign-on via Keymail. One instance per team. | Google Workspace, Microsoft 365 | Sealed per team |
| Woodstar | Social relays where follow lists are private and keys travel with the user. | X, Facebook, Mastodon servers | End-to-end encrypted |
| amadan | Git hosting and CI where the server cannot read your code. Hosts and gates the platform itself. | GitHub, GitLab, Actions | End-to-end encrypted, canary-tested |
| Correomona shipping this week | Mailing lists with consent recorded per list and checked at send time. No open pixels, no click rewriting, no engagement scores. One instance per team. | Mailchimp, Brevo | Server-side, named leaks tested |
| Dineraya proof of concept | Non-custodial payments over instant bank rails. One instance per buyer, one per merchant, a blind dispatcher. Nobody in the middle holds money. | Stripe, PayPal, card fees | Sealed to the buyer's passkey |
| Kass · Seapointish | Coaching, one instance per person. A team ledger across Revolut, Wise and Stripe. | Niche SaaS | E2EE · sealed single-tenant |
Ocho is not on this machine; per the founder it is a fork of Eleven for personal messaging at ocho.chat, so it inherits Eleven's E2EE posture. Dineraya is at bootstrap (one binary, three roles, CI gate, merchant canary live) and is openly a proof of concept. Correomona is due to be complete 2026-09-08 per the founder.
Sources: keymail/README.md, oficina/suite/README.md, pegamento/docs/doctrine.md, amadan/README.md, correomona/AGENTS.md, dineraya/README.md, paulca/seapointish/README.md.
Appendix · compliance · evidence and remaining work
No CARLOS deployment is certified yet, and no control mapping to ISO 27001 or SOC 2 has been written. The claim is narrower: the system already produces much of the evidence about data handling, in a form an assessor can re-run. The remaining work is a control mapping, a subject-access export, per-app deletion, a privacy policy and terms, and an assessor.
Ledger: carlos ledger verify, docs/site/cli.md:447-468. Console audit rows in internal/console/api*.go. Known gaps: no DPA, privacy policy or terms in any repo; no platform-level subject-access export; subscriber-level deletion in correomona is a dated not-yet. Sources: residency at IAM from Tito's region-*.tf and platform site; signed channel pointers, 72h bake, blind/seeing services from site/platform/index.html; device-code reasoning from README.md:136-154; consent from correomona/AGENTS.md; canary tests from amadan and oficina/home. The flag is important: nothing is certified, and the deck should never imply otherwise.
Appendix · aspirations · communities, universities, cities
A sports club, a co-op, a village. Chat, mail, a calendar and a mailing list on a box in the hall, sleeping between meetings, costing pennies. With a self-run object store and sign-on, members' data stays in the building; with a hosted bucket it stays in the region they choose. Either way, no company's terms of service in the way.
Universities used to run their own mail, file and course systems, then handed them to two vendors and lost the ability to say no. One instance per department or per course, hibernating between terms, on hardware the university already owns. Research data stays in the region the grant requires.
A city that writes a permits app as a CARLOS app has written it for every city. Fork it, keep your bucket, keep your residency, contribute the fixes back. The licence bill that goes to a vendor every year becomes engineers who work for the public.
Codex finding 8: name the operator of each dependency (bucket, edge, sign-on, backups) rather than promising "never leaves the building". Aspirational slide, built from the platform's properties (outbound-only hosts, per-instance isolation, hibernation, forkable shape) applied to three audiences the user named. No deployments in these sectors exist yet; present as "what this makes possible".
Appendix · foundation governance · proposed
Two arms make money. Two arms make the thing worth paying for. The golden share is what stops the first pair from eating the second: a veto on sale, change of purpose or licence change; a fixed share of distributions to the foundation; and a certification board appointed by the foundation, with no seat for the builders or the sellers terms to be drafted at incorporation.
Structure is the founder's brief (2026-09-07), not yet incorporated. "Foundation" is a placeholder name. Codex finding 18: name the mechanisms rather than assert the outcome; the three named here (veto rights, distribution share, board appointment with conflict exclusion) are the proposed terms and need legal drafting before the deck ships.
Appendix · r&d and verification
The tooling that lets a small team use AI at speed without taking the AI's word for it. It stays non-profit because the verifier must not be for sale, and its output, the software and the tests, stays public.
Factor X marking is on every README (carlos/platform/README.md:3-5). Canary and plaintext tests: amadan, oficina/home, sheets, correomona, dineraya. Build stamping: correomona commit "Stamp the build so a deploy can be proved, and disproved" and the platform's per-release attestation (README.md:514-624). 18,000-byte budget: rastrillo/skillmd_test.go. The "verify the AI" tooling beyond these tests is a roadmap item; present the existing tests as the seed of it.
Appendix · incubator · pilot assumptions
Cheap hosting removes one cost. It does not pay salaries, win customers or run support. The underwriting assumption is that a one-to-three-person organisation selling a CARLOS-based service locally can service a €50k to €150k loan from revenue within its first two years, with the consultancy's migration playbook and the certification badge as its sales tools.
Illustrative only: 80 of 100 loans repaid over seven years at 8% simple interest returns about €12.5m on €10m lent, before any recovery on the rest. The first cohort's repayment data is the product of year one; the model is proven or not by year three.
Codex finding 17: present a pilot with underwriting assumptions, not a validated lending model. Targets (80%+, 5–10 years, beat-market, up to 100 orgs, €10m book, 1–3 operators by local need) are the founder's (2026-09-07). Loan tiers, the 8% illustration and the two-year service assumption are the deck's proposals to be replaced with real terms; the benchmark still has to be named. No loan book exists.
Appendix · certification · proposed scale
End-to-end encrypted, peer to peer. Devices talk to each other directly; the platform, if present, is a rendezvous that holds nothing. There is no database to publish.
End-to-end encrypted. Keys are made on the user's device and never leave. The server holds ciphertext and routing only. Publishing every database leaks nothing but metadata, and the metadata is listed.
Sealed to the user's keys; the server never opens it. Whatever an operator necessarily learns (timestamps, who talked to whom) is published as declared residue and tested.
Key in memory while awake, because unattended operation needs it. A live-host compromise yields that instance's data and the class says so plainly.
Server-side trust, argued. Every plaintext column is listed with a dated reason and pinned by a test that fails CI when a new one appears.
Today's documents use classes A2, B and S (blind stateless service with declared residue): dineraya/DESIGN.md §3, pegamento/docs/doctrine.md. A1 and C are named in the founder's brief and defined here by extension. A0 (E2EE peer-to-peer, no server in the path) was added 2026-09-07 as the top of the ladder; nothing in the family reaches it yet, and the pill says so. Publishing the pinned scale is the certification arm's first deliverable. No certification has been issued.
Appendix · consultancy · intended
R&D makes the software worth migrating to. Consultancy migrates organisations and finds the gaps R&D should fill next. Certification makes the migration defensible to a board or a regulator. The incubator seeds the small organisations that could never have afforded any of it, in the places the landlords never bothered to serve. Every turn makes the next one cheaper.
Consultancy does not exist yet as an entity. Tito's self-hosting engagement and the rails-behind-carlos-edge POC are the nearest precedents. The flywheel is the argument for funding all four arms at once rather than one.
Appendix · plan detail · proposed milestones
Founder's three-year outline (2026-09-07): Y1 prove, Y2 hub-and-spoke regional distribution with ambition evolving as AI capability increases, Y3 global deployment, CARLOS an established default, model proven, consultancy worldwide. "Ten migrations", "three regions" and "self-sustaining by year three" are the deck's proposed milestones; confirm or replace.
Appendix · team split · proposed
| function | people | what they deliver in year one |
|---|---|---|
| Verification & R&D | 6 | Verification tooling v1, suite completion, platform hardening, benchmark the anecdotal numbers. |
| Certification | 3 | The published trust scale, threat models per tier, first certifications, the ISO/SOC control mapping. |
| Consultancy & migration | 3 | The migration playbook, ten paid migrations, the first regional partner. |
| Sales | 2 | Public-sector and SaaS-vendor pipeline; the first hundred loan applicants. |
| Marketing | 2 | The movement's public voice, the case studies, the site. |
| Outreach & community | 2 | Regional hub groundwork, universities and cities, incubator cohort support. |
| Operations, finance, legal | 2 | Incorporation, golden-share terms, loan administration, the books. |
The people who can build, verify and certify AI-built infrastructure are the people the AI labs are hiring. Paying below that market means not hiring them. Twenty at a loaded average near €250k is about €5m a year, half the seed.
The split is a proposal to confirm. The functions are the founder's; the headcounts are the deck's.
Founder's brief (2026-09-07): team of 20 at AI-market salaries across verification, certification, sales, marketing, outreach "etc". The 6/3/3/2/2/2/2 split and the €250k loaded average are the deck's assumptions. Codex finding 19: a funder needs to hear who can deliver; this is that slide.
Appendix · use of funds · proposed
| use of funds | €m | instrument |
|---|---|---|
| Team of twenty, year one | 5.0 | Grant to the foundation |
| Incorporation, governance, legal | 0.5 | Grant to the foundation |
| Certification programme | 0.5 | Grant to the foundation |
| Marketing, outreach, regional hubs | 1.0 | Grant to the foundation |
| Platform operations and infrastructure | 0.5 | Grant to the foundation |
| Runway into year two | 2.5 | Grant to the foundation |
| Loan book, cohort one, up to 100 organisations | 10.0 | Capital into the incubator, returned with interest |
| Total | 20.0 |
Take your software home. Twenty million euro is what it costs to hold the door open for everyone else.
Codex finding 7: the ask is the proposal, with instruments, allocation and milestones. Total and the 10/10 split are the founder's (2026-09-07). The line items in the €10m seed are the deck's proposed allocation and need confirming. Grant vs capital instrument per line is a proposal; the loan-book capital's return terms to funders still need drafting.
Appendix · features shipped and in progress
shipped today
working on
Every item on the left is a CLI command and an API call, designed for someone with no access to the boxes underneath. That is what makes the platform fully driveable by an agent as well as a person: if a task needs a human on a box, it is filed as a bug.
Shipped column verified against docs/site/cli.md section headings and the matching Go files on 2026-09-07. carlos canary landed on main 2026-09-04 (PR #384, "fill the reserved verb with the sugar over what already works"); the local checkout used for the first pass predated it. Deliberately omitted as not shipped: the blind services the site paragraph names (no code found), S3 cert cache (reserved).
"Working on": virus scanning, media hosting, error monitoring and analytics are the founder's list and appear nowhere in the repos yet. Instance moves (2026-08-28 spec), managed custom domains (2026-08-27 spec) are specced. Backup/restore today is operator-on-box only; webhooks exist only as an operator alert hook; search is not mentioned. Policy line: AGENTS.md:42, "if a day-to-day task has no API/CLI command, that is a product gap".
Appendix · speaker only · which argument lands
True, large, and easy to say. But everyone claims cheaper. On its own it gets a procurement meeting, not a movement. Cost is the proof, not the point.
True and structural: at rest, nothing runs. It is the argument's conscience, the reason a good person can feel fine about it. Energy is the bonus, not the point.
For fifteen years owning software meant ops, outages and a sysadmin. CARLOS makes owning cheaper, safer and lighter than renting. That is the thing nobody else can say. This is the point.
The most resonant sentence in this deck is the first one. Take your software home. The pennies and the sleeping servers are how we can afford to. The organisation is how everyone else can.
Appendix. The codex review judged this slide internal editorial; it stays here for the speaker, not the room. Its correction to the argument: cost is evidence, not a procurement footnote, and energy stays conditional until measured.
The user asked which point is most resonant. Recommendation: lead with ownership, prove it with cost, and let energy be the closing warmth. Cost-first pitches get compared on price; ownership-first pitches get compared on nothing, because no rented product can make the claim.