If you've spent any time reading "best tool" roundups, you already know the game. A tool ranks first, and three clicks later you find out the list was sponsored, or the ranking quietly tracks who pays the biggest commission. When you've shipped something real and you're deciding what to build the next year of your work on, that kind of ranking is worse than useless. It costs you time and, eventually, a painful migration.
So before you act on a single Kodbe rating, here's exactly how we make one. Not a vague promise that we're neutral. The actual rubric, the actual method, and the actual money.
Why we rate for day-2, not launch speed
Most tool reviews measure how fast you can get a demo on screen. That's the wrong thing to measure once you already have users. What matters after launch is whether you can understand the app, fix it when it breaks, keep your data safe, pay a predictable bill, and leave if you need to.
We call that day-2: everything that happens after the first deploy. It's the whole reason this site exists, and it's the lens we use on every tool. A tool that ships a landing page in ten minutes but traps your data and hides its logs might score well for launch and badly for day-2. We only rate the day-2 view, and we say so on every rating.
If you want the deeper decision framework this method sits inside, start with our guide on how to choose a tool you can live with. This post is the "how the sausage is made" companion to it.
The fixed rubric: what we score and why
The rubric is fixed. Every tool gets scored on the same four dimensions, in the same order, regardless of who makes it or whether there's an affiliate relationship. We don't add flattering categories for tools we like or bury weak ones.
| Dimension | The question it answers | Why it matters on day-2 |
|---|---|---|
| Maintainability | Can a non-engineer understand, change, and repair this over time? | Determines whether you stay in control or get stuck every time something breaks. |
| Exportability | Can you get your code, content, and data out in a usable form? | This is your exit. No export means no real ownership. |
| Security posture | What does the tool document about auth, data handling, and access? | Detection-first: we look at what's documented, not whether it's "safe." |
| Cost & lock-in | What will this cost as you grow, and how hard is it to leave? | Surprise bills and switching costs are the most common day-2 regret. |
A few things worth being clear about:
- We don't collapse these into a single hero number that hides the trade-offs. A tool can be strong on maintainability and weak on exportability, and you deserve to see both.
- Security posture is descriptive, not a guarantee. A good score means the documentation covers the right ground, not that the tool is secure or that your specific app is safe. Whether your build handles logins, payments, or personal data safely depends on how you configured it, and past a certain point that's a job for a qualified professional. We say that plainly in every security-related rating.
- Cost and lock-in are scored together because they're the same trap from two angles. The vendor lock-in scoring behind the rubric has its own deep dive if you want to grade your current stack: the vendor lock-in scoring behind the rubric.
Our method: documentation review, not hands-on testing
Here's the part most sites won't put in writing. Our ratings come from reviewing published documentation, official pricing pages, changelogs, export guides, and security docs. We do not run benchmarks. We do not stress-test performance. We do not claim hands-on results we didn't produce.
That's a deliberate limit, and it cuts both ways.
What it means you can trust. Every claim in a rating traces back to something a vendor published or a document anyone can check. We don't invent test numbers, we don't fabricate load times, and we don't quote prices we can't point to. Where a specific price, limit, or capability is central to a score, we cite the source. Where we cannot point to one, we leave the claim out rather than guess.
What it means you should verify yourself. Documentation can be out of date, incomplete, or optimistic. A tool that documents an export feature might export something less useful than it sounds. So we treat our rating as a starting map, not the final word, and we tell you which claims to confirm inside your own account before you commit.
If you want to see the method applied to real tools, our Lovable vs Bubble vs Replit comparison walks through the same four dimensions side by side.
How affiliate links work, and what they never change
Some tool links on Kodbe may be affiliate links. If you click one and later pay for the tool, we may earn a commission at no extra cost to you. That's disclosed here, and the full terms live on our Affiliate disclosure page.
Here's the line that matters: an affiliate relationship never changes a score, a ranking, or a recommendation. The rubric is applied the same way whether a tool pays us nothing or pays a commission. We rate tools we have no affiliate relationship with, and we publish low scores for tools we do. If a tool earns a weak rating on exportability, it earns a weak rating on exportability, commission or not.
We keep the money and the method separate on purpose, and we'd rather lose a commission than a reader's trust. The independence commitments behind that are written down in our Editorial policy, so you can hold us to them rather than take our word for it.
How we date, review, and correct ratings
A rating is only useful if you know how fresh it is. Tools change pricing, add export options, and shift their security posture constantly, so a two-year-old rating can be quietly wrong.
- Every rating carries a "last reviewed" date. If it looks old, treat it as old and verify the current facts yourself.
- We re-review on a schedule and when things change — a major pricing update, a new export feature, or a security change triggers a fresh look.
- We correct in the open. When we get something wrong or a tool changes, we update the rating and note what changed, rather than silently editing history. Corrections are part of the method, not an admission we hide.
How to use our ratings (and where to verify for yourself)
Treat a Kodbe rating as a shortlist tool, not a verdict. Read the dimension scores rather than any single number, weight the dimensions that match your situation (exportability matters more if you're nervous about lock-in, security posture matters more if you handle personal data), and then confirm the load-bearing facts inside your own account before you commit real work to a tool.
The Tools guide explains how to apply these criteria to any tool you are considering.
In Plain English
What this is: a public description of exactly how Kodbe rates AI and no-code tools — a fixed four-part rubric (maintainability, exportability, security posture, cost and lock-in), ratings built from documentation review rather than hands-on benchmarking, and an affiliate disclosure that never moves a score.
Who it helps: anyone who's been burned by pay-to-rank lists and wants to know whether these ratings are independent before trusting them, especially solo builders choosing what to build the next year on.
When to use it: read this once before you rely on any Kodbe tool rating, and keep it in mind whenever you see a "last reviewed" date on one.
What to do next: check the last-reviewed date on any rating you're using, read the dimension scores instead of a single number, and verify the facts that matter most to your build inside your own account.
If you want the full independence and affiliate terms, read them on our Disclosure page. That's the document that keeps this method honest, and it's the one to hold us to.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.