Product1 publisher2 min readPublished
Aha! rebuilt its app builder for product managers on V8 isolates after containers proved too wasteful
Aha!'s founders say the first, containerized version of Builder was too slow and expensive to scale, and the rebuild keeps authentication, SSO, databases and email out of generated code on cost and reliability grounds.
The Product Desk · Product desk
What happened
- Aha! rebuilt its Builder app for product managers onto a single-instance, multi-tenant architecture using V8 isolates after the first containerized Ruby on Rails version proved too wasteful to scale.
- Core plumbing including authentication, SSO, database access and email ships as pre-built deterministic components, which Aha! says cut token cost and guarantee reliability that AI-generated code can't.
- A multi-phase, multi-agent pipeline generates a design system, then a prototype, then a working application in minutes, reusing the agent framework built for Aha!'s roadmapping assistant Elle.
- The details come from a Just Now Possible episode in which Teresa Torres interviews Aha! co-founders Brian De Haaff and Chris Waters with senior product manager Sarah Moisan-Thomas.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- cost Aha! is bootstrapped and profitable, so the runtime choice lands directly in its own margin: every idle container-minute a product manager is not typing into is paid for out of the price of the seat.
- capability A product manager can stand up a prototype with working sign-in and a database without an engineer, because those pieces are called from a library instead of being written by a model on the fly.
- decision Buyers have to decide whether a fast prototype counts as a deliverable on its own, since Aha! is not offering Builder for the apps a business actually runs on.
- constraint No cost figures are published and the transcript is paywalled, so teams weighing the same container-to-isolate move cannot size the saving against their own bill from this account.
A product manager types a description of an app, and a few minutes later there is a working one with a design system and a backend under it [7]. Someone had to decide, before that minute, which parts a model writes fresh each time and which parts were written once by hand and reused forever.
Aha! drew that line at authentication, SSO, database access and email [6]. The sorting rule behind it transfers to any team shipping code generation to non-engineers: for each part of a generated app, ask whether a wrong version shows up as a bug the user can see or a failure they cannot. A misaligned button is the first kind. A login that admits the wrong tenant is the second, and it belongs in a library the model calls.
Container-per-user billing follows sessions, and app-building sessions are bursty. Prompt, wait, edit, walk away. Isolates on a shared instance hold many tenants against the same idle capacity [5]. That idle capacity comes out of Aha!'s own margin: the company has been bootstrapped and profitable for more than 13 years with no salespeople [3].
The episode gives no before-and-after infrastructure bill and no token cost per generated app, and the full transcript is available only to paid subscribers [13]. The chapters on pricing, the isolates architecture and the build pipeline run from 53:15 to the wrap-up at 01:05:52 [14], about 12 and a half minutes of a roughly 66-minute conversation, or a fifth of it [15].
The scope call is the one I would copy first. Aha! says it is optimizing Builder for prototypes, proofs of concept and internal "meta applications" [10]. Regenerating a prototype the model got wrong costs a few minutes; the app that pays people cannot be treated that way, and the enterprise questions the team says it handles (authentication policies, deployment guardrails, PII and PHI) arrive with it [12].
The build is staged: design system first, then prototype, then backend. According to the episode notes, that produces better outcomes than a single open-ended chat prompt [8], and it runs on the agent framework and tool set originally built for Elle, Aha!'s roadmapping assistant [9].
Two axes are enough to make the same decision in your own context: how long the generated artifact has to live, and what share of your sessions are idle. Short-lived artifacts with bursty sessions is the quadrant Aha! landed in, and it is where a container per user charges the most for the least work. Long-lived artifacts on steady sessions is the quadrant where per-user containers are defensible, and Builder's first version was built as though it were there [4].
What to watch
- Whether Aha! publishes a token or infrastructure cost figure for the container version against the isolate version.
- Whether customers push Builder-generated apps into line-of-business use, and what the PII and PHI guardrails allow at that point.
- What the paywalled transcript's pricing chapter at 53:15 says about how Builder is charged: per seat, per usage, or bundled into Aha!'s suite.