How to take over a design built in Figma Make and develop it with Claude Code

A developer recounts taking over four web apps generated by Figma Make and developing them with Claude Code, noting that the generated code is a projection of the design with exact-pinned dependencies and no data layer. One project, a beauty-curation site, was successfully deployed as a static site on AWS Amplify, while others stalled at the data layer or were intentionally left as mocks.

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/<id /... 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.