# How to take over a design built in Figma Make and develop it with Claude Code > Source: > Published: 2026-09-07 03:21:45+00:00 From February to April 2026, I launched four web apps, each starting from a code bundle that Figma Make (Figma's AI feature that generates a working front-end code bundle from a design) had spat out: a beauty-curation site, a gift-record app, a plush-toy album, and a UI mock for an AI development tool. Every one of them starts its repository in a state where "the look is already finished." In this article I look back — from the actual config files and commit history — at what I did to get those generated outputs into a state where I could take over development in Claude Code (Anthropic's CLI coding agent) and start working on them, and at how far each of the four repositories progressed or stalled. A Figma Make export runs as-is with `npm run dev`. The README tells the story. ``` # Beauty Information Curation Site This is a code bundle for Beauty Information Curation Site. The original project is available at https://www.figma.com/design//... ## Running the code Run `npm i` to install the dependencies. Run `npm run dev` to start the development server. ``` A README that says "the original lives in Figma." That symbolizes the character of the output: the code is a **projection** of the Figma design, and the code is not the source of truth. On top of that, if you look at `package.json`, every dependency is exact-pinned. ``` { "dependencies": { "next": "15.3.4", "react": "19.1.0", "react-dom": "19.1.0", "lucide-react": "0.487.0", "motion": "12.23.24", "tailwind-merge": "3.2.0" } } ``` Fixed versions with no `^`. As a snapshot of the moment it was generated, it is highly reproducible, but leave it as-is and it grows stale with no one ever updating it. There is no data layer either. The screens are pretty, but behind them everything is mock data — no persistence, no authentication. "It runs, but there is no foundation to grow it on" — this was the common starting point across all four repositories. [画像: The README and package.json of a Figma Make output (screen reconstructed and anonymized; contents are as measured). The README states plainly "the original lives in Figma / this is a code bundle," and dependencies are exact-pinned like next 15.3.4. The code is a projection of the Figma design, and as-is the source of truth is not on the code side]（画像は別途ホスティング予定） Even from the same Figma Make starting point, how far I pushed toward a product varied with what each one was. **The UI mock for an AI development tool** I stopped at a mock, as the name says. Its README stayed the boilerplate from generation time. Its purpose was "a look for reviewing the UI," and there was never any intention to turn it into a product, so I didn't force it to grow. Deciding to throw something away is a decision too. **The beauty-curation site** went the furthest. It works as a static site, so I set Next.js (a React web framework) to export statically and put it on Amplify (AWS's web hosting service). ``` js // next.config.ts — export as a static site const nextConfig: NextConfig = { output: "export", images: { unoptimized: true }, trailingSlash: true, }; # amplify.yml — serve out/ as the artifact (no SSR) frontend: phases: preBuild: { commands: [ "npm ci" ] } build: { commands: [ "npm run build" ] } artifacts: baseDirectory: out files: [ "**/*" ] ``` With `output: "export"` I made it a pure static site with no SSR (server-side rendering), and with `images.unoptimized` I also dropped Next.js's image-optimization Lambda. Do this and Amplify just serves `out/`, which makes operations very light. In March I switched the repository's deploy method to "automatic deploy via GitHub integration," carrying it from a generated output all the way to a "site that gets served." **The gift-record app** and **the plush-toy album** had dense product specs, yet stalled at the data layer. The former's README spells out the MVP (Minimum Viable Product) scope concretely — dashboard, people management, gift records, calendar, anniversary management, and five business-facing screens, all implemented in Atomic Design (a UI-component method that builds screens up from small parts). But at the top of the "deferred / undecided" list, it says this: - Actual data persistence (currently mock data) - Authentication and user management - Notifications The look and the screen transitions are finished, yet the widest gap of all sits between the mock data and a real backend. The plush-toy album, too, was built up to Vite (a fast front-end build tool) + React 18 + a five-layer Atomic Design, and even had its design philosophy nailed down (a gentle earth-tone palette specified as concrete values) — but it likewise stalled before persistence. [画像: How far each of the four Figma Make-based repositories got (screen reconstructed and anonymized; states are as measured). The UI mock stayed a mock, the beauty-curation site reached static hosting, and the gift-record app and plush-toy album stopped just short of the data layer]（画像は別途ホスティング予定） If you grow four repositories separately, CI (continuous integration; running tests automatically on each change), security, and quality all end up scattered and inconsistent per repo. So at the end of June I put a group of repositories including these ones onto the same self-hosted security CI **all together**. The traces remain in the commit logs, in the same form across every repository. ``` chore: onboard ELN self-hosted security CI (#1) (2026-06-27) chore(dependabot): group+monthly to cut hosted CI cost (2026-06-27) fix(security-pr): rename sticky comment script to .cjs for ESM repo compat (2026-06-29) ``` That last rename to `.cjs` addresses a problem where the comment script posted on security PRs couldn't be loaded in ESM-configured repositories (`"type": "module"`). Figma Make outputs assume ESM (ECMAScript Modules, the modern JavaScript module system), so placing a CommonJS (the older Node.js module system) script as a plain `.js` makes it fail with `require is not defined`-type errors. Because a whole group of repositories hit this at once, I renamed them to `.cjs` across the board to fix it. "Turning an output into a product" is not only about adding features — it is also about putting them onto this kind of governance foundation and getting them in step. [画像: The shared commits left in the same form across the four repositories (screen reconstructed and anonymized; commits are as measured). I onboarded them all at once onto the same self-hosted security CI, and fixed the problem of CommonJS scripts not loading in ESM repositories with a cross-cutting rename to .cjs]（画像は別途ホスティング予定） The reasons sort into three. First, **where the source of truth lives.** As the README says, "the original lives in Figma" — the code is a projection. The moment you start editing the code here, Figma and the code become double-managed, and unless you decide which is authoritative, a regeneration will overwrite your work by accident. So the first step toward productization was to make up my mind: "from now on, the code is the source of truth." Second, **frozen dependencies.** Exact pins are righteous at generation time, but with no one owning updates they rot. Only once you add a lockfile and CI do you reach a state where you "can update." Third, **the missing data layer.** The output is closed around its look and its mocks, so the "backbone of a product" — persistence, authentication, notifications — is entirely untouched. Even when the look is 90% done, this backbone, which looks like the remaining 10%, actually accounts for the bulk of the work. The endpoints split cleanly. The mock I decided to discard stayed a mock; the site that works as static reached hosting; the product that needs a data layer marks time just short of the mock data. And every repository did get onto the shared CI and security gate. "With Figma Make the look stands up in a day" is true, but misjudge what comes after it — handing over the source of truth, thawing the dependencies, the data layer — and something that looks "almost done" can stop moving for months. `output: "export"`) to keep serving it light. If you need neither SSR nor an image-optimization Lambda, don't carry them.