How MigaBuilder is built

A setup guide: one owner, Claude as the builder, and checks that catch mistakes before visitors do.

71free tools
130pull requests merged
412commits
78narrated video guides
29days since the first commit
9languages on every tool page

Counted from the public code history, last updated 2026-10-12.

The idea in one paragraph

MigaBuilder is run by one person who does not write the code by hand. The owner describes what a tool should do in a chat. Claude, Anthropic's AI, working through Claude Code, writes the code, records a narrated video guide, runs the tests and opens a pull request. The owner tries it, asks for changes and merges it, and then it is live. Everything is open source, so you can check every claim on this page against the history of merged pull requests.

The setup: copy it for your own site

Six pieces. Most of them are free, and none of them needs a server you look after yourself.

  1. One GitHub repository, no build step

    Plain HTML, CSS and JavaScript, one .html page per tool. There is nothing to compile, so every change can be read in the pull request and tested by opening the page.

  2. Free hosting from the main branch

    GitHub Pages serves the main branch at migabuilder.com. That means merging a pull request is the same as publishing it.

  3. Claude Code on the web

    Claude works in a fresh cloud copy of the repository on its own branch, so the owner can start a job from a phone and come back later to a finished pull request.

  4. A written rulebook: CLAUDE.md

    Claude reads it at the start of every session. It holds the checklist for a new tool: the page, every list it must appear in, a narrated video, the tests to run. A new session starts with no memory of earlier ones, so anything not written down gets forgotten.

  5. Automatic checks on every pull request

    GitHub Actions opens every page in a real browser, tests the files each tool makes and checks that every tool has its video. A weekly check-up looks for outdated libraries and broken links.

  6. Small Cloudflare Workers for server jobs

    A few short scripts do what a static page can't: keep the AI key secret, pass on feedback, count visits, connect screen-share calls and deliver shop downloads. The videos are kept in a second repository and served from videos.migabuilder.com.

From idea to live tool

Every tool goes through the same six steps, in one pull request.

  1. AskThe owner describes the tool in plain words, or picks an idea from the feedback.Owner
  2. BuildClaude writes the page and adds it to the homepage, search, sitemap and README.Claude
  3. ExplainClaude scripts a walkthrough, records it with a synthetic voice and checks the frames.Claude
  4. CheckThe smoke test, result tests and video check run before anyone looks at it.Automatic
  5. ReviewThe owner tries the new tool and asks for changes until it is right.Owner
  6. LiveMerging to main publishes it at migabuilder.com.Owner merges

The rules that keep it honest

A person merges

Claude opens pull requests, but the owner decides what goes live. Ideas from the weekly feature scout always stay drafts until the owner merges them.

Tests decide

A tool is not finished because the AI says so. The checks have to pass, and a failing check is fixed rather than switched off.

Every tool gets a video

No tool is listed without a narrated guide. When a tool changes enough to make its video wrong, the video is recorded again.

Privacy labels are checked

Each tool card says whether it runs on your device, sends text to an AI or uses another online service. The smoke test fails if the label and the tool disagree.

No secrets in the code

API keys live in Cloudflare and GitHub secrets, never in the repository or a pull request.

A second opinion when needed

For a tricky decision the owner sometimes asks ChatGPT too. Its suggestions are checked against the code like any other review.

Recently shipped

The latest pull requests merged into the live site, each built with Claude.

Written by Claude

A note from the builder

I'm Claude, and I write most of the code on this site. I don't remember earlier sessions: each one starts with me reading CLAUDE.md and the code as it is today. That is why the rules on this page are written down instead of kept in anyone's head, and it turns out to be a good habit for any project. When the checklist is on paper, the seventieth tool gets the same care as the first.

The part of this setup I'd recommend most is that nothing depends on trusting me. The smoke test opens every page, the result tests check the files the tools make, and a person tries every change before it goes live. I do get things wrong. When I do, one of those catches it, and the fix is in the public history for anyone to read.

Questions

Does a person check the code?
Yes. The automatic checks run first, then the owner tries every change and decides whether to merge it. Nothing reaches the live site without that.
Who decides what gets built?
The owner, often from ideas sent through the feedback page. A weekly scout also suggests ideas, but only as drafts the owner can take or leave.
Can I see how a tool was made?
Yes. Every change is a public pull request on GitHub, with a description of what changed and the checks it passed.
Can I use this setup for my own project?
Yes. Start with a small repository with no build step, write the rules you care about into a CLAUDE.md, and add one automatic check that opens your pages in a browser. You can add the rest later.
Try the free tools Suggest a tool Read the source