Eyes for your AI
it got slow
Something you built is taking too long, or hangs, or quietly got worse this week — and you can describe it but not read it.
guess 1 · guess 2
Whatever is writing your code has changed a couple of things and made it worse, because nothing it can see tells it what your app is actually doing.
the fix
Boosthis measures the running app, names the screen or route that is bad and how bad it is, and hands over the written fix for that exact problem — to you, and to the assistant doing the typing.
A drawing of the headline, not a reading.
Built for the person shipping a real product that was largely written by a coding agent, and for the small team whose phone app and back end each blame the other for being slow. It drops into JavaScript / TypeScript, Python, Java, Go, PHP, C# / .NET, Ruby, Dart (Flutter), Swift, Kotlin (Android), Rust or Elixir — in phone apps, browser pages, back-end servers, Bun and edge functions. If you already have a performance specialist and a stack you trust, this is probably not for you.
The languages you write
…and the places that code runs
Example project
It never reads your source code and never sends a full web address: route and screen names are normalised before anything is uploaded. A project sends nothing until its kit starts with your project key. That install step turns sharing on, full timings included, and the Full telemetry switch on your dashboard turns the full timings off again (the edge kit has a single mode and ignores it).
What you are buying
This is the shape of it a day after a kit goes in: the things you shipped, each with a score and a plain verdict, and the worst one carrying the written fix it belongs to. Your assistant reads the same thing you do.
/orders/:id 47
The fix filed against /orders/:id
What is happening. The route assembles the whole answer before it sends any of it, so the customer waits for the slowest part of a page they can already mostly see.
What to change. Answer with the part that is ready, and fill the rest in behind it.
How you will know it worked. The same route stops rating poor, and stays out of it across a day of real traffic.
Checked, not claimed
Our own availability is measured from outside Boosthis, by a watcher that is nothing to do with our servers — but it is not a figure this page can work out as it renders, and a stale percentage is worse than none, so it is not printed here. The watcher's reading is on the status page, good news or not.
What we support
Two different questions, kept apart on purpose. What you write is a language: JavaScript / TypeScript, Python, Java, Go, PHP, C# / .NET, Ruby, Dart (Flutter), Swift, Kotlin (Android), Rust and Elixir. Where it runs is a place — phone apps, browser pages, back-end servers, Bun and edge functions — and the same JavaScript can run in every one of them. That is why fifteen toolkits cover twelve languages, and why there are sixteen separate things you can install.
Three things are genuinely identical everywhere: the scoring model and its shared budgets, the strict PII guard on everything a kit sends, and the AI tool surface your assistant reads. How much a runtime can measure is not identical — a browser has no garbage collector to inspect, Rust has no runtime to ask, an edge isolate is gone between requests — so the fullest kits take 96 readings and the newest take 25. The plans page lists what each runtime can measure, row by row and generated from the kits themselves; find yours there before you choose a plan.
There is a one-command scanner that answers it for you, with no account and no key: it walks the folder, reads the names and contents of the files that list your dependencies, and tells you which kits the project needs and where they go. It never reads your source code, sends nothing anywhere, and makes no network call of its own — the answer is printed in your own terminal.
The iOS and Android apps people install — React Native, Flutter, Swift (Apple) and Android (Kotlin). Here Boosthis reads how long the first screen takes to appear, how long until it answers a tap, how long that tap then waits, and how steady the screen stays afterwards.
Requirements: React Native 0.76.0 or newer; React 18.2.0 or newer.
Drop useBoosthis("ScreenName") into any screen for
instant, on-device performance ratings — every screen measured, and
regressions caught early. A built-in dashboard tab shows the full
meter page inside your own app, and your AI assistant can read the
same numbers.
Requirements: Dart 3.0.0 or newer (below 4.0.0); Flutter 3.10.0 or newer.
One line — BoosthisFlutter.runApp in main(),
in place of Flutter's own — rates every
screen against the same shared budgets, straight from the engine's own
frame timings. Catches what actually slows Flutter apps down, from
raster-vs-build jank and frozen frames to image-cache weight and
memory growth.
Requirements: Swift toolchain 5.5 or newer; iOS 14 or newer; tvOS 14 or newer; macOS 11 or newer.
One line — BoosthisApple.start at launch — rates every
screen of a native iOS, iPadOS, macOS, tvOS or visionOS app against
the same shared budgets, straight from the app's own run loop and
MetricKit. Catches what actually slows native Apple apps down, from
unresponsive hangs and scroll hitches to memory headroom before
jetsam.
Requirements: Android API level 24 (minSdk 24); Kotlin compiler 2.0.21 (lowest tested; no floor declared).
One line at launch rates every screen of a native Android app against the same shared budgets, straight from the app's own frame timing and the ART runtime. Catches what actually slows Android apps down, from frozen frames and app hangs to GC pauses, thermal throttling and cold-start cost.
Anything a person opens in a browser tab — Web (browser). Here Boosthis reads INP — how long a page takes to respond after someone clicks — and the rest of the Core Web Vitals, page by page.
Requirements: Chromium 140.0.7339.16 (lowest tested; no floor declared).
Call startWebVitals() once at page load for real
browser Web Vitals per page — INP for how quickly the page answers a
click, plus the rest of the Core Web Vitals — rated against the same
shared budgets. Catches the browser-specific problems that hurt real
visitors, with a concrete fix for each.
The services your app calls — Node.js / Express, Python, Java, Go, PHP, C# / .NET, Ruby, Rust and Elixir. Here Boosthis reads how long each route takes to answer, and what the runtime was busy doing while it took that long.
Requirements: Node.js 24.13.0 (lowest tested; no floor declared).
Add the boosthis() Express middleware — or
attach() on any other Node server — and optionally
mount(app) for the live /_boosthis/ page.
Catches the runtime-specific problems that actually slow Node services
down, with a concrete fix for each.
Requirements: Python 3.10 or newer.
Add @track_perf("route") to any function. One extra
line — boosthis.mount(app) — mounts a live dashboard at
/_boosthis/ on your existing Flask or FastAPI port. Run
boosthis serve without a web app for the same dashboard
at localhost:7787. Catches the problems that actually
slow Python services down, with a concrete fix for each.
Requirements: Java (OpenJDK) 19.0.2 (lowest tested; no floor declared).
Wrap any com.sun.net.httpserver handler with
BoosthisHandler, or any framework route with the generic
Wrap helper, for per-route ratings against the same
shared budgets. Catches the problems that actually slow JVM services
down — with a concrete fix for each, zero dependencies, JDK stdlib
only.
Requirements: Go 1.25.0 or newer.
Wrap any http.Handler with
boosthis.Middleware for per-route ratings against the
same shared budgets. Catches the problems that actually slow Go
services down — with a concrete fix for each, zero dependencies, pure
stdlib.
Requirements: PHP 8.1 or newer.
One line — \Boosthis\Boosthis::start() in your front
controller, or the ready-made Laravel / PSR-15 middleware — rates
every route against the same shared budgets. Catches what actually
slows PHP-FPM sites down, from OPcache and memory limits to realpath
cache pressure, with a concrete fix for each and no extensions
required.
Requirements: .NET 8.0 (lowest tested; no floor declared).
One line — app.UseBoosthis() in your ASP.NET Core
pipeline, or Boosthis.Start() anywhere else — rates every
route against the same shared budgets. Catches what actually slows
.NET services down, from GC pauses and heap headroom to thread-pool
starvation, with a concrete fix for each and not one NuGet package to
install.
Requirements: Ruby 3.0 or newer.
One line — Boosthis.start, or the ready-made Rails
Railtie / Rack middleware — rates every route against the same shared
budgets. Catches what actually slows Rails and Rack apps down, from GC
pressure and memory headroom to slow outbound calls, with a concrete
fix for each.
Requirements: Rust 1.88 or newer.
One layer — boosthis::middleware for axum or
actix-web — rates every route against the same shared budgets. Catches
what actually slows tokio services down, from blocking calls on an
async worker to task backlog and connection churn, with a core that
pulls in nothing but std.
Requirements: Elixir 1.14 or newer (below 2.0).
One plug — Boosthis.Plug in your Phoenix endpoint —
rates every route against the same shared budgets, and reads what only
the BEAM can tell you: scheduler utilisation, run-queue backlog,
reductions, per-process message queues and ETS growth. Zero
dependencies — it runs on OTP alone.
The same back-end kit, on Bun's own engine instead of Node's. Here Boosthis reads the same per-route timings as a Node.js server, minus the few readings Bun's engine does not expose.
Requirements: Bun 1.3.6 (lowest tested; no floor declared).
Bun runs the back-end kit's own files on Bun's engine instead of
Node's — the same boosthis() middleware, the same
/_boosthis/ page, and its own recipe on your Setup page.
It registers under its own name so your dashboard can say plainly
which readings Bun's engine does not expose, rather than showing them
as blanks on a Node project.
Code that runs at the edge, close to whoever asked for it. It runs on Cloudflare Workers, Deno Deploy, Deno, Supabase Edge Functions, Vercel Edge Functions and Netlify Edge Functions. Here Boosthis reads how long each request spends inside the isolate — which is as much as something that stops existing between requests can know.
Requirements: workerd (the Cloudflare Workers runtime) 1.20260825.1; Deno 2 (lowest tested; no floor declared).
Wrap a Cloudflare Worker or a standard request handler to measure reliability, access pressure, cookie safety and cold starts where the host allows it. It needs neither Node.js nor a filesystem. It adds no page and no bubble to the function on purpose — its numbers appear on your Boosthis dashboard instead.
Scoring model
Every runtime is rated against the same shared budgets and distilled into a single 0–100 score, so you can compare performance across RN screens, Python routes, and Node.js handlers side-by-side — no per-tool guesswork.
Measuring and rating happen where your code runs. Nothing is uploaded
until the kit starts with your project key, the install step that turns
sharing on; from then it sends the timings, the issue labels and the
screen or route name — normalised, so it is a label like /orders/:id and never a real address. A new project sends its full timings from
the start, and the Full telemetry switch on your dashboard turns them off
(the edge kit has a single mode and ignores it).
How it works
Detection runs entirely on-device; clear fix guidance is delivered inside your dashboard and AI tools exactly when an issue is detected.
React Native: useBoosthis("ScreenName").
Python: @track_perf("route").
Node.js: app.use(boosthis()).
One line per screen or route, and your project key connects it.
Each kit takes the measurements its own place can actually take — INP and the Core Web Vitals in a browser, first-screen and tap timings in a phone app, per-route timings on a server — rates them against the same shared budgets, and detects known problems as it goes. What each place measures is listed above.
Connect your AI assistant so it can read the full live meter page, per-screen diagnosis, session summary and fix suggestions — for the projects you connect, and nothing else. How to connect your AI.
After the fix
Fixing it once is not the end of it. The next time your coding agent touches that part of the app it writes the same thing again, because nothing it reads before it starts knows what went wrong last time.
Boosthis writes a short block of house rules for
AGENTS.md — the standing-instructions file a coding agent
reads before it writes anything. You copy it in; it is your repository,
not ours.
Every line comes from something Boosthis measured in your own app, with your own evidence beside it. Nothing from anyone else's project goes in it: no averages, no "apps like yours", and no fix text — that stays on the page it belongs to, and the block links there.
A rule that has stopped being true is worse than none, so the block is stamped with the day it was generated, and a problem your project no longer reports drops out of the next copy.
What you get
Finding the slow thing is half the job. This is what Boosthis does with it afterwards.
Every problem a kit reports is tied to a fix in the Boosthis library: what causes it, what to change, and how to tell it worked. Your AI assistant reads the same library, so it works from that written fix instead of inventing one — what it changes in your code is still its suggestion and your call.
When something throws where a kit can see it, the crash is filed with your project — through the same privacy guard as every other payload. The kit never takes your app down with it: a failure inside Boosthis can only ever silence Boosthis.
Boosthis watches your projects between visits and emails you when a screen or route turns bad, when a fixed one comes back, or when a project that was reporting goes quiet. Muting an alert silences the email, never the measurement — and the page says how much a mute is hiding.
Once a month, a written summary per project: what got faster, what got slower, and what was not measured at all. A month with no data is reported as a month with no data, never drawn as a good one.
On the plans that include it, one request can be followed from the screen a person tapped, through the services behind it, and back — so a slow screen is blamed on the part that was actually slow. Available in 15 of 15 runtimes.
Every project has a dashboard with its meters, its issues and its history; and 7 of 15 kits — Node.js / Express, Python, Java, Go, PHP, C# / .NET and Ruby — can serve that same page inside your own app as well. Our own uptime is on the status page, whether it is good news or not.
Why not what you already have
Most people reading this already have something in place, and all three of these are good at the job they were built for. None of them answers the question you are actually stuck on.
It tells you what broke, and it is the right tool for that. But slow is not an error: the route that takes six seconds and the screen that stutters never throw anything, so they never reach it.
One run, on one machine, on one network — usually against the pages a stranger can reach. It cannot open the signed-in screen your customers spend their day in, it says nothing about your server, and it has never seen your phone app at all.
It reads the code, not the running app. With no measurements it reasons about what the code could do rather than what it does do, which is why the second guess is so often worse than the first.
What Boosthis adds is the input all three are missing: readings taken inside the app while real people use it, tied to the screen or route they came from, in a form your assistant can read — and each problem arrives with a written fix rather than an opinion.
Pricing
Choose monthly or yearly below, where a year costs 10 months, and the price you see is the final amount charged — inclusive of any applicable taxes, with no hidden fees. Enterprise is priced by arrangement. Charged in Saudi Riyal (SAR): the SAR figure shown is the exact amount taken from your card. The dollar figure is an approximate conversion at the fixed rate of SAR 3.75 to $1, and your own bank converts at its own rate, which may include a fee. Major cards are accepted. You choose your plan when your free trial ends, or during it if you would rather subscribe straight away.
Try Boosthis free for 7 days. It is the whole Team plan, every feature switched on: up to 6 projects, up to 7 people and 12,000 AI credits. No card and no payment details: confirm your email with the 6-digit code we send you, and the trial starts as soon as you enter it. On day 7 the trial ends and nothing is charged — subscribe whenever you like to carry on. Your projects, keys and everything already measured stay exactly as they are, whether you subscribe or not. Subscribe during the trial and you keep the free days you have left: you pay the ordinary price once, and the month you have paid for starts the day the trial would have ended. You get an email when the trial starts, one a few days in, and one when it ends. End the trial whenever you like — one click, and nothing is ever charged for it. One free trial per account and per confirmed email address.
Where most projects should start. For a developer who wants the whole picture of their project.
For when more than one person is responsible for the same project.
Priced by arrangement. Tailored to enterprise needs.
Plans renew automatically — monthly plans each month, yearly plans each year — until cancelled. Cancel anytime: you keep your plan until the end of the period you have paid for, and a lapsed plan never deletes your data. Fees are prepaid for the period you chose and non-refundable except where the law requires — full details in the Refund & Cancellation Policy.
Privacy
Boosthis is built to keep sensitive data inside your app rather than filter it afterwards. Measuring and rating happen inside your own process, and a project uploads nothing until its kit starts with your project key: that install step is what turns sharing on. Read the full policy in our Privacy Policy.
From then on, three things go to your dashboard: the timings, the issue labels, and the normalised name of the screen or route they belong to. A new project shares its full timings from the start; the Full telemetry switch on your dashboard turns them off from the app's next launch (the edge kit has a single mode and ignores it), and a build without the key sends nothing at all. Your source code, request and response bodies, cookies and session data are never collected. Reading something inside your process and collecting it are two different things. The one exception is the AI-call meter: to tell repeated prompts apart it reads up to the first 4,096 characters of an outbound request body to an AI provider, inside your own process, and reduces it immediately to a single number — no body text is stored, uploaded or recoverable. Nine other bounded reads work the same way — the token counts a provider states in its reply, which kind of refusal a provider's error reply is, a stack trace or a secret about to reach one of your users, an error-shaped JSON answer returned with a 200, the method name in a tool-call request your app serves, the query and body of an outgoing call, folded into one number, the flags on the cookies your app sets, a fixed list of named headers and the query of the kit's own upload URLs — each reduced on the spot to a number, a flag or a label from a fixed list, and each set out with its own limit in the Privacy Policy. One bounded read is not a reduction at all — the HTML page the dashboard bubble is written into — held only long enough for the one script tag to be written in, then handed back with nothing taken from it. One read is neither narrowed to a label from a fixed list nor limited in length — the query on requests to the kit's own read endpoints — used as the caller wrote it to pick which of the kit's own rows come back, then dropped with the reply. One bounded read does not stay inside your process — the trace id and span id another instrumented service already put on the request — each adopted only when it is exactly the shape the kits mint, then carried onward or uploaded with that request's timings so one action across your services reads as one. Two reads send what they hold to Boosthis — the owner link's one key, boosthis, in a page's address; and the kit's own two owner cookies — and what is sent is only a credential Boosthis itself issued, returned to be checked on a call of its own, never inside an upload. One read is neither bounded nor reduced to a number, and you ask for it yourself: the code you post to the kit's own rule matcher. Apart from the trace id and span id another instrumented service already put on the request, the owner link's one key, boosthis, in a page's address and the kit's own two owner cookies, none of what is read here is stored, uploaded or recoverable from what is uploaded, and the guard on the upload path refuses outright any payload carrying a request or response body, a header, a cookie or a query value — and those ids are uploaded as fields of their own, never as the header they arrived in, and the owner proof and pass go to Boosthis on calls of their own, never inside an upload.
Before you decide
Plans run from about $35 to $70 a month (SAR 131 to SAR 263 charged), or about $349 to $701 a year (SAR 1310 to SAR 2630 charged) — a year costs 10 months. The price you see is the final amount charged, inclusive of any applicable taxes, with no hidden fees. Enterprise is tailored to enterprise needs and priced by arrangement. Every plan covers every language, every place your code runs and every reading; what changes between them is how many projects and people they hold, and how much AI use a month includes — the plans, side by side.
On day 7 the trial ends and nothing is charged — subscribe whenever you like to carry on. Your projects, keys and everything already measured stay exactly as they are, whether you subscribe or not.
Boosthis covers JavaScript / TypeScript, Python, Java, Go, PHP, C# / .NET, Ruby, Dart (Flutter), Swift, Kotlin (Android), Rust and Elixir, in phone apps, browser pages, back-end servers, Bun and edge functions. What each one can measure is not identical and cannot be — a browser page cannot be asked what a server can — so the plans page carries a table, generated from the kits themselves, of what your runtime actually reads. Check yours there before you pay. If you are not sure what your project even spans, the scanner answers that without an account.
Nothing at all until the kit starts with your project key: that install step is what turns sharing on, and there is no separate switch to flip later. From then on, three things: the timings, the issue labels, and the normalised name of the screen or route they belong to — a label like /orders/:id, never a real address. Your source code, request and response bodies, cookies and session data are never collected. The full list is in the Privacy Policy.
You keep your plan to the end of the period you have already paid for. After that the projects on it are frozen rather than emptied: they stop reporting, the dashboard says why, and everything already measured stays where it is — a lapsed plan never deletes your data, and paying again turns it straight back on. Fees are prepaid for the period you chose and non-refundable except where the law requires — Refund & Cancellation Policy.
No. The meters, the issues, the written fixes and the alerts are all in your dashboard and work on their own. Connecting an assistant is optional, covers the projects you connect and nothing else, and exists so the thing writing your code can read your real numbers instead of guessing at them. Your assistant can look, never change a setting, a key, a measurement or a rule. What it can add is its own word: a note of a change it made or plans to make, a promise you asked it to remember, or a report of how it fixed a crash, for a person at Boosthis to review. Each is kept apart from what Boosthis measured.
Setup questions — getting a kit into your project, connecting an assistant, what one particular kit can measure — are answered in the help centre, and are not repeated here.
Start here
Create an account, confirm your email, drop the kit into the project, and let it watch real traffic for a day. Then you have what the rest of this page describes: the worst screen or route named and rated, the written fix beside it, and the same numbers in front of whatever is writing your code. Want the detail first? Compare the plans, or read how it goes in over at the help centre.
