The whole capability

What it checks, what it fixes, what it builds.

Atrytone reads an AI-built app and sorts what it finds into 24 areas that a real product needs, in 6 groups. Then it fixes what you say yes to, on a copy, builds what you ask for, and keeps looking after every change, and every night. Below is every area, what code is read, and what is not read yet.

Last updated

Check: the areas it reads

We read your code for 23 of them today, as rules and not as an AI’s opinion. For Tests, we run your app on a copy. We do not test your live site. Nothing changes without your yes.

  • Safe. Data access, Keys, Logins, Access holes, Input safety, Cost guard, Parts, Old runtimes, Browser protections, Build robot.
  • Works. Tests (run on a copy of your app), Errors and uptime, Backups, Speed.
  • Legal. Legal pages, Personal data, Accessibility, Open-source licences.
  • Money. Payments.
  • Reach. Email, Search and launch, Marketing.
  • Run. Staging and deploys, Support.

Which code it reads

Reads JavaScript and TypeScript code, and Python, Go, PHP, Ruby, Rust, Java and C# code for the basics; npm, pnpm, yarn, bun, requirements.txt, uv, Poetry, Pipenv, Rust, Go, PHP, Ruby, Maven, Gradle and NuGet parts; Supabase and Firestore data rules; Stripe, Lemon Squeezy and Paddle payments.

Connect your app from GitHub, or upload its code.

Press Connect from GitHub and choose which repositories to share.

Not read yet

A clean reading says the rules found nothing. It is not a promise that nothing is wrong.

  • Your running site. We read your code, not the live site, so a setting made in a host's dashboard is not seen.
  • Email. The code's side only; your domain's mail records (SPF, DKIM, DMARC) are not read.
  • Backups and restores. We look for a backup in your code. None is run, and no restore is tried.
  • Measured speed. No page is timed. The rules read your code for what makes pages slow.
  • Payments beyond the code. We read your payment code. No payment is made, test or real.
  • Other databases. Data rules are read for Supabase and Firestore. Any other database is not.
  • Your git history. We read your code as it stands now, so a key deleted but still in the history is not seen.
  • Colour contrast. It needs the live page, so it is not read.

Fix: on a copy, on your yes

Atrytone merges the fix into your GitHub repository on your yes. It does not deploy: if your host publishes from GitHub, the merge goes live there.

A fix is tried on the copy with your app's own tests. With none, a JavaScript app can get its first test from the fix.

A fix job copies your code onto our server in Vienna, Austria, works on that copy and keeps a snapshot of the files it read and wrote with the job, so a stopped job can carry on. The copy on our server is deleted when the job ends; a daily check removes any copy left behind once it is 14 days old.

On 10 November 2026, 8 fix jobs had been asked for from the check's results, all in our own workspace and none in a customer's. Our own bar before we call fix jobs reliable: five in a row, on apps we did not hand-pick, each reaching its goal with nobody stepping in. On 10 November 2026 we were at 0 of 5.

Build: ask for more

Ask in plain words for a feature, a new look or a whole new app. The work goes through the same yes and the same record.

Own apps only: 58 build jobs asked for in words, 14 finished, and 3 look jobs asked for, none delivered. Read on 10 November 2026: every one in our own workspace and none in a customer's.

Kept: looked at again and recorded

The code is read again after every change, and every night.

Who asked, which model made the change, what was checked, what it cost and who said yes. Each entry carries the fingerprint of the one before it, so a changed entry shows, and our app can only add to the record. Anyone can check a receipt themselves.

Why it is built this way

  • The whole road, not one scan. Keys, logins, payments, legal pages, speed and 19 more areas, on one page. Each is marked read, or not yet.
  • Your code is re-read, not checked once. It is read again after every change, and every night, so a flaw published later is found too.
  • On a copy, with your yes. Fixes are tried in a sealed box: while your tests run it has no network and none of your keys. Nothing goes live without your yes.
  • A receipt for every change. Every finished change gets a receipt, in a record our app can only add to.
  • One AI builds. A different one checks. The model that makes a fix is not the one that checks it. Settings will not save the same model for both.
  • Your AI, your bill. Your own key pays the model. Every fix job so far has run on Claude. OpenAI and Gemini keys connect today; no fix job has run on them yet.

When a platform changes

When a platform an app builds on changes a rule, the change gets a page of its own: what changed, who is hit, and what to do.

What a report looks like

A report says what was read, every finding as one plain sentence with its area, what was not read, and where each number comes from. The sample is made from our own practice app, never from a customer's, and is not indexed by search engines, because a finding in a search result would read as a statement about someone's app.

Free check