Devlog · Phase 0 · 1/7
Why Aubia Starts With a Waitlist
One page, one email field, one promise: aubia.dev's Phase 0 validates real demand with a double opt-in waitlist before broadening the product.
- waitlist
- product
- architecture

Aubia's first public incarnation fits on a single page: an email field and a promise. No pricing, no download, no account signup. This Phase 0 has one job: to measure whether the AI agent orchestrator I'm building answers a real need, before pouring more months into it.
I could have coded the desktop app on my own for six months, then announced it. I chose the opposite. The landing page first validates a hunch: do other developers feel the same frustration I do, running several AI agents in rotation without ever making them talk to each other? A waitlist answers that question early, and along the way it builds a consenting, qualified list of contacts for the beta 0.1 launch. The developer's note tells where that frustration comes from.
This caution answers a documented risk: the AI agent orchestrator segment is still immature, and adoption there doesn't prove monetization. One of the segment's most popular orchestrators announced its shutdown in 2026 despite real traction. The waitlist serves to validate an interest that holds before broadening the product, rather than piling up features nobody has asked to pay for.
One Page, a Single Conversion
The website repo started in late April 2026, and this discipline shows in the routing from the very first commits. Every public page lives under a language prefix, and the only write verb exposed is the waitlist form submission, which goes out to aubia.cloud.
Route::prefix('{locale}')
->where(['locale' => 'fr|en|es|de|it|pt'])
->group(function (): void {
Route::inertia('/', 'welcome')->name('home');
// Proxy waitlist vers aubia.cloud (BF-WB-001). Throttle nommé défini
// dans bootstrap/app.php.
Route::post('/waitlist', [WaitlistController::class, 'store'])
->name('waitlist.store')
->middleware('throttle:waitlist');
});
No dashboard, no member area, no public API. The landing exposes a localized home page, two legal pages, the confirmation pages, and that single submission endpoint. The language prefix serves six locales, each with its own indexable URL. Less surface means fewer bugs and a message that doesn't get diluted.
I ruled out keeping the Download and Create account buttons around, grayed out with a Coming soon. An inactive CTA sitting next to the active signup button creates a cognitive hesitation that costs conversions: the visitor wonders which one to pick instead of acting. As long as aubia.cloud isn't opening accounts and the binaries aren't signed, those buttons would lead nowhere.
aubia.dev, aubia.cloud, aubia.app: One Boundary Per Domain
The choice of domain encodes a clean boundary between Aubia's building blocks. The website and the emails live on aubia.dev. The application and its API live on aubia.cloud, with the api.aubia.cloud endpoint receiving signups. The desktop app will occupy aubia.app.
This separation guarantees that the public site, exposed to the entire internet, shares no sensitive infrastructure with the app. The landing page stays a lightweight, stateless shell, while the business logic and the data stay confined on the cloud side. When you submit your email on aubia.dev, the request crosses the boundary to api.aubia.cloud, and nothing personal is left behind on the website along the way. I cover that proxy further along in the series.
Measuring Without Cookies or a Banner
Running a pre-launch signup campaign demands knowing what works, without betraying visitors' trust. I use Fathom Analytics, cookieless and with no individual tracking. A handful of custom events is enough to read the journey: the form entering the viewport, a successful submission, a possible error, the arrival on the confirmation page. No profile, no data resale, no consent banner to force on anyone.
The landing also shows a count of people already confirmed, fetched server-side from aubia.cloud. A real number, never a projection: it counts only signups confirmed by double opt-in, never emails still awaiting validation. This demand for restraint also guides the product's vision: a tool that adds value without hijacking your attention.
The First Stone
A minimal website, a single goal, a strict boundary with the cloud: that's the first stone. The following articles get into the technical side: the stack that serves this page to search engines, then the architecture of a landing deliberately built without a database.
To be notified when the beta 0.1 opens, join the waitlist.
This build is chronicled here, article after article. Come aboard: your feedback will shape what comes next.
Join the waitlist