Methodology
How we review
Every tool in the index is scored out of five stars on the same ten axes, with the same published weights, against the same six briefs, run three times each. This page is the whole method, including the parts that are uncomfortable to publish.
Disclosure: where the launch ratings come from
Editor panelApp Builder Index launched in 2026 with ratings for eleven builders and now covers thirty-seven. Those ratings are editorially seeded. They come from our own testing panel running the briefs described below, not from a pool of public user reviews, because on launch day no such pool existed here.
Every one of those seeded entries is labelled with an Editor panel badge wherever it appears, including in the user reviews list on each review page and in the structured data we publish. Community ratings accumulate on top of the seeded score and are labelled Community. The review count shown next to each tool is the number of ratings behind that average.
We think this is the honest version of a problem every new review publication has. The alternative, which is to publish nothing until strangers arrive, produces an empty site and no accountability. The alternative we refuse is to present panel scores as though they were crowd scores.
The ten axes and their weights
The overall rating is a weighted mean of the ten axis scores, rounded to one decimal. Nothing else feeds into it: not popularity, not funding, not how much we like the company. The weights below sum to 100 and are identical for every tool.
| Axis | Weight | What it measures and how we test it |
|---|---|---|
| Reliability | 16% | Does the thing keep working. We count failed builds, broken deploys, silent data loss, agent runs that end in an unrecoverable state, and how often a finished feature stops working after an unrelated change. Weighted highest because a builder that is fast and broken is worth less than one that is slow and dependable. |
| Integrations | 16% | How much of a real product you can assemble without leaving the tool. Auth, database, payments, email, file storage, webhooks, third-party APIs. We score both breadth and how much manual wiring each connection actually takes. |
| SEO and GEO | 13% | Whether the output can be found. Server rendering, crawlable markup without JavaScript, metadata and canonical control, structured data, sitemaps and robots, page speed, and whether the pages are legible to answer engines and large language models as well as to classic crawlers. |
| Design quality | 12% | How the default output looks and behaves before a designer touches it. Typography, spacing, responsive behaviour, dark and light handling, accessible contrast and focus states, and whether every project comes out looking like the same template. |
| Agent performance | 10% | How well the agent understands a brief, plans multi-file work, recovers from its own mistakes, and holds context across a long session. Measured with a fixed set of briefs run three times each, scoring completion, regressions introduced, and prompts needed per finished feature. |
| Speed | 9% | Time to a first running screen, time to a deployed URL, and iteration latency once the project has real files in it. We measure wall-clock time on identical briefs, not marketing claims. |
| Value | 9% | What a finished feature actually costs. We record real spend across our test builds, including credits and tokens burned on failed attempts, then compare it against what the tool delivered. Cheap tools that need three retries are not cheap. |
| Scalability | 7% | What happens as the project grows: background jobs, scheduled tasks, queues, migrations, file volume, concurrent users, and whether you can reach the underlying infrastructure when the defaults are no longer enough. |
| API and MCP access | 5% | Whether the platform is programmable from outside: documented REST or GraphQL access, webhooks, CLI, and an MCP server so other agents and scripts can drive it. Increasingly the difference between a tool and a component. |
| Code ownership | 3% | Can you leave. Full source export, real two-way version control, no proprietary runtime required to run the result, and a realistic self-hosting path. Weighted lowest of the ten because most buyers never exercise it, and weighted at all because the ones who need it need it badly. |
| Total | 100% |
Reliability and integrations carry the most weight, at sixteen percent each, because they are what people actually leave over. A tool that generates a beautiful interface and then cannot keep a deployment healthy has not saved anyone any time. SEO and GEO sits at thirteen because for a large share of these projects being findable is the point of building at all. Code ownership sits at three, which is deliberately low: important when it matters, and it does not matter for most projects most of the time.
Worked example. A tool scoring 4.0 reliability, 4.5 integrations, 4.0 SEO, 4.7 design, 4.4 agent, 4.5 speed, 3.9 value, 3.8 scalability, 4.0 API and 4.5 code ownership gives (4.0 x 16 + 4.5 x 16 + 4.0 x 13 + 4.7 x 12 + 4.4 x 10 + 4.5 x 9 + 3.9 x 9 + 3.8 x 7 + 4.0 x 5 + 4.5 x 3) / 100 = 4.2 stars. That is arithmetic you can check against any row of the rankings table, and we publish the raw axis scores as JSON so you can.
The testing specification
Six briefs, each run three times per tool from a clean account, by two testers of different technical backgrounds. Eighteen runs per tool, sixty six runs per brief across the index. We record wall clock time to first working version, number of prompts, credit or token spend, failed deployments, and every point at which a tester had to read code to proceed.
Brief one: the CRUD app
A client register with accounts, roles, a searchable list, a detail view, file attachments and an audit trail. The baseline. Any tool that cannot finish this is not a full-stack builder regardless of what it claims.
Brief two: the marketing site
A five page product site with a blog index, one long article, a pricing table and a contact form that actually delivers. Scored heavily on the SEO and GEO axis because this is the brief where server rendering, titles and canonicals are visible.
Brief three: the integration
Take the register from brief one and connect it to an external HTTP API with authentication, pagination and a rate limit, then persist the result. This is where the integrations axis is decided and where quiet failure shows up.
Brief four: the change of mind
Forty prompts into brief one, we change a core decision: multi tenancy. This is the brief that separates agents that hold a model of the application from agents that pattern match the last message.
Brief five: the breakage
We deliberately introduce a failing migration and a bad third party response, then ask the tool to diagnose and fix. Recovery cost, in both minutes and credits, is recorded here.
Brief six: the exit
Export the finished application and run it on our own machine and then on a plain container host. If it does not start, code ownership scores low no matter what the marketing page says about owning your code.
The fixed checks
Alongside the briefs, eleven capability checks are run identically on every tool and published as the feature table on each review: full-stack backend, database included, auth included, code export, GitHub sync, one-click deploy, custom domain, mobile or native output, team collaboration, public API or MCP server, and self-hosting the output. A capability counts only if we made it work, not if it is listed on a pricing page.
How the SEO and GEO axis is scored
We fetch the generated output with JavaScript disabled and check that the main content is present in the initial HTML. We check that title, meta description and canonical can be set per route. We check for a real sitemap and robots file. We check that structured data can be emitted. We check that an answer engine crawler receives the same content a browser does. Cloaking, in either direction, scores zero on this axis.
Scoring, and who signs it off
Each tester scores each axis independently. Where the two disagree by more than one star, the reviews editor arbitrates and the disagreement is written up as the dissenting view published beneath the verdict. We publish the dissent rather than average it away, because the average hides exactly the information a reader needs.
Re-verification
Ratings decay. Each review shows a real last verified date and a next scheduled check ninety days later, both driven from the database rather than written into the page. The most recent verification across the index was 14 August 2026, and the next sweep is due 12 November 2026.
Independence
App Builder Index is an independent review publication. We buy our own subscriptions on every tool we test, at the same prices anyone else pays, and we test on paid plans because free tiers behave differently. No vendor sees a score before it is published. No vendor has editorial input. We do not sell placements, sponsored positions or rating improvements, and there is no arrangement under which a tool can pay to move up this index.
Where a tool we rate is also a commercial product with a marketing team, we treat its claims exactly as we treat any other: as claims to be tested. Every tool in the index is scored on merit against the same briefs, and the ranking is whatever the arithmetic produces.
Frequently asked
- Are the launch ratings based on user reviews?
- No. The launch ratings are ours. Every builder in the index was scored by our testing panel against the six fixed briefs, and each of those panel entries is labelled Editor panel where it appears. Community ratings accumulate on top of that starting point and are shown separately in each review's user reviews section.
- Do you accept payment for a rating or a placement?
- No. App Builder Index does not sell placements, does not accept payment for a review, and does not let a vendor see a score before publication. We do not currently run affiliate links. If that ever changes, the disclosure will appear on this page and on every affected page before the first link goes live.
- Why stars rather than a score out of one hundred?
- Because a hundred point index implies a precision we do not have. The difference between 78 and 81 is noise. The difference between three and a half stars and four and a half is a decision. We publish one decimal place, which is as fine a resolution as our testing honestly supports.
- How often do you re-test?
- Every builder is re-verified on a ninety day cycle, and immediately if a vendor ships a change that would plausibly move an axis. Every review page shows the real last verified date from our database and the next scheduled check computed from it, so you can see how stale a rating is rather than guessing.
- What happens if we get something wrong?
- Write to editorial@app-builder-index.com quoting the sentence. If a factual claim is wrong we correct it, note the correction on the page, and re-run the affected brief if the error touched a score. Vendors get the same route as readers and no faster response.