featkpr is made by DevClusterAI / Tim Derzhavets
featkpr, a tool that maps what a web app does for its team to approve, is built by one person, Tim Derzhavets, at DevClusterAI Ltd in Toronto. This page says why, the rules it keeps and how it is built.
DevClusterAI Ltd, Toronto · started 8 Sep 2026 · this page as of 28 Sep 2026
The first three weeks #
Dated from the project's decision log. The product figures are featkpr's records for BookStack, each with its own date.
- 8 SepThe ideaFeatures first, then flows, then tests: know what a product does before testing it.
- 17 SepA first productBookStack, open source and about the size of a real company's app.
- 18 SepThree designs, one chosenBuilt side by side and judged by three reviewer agents that didn't build them; the simplest correct one won.
- 21 SepThe first build goes liveEvery package was checked by three reviewer agents, for the spec, for mutations and for hostile inputs, before it merged.
- 22 SepThe app, and a namefeatkpr's app, with its first twelve screens; the product became featkpr.
- 25–26 SepCrawl and run167 screens walked; the first tests run, each one sent again as the wrong user.
- 27 SepFigures exported; site movedfeatkpr's BookStack figures exported from its records with their dates, and this site moved to featkpr.com.
- 28 Sepfeatkpr reviews featkprIts first verdict on its own pull request; release flows drawn and approved; a test copy that sends real mail. BookStack's latest run: 311 tests, 276 proven by the wrong-user check.
I build platforms for a living, and I kept seeing the same thing: an app grows for years, nobody can list what it does any more, and the tests guard less than anyone thinks.
Most testing tools start from the tests. featkpr starts one step earlier: it reads the code and walks the running product to write down what the product does, as features and the flows people take. Tests come from that list, and each one is sent again as the wrong user, someone who should get the opposite answer. The test must then fail; if it still passes, it was not checking the permission.
It is early, and this site says so wherever it matters. The library shows how far featkpr has got on each product, and the roadmap shows what comes next.
Tim Derzhavetsbuilds featkpr · DevClusterAI Ltd, Toronto
Three rules featkpr keeps #
Each rule is written into the app and into this site. Where one is not met yet, the row says so.
Truth #
Every word and number on a screen is a stored fact, with its date and where it came from.
On this site, BookStack's figures are featkpr's records, exported with their date, and a test fails the build if a page types one by hand.
The app's own footer reads “every word on a screen is a stored fact”. A count on a screen is computed from the store, never typed.
Two sections, the crawl and the Flows board, were read from the app's screens and the build log, not exported from the records yet.
Receipts #
A result comes with what was sent and what came back, so anyone can check it.
Each figure here carries its date and its commit.
Each test keeps the request it sent and the answer, for its own user, for someone allowed as a control, and for the wrong user.
POST /books/{bookSlug}/convert-to-shelfsent three times; only the signed-in user changes- The test's own userholds only book-update-all BookStack hides the book: “Book not found” (404) the test passes
- Admin, the controlholds every permission the same request gets through: 302 → /shelves/{new shelf} a refusal is the permission's, not a broken page
- Admin, as the wrong usershould get the opposite answer the same test, run as Admin: BookStack lets Admin through, so the “hidden” check fails the test fails, as it must: proven
No public run to browse yet: today you see the receipts on a call.
A person decides #
featkpr drafts; a person keeps or drops.
A demo request is read and answered by Tim, by hand.
Every drafted flow waits for a verdict, and every open question comes with a default already in force, so nothing stalls while it waits.
You can't yet correct a drafted goal's links to the code one by one; you keep or drop the goal whole.
How it is built #
One person, a small cloud and a homelab. Your code is read in one place and your test copy runs in another; nothing touches your production.
- Yours: the repository (read access only) and a test copy of your app with one user per role; never your production.
- featkpr: reading, crawling and testing run as jobs on a homelab cluster; the service and its store at Fly.io in Toronto; bodies on Cloudflare R2; named models through OpenRouter get excerpts only.
- What you see: the app on Cloudflare Pages, opened by a link per person.
Tim, with coding agents. Each package of the first build was checked by three reviewer agents, for the spec, for mutations and for hostile inputs, before it merged.
first build complete 21 Sep 2026The service and its Postgres store at Fly.io in Toronto; stored bodies on Cloudflare R2; crawls and test runs as jobs on a Kubernetes cluster in a homelab; the app and this site on Cloudflare Pages.
compute in the homelab, state in the cloudPython for reading and testing, Playwright for the crawl and the tests, React for the app. Hosted AI models through OpenRouter, each named, on capped monthly budgets.
each model named, each spend on a capped monthly keyHow the pages on this site are drafted, checked and corrected, and where every number comes from: how we write and check.
See it on BookStack #
Half an hour, live, your questions first. Tim replies by hand.