Fountible: Built from Scratch with Claude, GPT and Kimi K3
On July 3, 2026, at 21:49, Fountible was an empty monorepo. No inherited editor. No document model. No starter that already knew how a design canvas should behave.
On July 18 at 23:21, I committed the snapshot that closed the first build run: 206 mainline commits across 15 elapsed days and 16 calendar dates. By then, Fountible had become a working design environment spanning web, desktop, a capture extension, collaboration, AI, export, motion, and shaders.
I built and reviewed it with Claude Fable 5, GPT-5.6, and Kimi K3, plus a few smaller assists. This is not a one-prompt story. It is about directing several models through one codebase while keeping the taste and product decisions human.
The Design Is the Code
The idea behind Fountible was simple to say and difficult to build: I wanted the design surface and the production surface to stop being separate worlds.
Traditional workflows create an artifact, then somebody translates it into code. During that translation, details drift. Spacing gets approximated. Responsive behavior becomes a note in the margin. Motion gets reduced to “ease in, 300 milliseconds,” and important interaction details disappear first.
Fountible connects the canvas to the systems that make the result real. It uses React 19, Vite, Tailwind 4, Yjs, and Convex, with Electron for desktop and a Chrome extension for capture. Anime.js powers motion. From scratch did not mean refusing mature tools. It meant the repository began empty and every layer of Fountible still had to be composed, tested, and directed.
I was not drawing an approximation of an editor and asking an engineer to interpret it later. I was judging the actual canvas, inspector, drag behavior, and output in the browser. The design was not waiting to become the product. It already was the product.
The First 73 Minutes
The first 73 minutes still look slightly ridiculous in the Git history.
The repository went from empty to a scaffolded application with a Yjs document model, a renderer and fidelity kernel, a Tailwind worker, canvas pan and zoom, selection, dragging, resizing, autosave, an inspector, and the beginnings of a component library.
That does not mean the editor was finished in 73 minutes. Far from it. It means the load-bearing shape appeared quickly enough to test the idea before spending days polishing the wrong architecture. Claude Fable 5 is explicitly credited on 27 commits, including foundational work from this early phase. I supplied the structure, reviewed what appeared, corrected the direction, and kept moving.
Speed mattered because it shortened the distance between a product decision and evidence. The first pass did not have to be perfect. It had to reveal the next real problem.
And it did. Once selection existed, the inspector had something honest to inspect. Once the document model existed, autosave could be tested against real state. Once the renderer existed, fidelity stopped being a vague goal and became a list of visible mismatches.
The important part was not that AI typed quickly. Each working layer made the next decision less hypothetical.
Two Weeks of Compounding
July 3 was the foundation. July 4 pushed toward the interaction quality people expect from a Figma-like tool. July 5 expanded into variables, Convex, vector editing, gradients, SVG, and HTML. It was also the peak day, with 37 mainline commits.
From July 6 through July 8 came export, Electron, 3D, booleans, masks, fonts, team libraries, and the capture extension. These were not random feature drops. Each forced the shared document and rendering systems to survive new pressure. A mask is not just another toolbar button; it changes how objects compose. A custom font affects loading, measurement, rendering, persistence, and export.
From July 9 through July 11, on-device AI, Claude and Codex runtimes, image generation, and bring-your-own-key support entered the codebase. July 12 through July 15 went deeper into lifecycle behavior, shadows, shaders, motion, timelines, and easing. The final stretch added Figma import, AI-assisted animation, more shader and motion work, Kimi integration, tabs, and sharing.
The pace came from compounding. A reliable document model made collaboration possible. A fidelity layer made import and export more credible. The component system made new interfaces faster to assemble. Tests made aggressive iteration less reckless.
At the July 18 snapshot, 21 projects typechecked and 2,108 tests passed. The web application and extension also built successfully. That mattered more than the commit count. Commits show activity. A product that still builds and passes its tests after two weeks of pressure shows that the activity accumulated into something.
Three Models, One Rotating Team
I did not assign Claude Fable 5, GPT-5.6, and Kimi K3 fixed job titles. There was no “frontend model,” “architecture model,” and “review model.” That would look neat in a diagram, but it was not how the work moved.
I rotated models deliberately. A fresh context could question an implementation that had become too familiar. Another model could suggest a different route when the current one stalled. A model entering later could review what existed instead of defending the decisions that produced it. Rotation helped with alternate implementations, review, unblocking, and breaking the momentum of a weak idea before it spread.
The model rotation was not a benchmark to find one winner. It kept the codebase exposed to fresh reasoning while one product direction stayed consistent.
The Git history gives Fable 5 explicit credit on 27 commits. The other headline models actively built and reviewed the product too, but I do not want to invent clean feature-by-feature attribution that the evidence does not support. Other assistants made smaller contributions. The honest version is collaborative and slightly messy.
The repository kept that mess productive: shared types, tests, builds, commit history, and current browser behavior. Each model inherited the same evidence. My job was to preserve intent across handoffs, reject technically valid work that felt wrong, and decide when another implementation was worth the cost.
The Hard Parts Were Under the Canvas
A canvas can look convincing long before it is trustworthy.
Selection boxes, resize handles, gradients, masks, and shadows are only the top layer. Underneath them, Fountible needed a document model that could persist and collaborate, a fidelity kernel that interpreted decisions consistently, and a renderer that would not quietly change meaning between the editor and the result.
Yjs carried collaborative state. Convex handled the reactive backend. The Tailwind worker connected visual choices to a real styling system. Export then had to turn the internal representation into something useful without pretending every visual idea maps cleanly to production code. The export documentation describes that surface, but building it meant confronting where a design abstraction ends and a browser rule begins.
The same problem appeared with vector operations, boolean shapes, masks, fonts, 3D, shaders, team libraries, import, desktop, and capture. Each affected more than its visible UI. It touched serialization, lifecycle, performance, undoable state, or fidelity.
This was where fast generation could become dangerous. A feature might work in the happy path while weakening the document underneath it. I kept pushing work toward shared systems, then validating across workspaces instead of accepting a local demo. The canvas is what people touch. The architecture below it is why they can trust the next action will not break the previous one.
Where I Still Had to Be the Designer
AI did not decide what Fountible should feel like.
It could produce pan and zoom, but I had to judge whether the canvas felt heavy or precise. It could build an inspector, but I decided what stayed visible, what became contextual, and when useful density turned into noise. It could implement timelines and easing, but technically correct motion can still feel completely dead.
The same was true at product level. In a 15-day build, every “yes” creates five branches. Somebody has to decide which branches matter, which abstractions are premature, and which rough edges block the idea rather than merely offend perfectionism. That was me.
I spent less time translating static screens into specifications and more time reviewing the real thing: dragging objects, opening tabs, importing material, changing variables, and watching where interactions lost clarity. The browser became the design surface because it contained the consequences.
Models lowered implementation cost dramatically. They did not provide the point of view. Fountible still needed someone to say, “This is coherent,” “This is too much,” or “It works, but it does not feel right.” Taste did not disappear. It moved closer to execution.
When the Product Started Using Its Own Builders
About a week in, the project became recursive.
Fountible was being built with AI, and then AI became part of Fountible. The July 9–11 run introduced on-device AI, Claude and Codex runtime connections, image generation, and bring-your-own-key support. The AI documentation covers the product-facing setup, but the interesting shift was conceptual: the agentic workflow shaping the repository could now operate inside the design environment.
The final days pushed that idea into animation, shaders, and motion. Figma import brought existing work into the system. AI-assisted animation helped turn static decisions into temporal ones. Timelines and easing gave those results somewhere concrete to live. The animation documentation shows how that layer fits together.
This was not an AI button added because every product apparently needs one now. It was about reducing another translation gap. If an idea can be described, generated, adjusted, and judged inside the same environment, experimentation gets cheaper. You can try a motion direction against the real composition, reject it, and move again without a separate pipeline.
The boundary stayed the same: generation proposes; the designer directs. AI made more material available and complex implementation reachable sooner. It did not decide which result belonged in the product.
What This Changed for Me
I used to think the fastest AI workflow would come from finding the single best model and learning to prompt it perfectly. Fountible changed that.
The stronger workflow was orchestration: clear intent, a shared codebase, deliberate rotation, aggressive review, and enough automated validation to keep speed from becoming entropy. Claude Fable 5, GPT-5.6, and Kimi K3 were not replacements for a team in a neat one-to-one sense. Together, they became a rotating implementation and review layer I could direct.
Two weeks did not make Fountible finished. It made the product real enough to use, test, explain, and keep building. The July 18 snapshot is not a finish line; it proves that the distance from an empty repository to a serious working system has changed.
You can read the broader Fountible documentation, explore the ideas on the Fountible website, or open the app and judge the result where I judged it throughout the build: in the actual product.
The models accelerated execution. The repository held the memory. Tests kept the speed honest. I still had to decide what was worth making.
That is the part of building I care about most.