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-three. 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.
Helpful counts work the same way and are held to the same rule. A helpful count is only ever the number of votes cast by signed-in readers, one per reader per review or reply, counted from the vote records themselves. Nothing is seeded, so the panel reviews published at launch carry no helpful votes at all, and a review with none shows no count rather than a zero.
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 the weighted mean of the axis scores that apply to that tool, 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.
When an axis does not apply, we publish n/a rather than a low number. n/a means the axis does not apply to this tool. It builds internal software behind a login, a native store app or an API, so there are no public crawlable pages to test. The axis is left out of the overall rating and the remaining weights are renormalised, rather than the tool being scored down for something we did not test. In practice the formula is: sum of each applicable axis score times its weight, divided by the sum of those same weights, rounded to one decimal, with an exact half rounding to the nearest even tenth. A tool scored on all ten axes divides by 100. A tool whose SEO and GEO axis does not apply divides by 87. Today that applies to 11 tools, all of which build internal software behind a login, native store apps or APIs: Retool, Airtable, Xano, Glide, Softr, Rork, a0.dev, Bravo Studio, Knack, Adalo, Thunkable.
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 6 September 2026, and the next sweep is due 5 December 2026.
Currency, region and what a published price means
Every price on this site is the lowest recurring price the vendor publishes for its entry paid tier, in the vendor’s own currency, with the vendor’s own unit, and with the billing term always stated next to the figure. We do not convert between currencies, because a converted figure is a number no reader will ever be charged. Where a page shows euros it is because the vendor itself quotes euros.
One rule applies to all thirty-three rows. Most vendors publish two figures for the same entry plan, a lower one billed annually and a higher one billed monthly, and this column used to headline whichever figure the vendor’s own page led with. That produced eight rows quoting an annual rate beside twenty-five quoting a monthly one, in a single column, which is worse than picking either. So the headline figure is now the lowest recurring published rate, the billing term is printed with it, and where the monthly-billed rate differs it is given in the note underneath.
Prices were captured from a European IP address on the date stated on each page. That matters: several vendors geo-route their pricing pages, so a reader in another region may be shown a different currency or a different figure for the same plan. Many vendors also default the billing toggle to annual, which shows a lower monthly number than the one a monthly subscriber pays, so we record which term the captured figure belongs to and print it beside the price.
A price is the entry point, not the bill. Where a tier gate, a per-seat charge, a credit ladder or a required add-on changes what a working setup costs, that qualifier is published next to the figure rather than left for a reader to discover after signing up.
Sourcing: where every published fact comes from
Every statistic we publish traces either to the vendor’s own live page or to a named public source, and carries the date we fetched it. Each review lists its sources with those dates. A claim we could not verify against a live page is either not published or published as not verified, and never dressed up as a finding.
Where a reputable current public benchmark covers a tool we rate, we cite it by name, with its URL and our fetch date, as corroborating evidence alongside our own editorial rating rather than in place of it. When such a benchmark contains a finding we believe has been superseded, we say so on the page and cite what superseded it, rather than quietly leaving the finding out.
Star ratings and written reviews are counted separately
Two different numbers appear on every review page and they are not interchangeable. The rating count is the number of star ratings behind the community average, and it drives the histogram. The written review count is the number of those ratings that also carry text. Every written review carries a rating, but most ratings arrive without any text, so the written count is always the smaller of the two.
Neither number feeds the editorial star rating. The weighted score on this site is our panel’s, computed from the axes above; the community average sits beside it and is never blended into it.
Changelog
- 19 and 20 August 2026: full vendor re-verification
- We re-checked every tool in the index against the vendor’s own live pages over two days. The pass corrected the price layer across the whole index, so every figure now carries the vendor’s own currency, unit and billing term; removed four tools that had left the category, each of which keeps its page with a dated withdrawal notice; revised several axis scores; and rewrote the verdicts and feature cells that stated things the vendors’ own pages contradicted. No star rating was changed by the copy pass that followed.
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 the desk through the contact form at /contact, 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.