The roadmap on one time axis: what shipped, day by day, and this week.
One lane per part of the product. Shipped work sits on the day it landed and this week's work at today. What comes next has an order, not a date, so it sits under the axis with Later and the ideas. Select any node or bar for the same detail as its card on the board.
as of 1 Oct 2026 · 31 shipped · 4 being built · 12 next, in order · 30 later · 16 ideas · weeks ahead are named, never dated
Weeks ahead are named, never dated: this week, next week, the week after (Tim, 1 Oct). Shipped means live in production; merged and waiting for the next release is "on dev, shipping". The order before 1 Oct moved to Later, after these two weeks.
Select a node or a bar for its details. On a keyboard, Tab reaches each one; ← and → move along a lane.
the map6 dated, 9 not
flows4 dated, 5 not
decisions5 dated, 5 not
on top: tests and proof2 dated, 15 not
on top: changes and releases4 dated, 4 not
platform and the library14 dated, 20 not
A filled node shipped on that day · an open bar is being built this week · the shaded part is ahead of today, and nothing in it is dated: Next, Later and the ideas are listed under the axis. Commits: commits on the main development line, per day (git log; 28 Sep counted on dev to 06:33 EDT).
Shipped 9 Octflows
Immich's crawl and flows in production
Immich's crawl and the flows it draws, in production since 9 Oct.
- Why
- Immich is the app featkpr is shown on all the way. Its flows come from its crawl.
- What it made possible
- Immich's crawl, run on our homelab, reached production on 2 and 9 Oct: 394 screen captures of 74 paths, as admin, as a user and signed out. Its flows were drafted from it on 9 Oct, and every Immich goal now has its mechanic on the site.
- What we know
- Immich's crawl ran in a homelab lane as admin, user and anonymous; the lane was released on 1 Oct (#960)the release log ·
- production's records for Immich: 394 screen captures of 74 paths (161 screens), taken on 2 and 9 Octproduction's store as ae_reader, read 20 Oct 2026, 12:13 UTC (tools/site_numbers.py, numbers.json) ·
- production's records for Immich: 60 drafted flows, all on 9 Octproduction's store, read only, read 20 Oct ·
- What shipped
- captures as admin, as a user and signed out, on 2 and 9 Oct
- flows drafted from the crawl on 9 Oct
- what each goal does, on Immich's mechanics page
Shipped 1 Octthe map
A new app reaches the map
A new app's code extracted at its read's commit and named; Immich, InvenTree and Formbricks are on the map.
- Why
- Naming works on what the first read stored. Storing it at the read's own commit keeps the map, the crawl and the tests on one version of the code, and a named map is what a person approves or rejects.
- What it made possible
- A newly added app's code is now extracted at the commit its first read used, and its features are named from that code. Immich, InvenTree and Formbricks are on the map. Released in #965.
- What we know
- Merged as #965the release log ·
- In the release of 1 Oct, about 16:00 EDT (#967), live in productionproduction's deploy log ·
- Immich 294, InvenTree 240 and Formbricks 89 features, with no goals yet (read 1 Oct, 22:29 EDT)production's API ·
- What shipped
- Immich: 294 features in 43 modules, named from its API's own tags
- InvenTree: 240 features in 15 modules
- Formbricks: 89 features in 3 modules
- all three named from code, not yet crawled or proven: no goals yet
- counts read from production's API, 1 Oct, 22:29 EDT
Shipped 1 Octplatform and the library
Adding an app finishes inside the app
The owner confirms how the app ships as a step of Add an app, so setup finishes inside the app.
- Why
- How an app ships decides where a goal counts as proven. The owner confirms it once, while adding the app, instead of in a file we write.
- What it made possible
- Add an app now ends inside the app: featkpr drafts how the app ships from its first read, and the owner confirms that release flow as a step of setup. Released in #970.
- What we know
- Merged as #970the release log ·
- In the release of 1 Oct, about 19:40 EDT (#979), live in productionproduction's deploy log ·
- What shipped
- the release flow featkpr drafted, confirmed as a step of Add an app
- once approved, the release flow is stored for the app
Shipped 1 Octplatform and the library
The honest Running step
After Go, a step that says featkpr can't start the app by itself yet, and records how it starts.
- Why
- A step that pretends to start an app would be the first false thing an owner sees. Saying what happens next keeps setup honest until featkpr can start apps itself.
- What it made possible
- After Go, Add an app shows a Running step that says what is true today: featkpr can't start an app by itself yet. It records how the app starts, and a lane for the app is built by hand. Released in #975.
- What we know
- Merged as #975the release log ·
- In the release of 1 Oct, 21:38 EDT (#981), live in productionproduction's deploy log ·
- What shipped
- says plainly that featkpr can't start the app by itself yet
- records how the app starts, for the lane built by hand
Shipped 1 Octon top: changes and releases
The test map at review
On a pull request, the tests that touch the change, and the changed code no test names.
- Why
- A reviewer reads the verdict faster with the tests behind it right beside it, and changed code that no test names is where to look first.
- What it made possible
- On a pull request, featkpr lists the tests that touch the change, and the changed code that no test names. Released in #963.
- What we know
- Merged as #963the release log ·
- In the release of 1 Oct, about 16:00 EDT (#967), live in productionproduction's deploy log ·
- What shipped
- the tests that touch a change, beside the verdict
- the changed code that no test names
Shipped 1 Octplatform and the library
Postgres connections kept under a budget
Postgres connections kept under one budget per process; each product loaded on first use.
- Why
- With more apps added, opening every product at start would crowd the database. A budget, and loading a product only when it is asked for, keep one busy app from starving the others.
- What it made possible
- Each serving process keeps its Postgres connections under one budget, and each product is loaded on first use instead of at start. Released in #973.
- What we know
- Merged as #973the release log ·
- In the release of 1 Oct, 21:38 EDT (#981), live in productionproduction's deploy log ·
- What shipped
- one connection budget per serving process
- each product loaded on first use
Shipped 1 Octflows
Immich crawled as admin, user and anonymous
Immich crawled as admin, user and anonymous on our homelab; its captures reached production from 2 to 9 Oct.
- Why
- Immich is the app featkpr is shown on all the way. Its flows come from its crawl, one per role.
- What it made possible
- A crawl of Immich as an admin, as a signed-in user and anonymously ran in a lane on our homelab. Released in #960. Its captures reached production from 2 to 9 Oct, with the flows they draw.
- What we know
- Merged as #960the release log ·
- In the release of 1 Oct, about 16:00 EDT (#967), live in productionproduction's deploy log ·
- What shipped
- one crawl per role: admin, user and anonymous
- run on our homelab, against our own copy of Immich
- its captures reached production from 2 to 9 Oct
Shipped 1 Octplatform and the library
Three more open-source apps added, through Add an app
Immich, InvenTree and Formbricks added through Add an app on 1 Oct.
- Why
- Apps on other stacks test whether featkpr's readers and crawl hold up beyond the ones it knows, and whether Add an app works without us.
- What it made possible
- Immich, InvenTree and Formbricks were added on 1 Oct through the same flow anyone uses: the address, a token where one is needed, the first read. Their features were named the same day, once a new app could reach the map.
- What we know
- Three apps on different stacks named as the next targets on the counting protocolresearch report T2 ·
- Added in production through Add an app on 1 Oct; no features named yetproduction's API ·
- What shipped
- added through Add an app, with no setup files written by hand
- named on 1 Oct, in "A new app reaches the map"
Shipped 1 Octplatform and the library
The home page opens on the film
The home page opens on a short film, and /film holds it on its own.
- Why
- A first-time visitor should see what featkpr does before reading about it.
- What it made possible
- featkpr.com now opens on a short film of one feature followed through the app, and the film has its own page.
- What we know
- Direction C of the home page design pass, approved; the site released on 1 Octthe release log ·
- What shipped
- the home page leads with the film
- /film, the film on a page of its own
Shipped 1 Octthe map
Readers for five more kinds of app
Hono, OpenAPI with SvelteKit, Django, React Router and Next.js apps read from their code.
- Why
- Every new stack used to need its own adapter before featkpr could read it. Five readers in two days open the library to apps that are not built like BookStack.
- What it made possible
- featkpr now reads the routes and screens of apps built with Hono, an OpenAPI spec with SvelteKit, Django, React Router and Next.js. New apps on those stacks get a first read without anyone writing an adapter. Live on the service by 1 Oct.
- What we know
- Merged as five pull requests on 30 Sep and 1 Oct; the service release of 1 Oct carries all fivethe release log ·
- Python (FastAPI, click) and React readers shipped earlier, on 28 Septhe register ·
- What shipped
- Hono: a service's routes, mounts and prefixes included (30 Sep)
- OpenAPI and SvelteKit: a target's API spec and a SvelteKit app's routes (30 Sep)
- Django: a Django and DRF project's URL configuration (1 Oct)
- React Router: an app's screens (1 Oct)
- Next.js: an app's file routes (1 Oct)
Shipped 30 Sepplatform and the library
Add an app reads a new repository in production
Add an app's first read clones the repository in production.
- Why
- Add an app shipped on 30 Sep, but its first read needs the repository on disk. Without git in the service, the flow stopped at its third step.
- What it made possible
- The service image now carries git, so Add an app's first read clones the repository it was given instead of stopping. Live on the service on 30 Sep.
- What we know
- Hot fix: git in the service image, for Add an app's first read; the service redeployed the same eveningthe release log ·
- What shipped
- git in the service image, for Add an app's first read
Shipped 30 Sepon top: changes and releases
featkpr runs its own goals on a test copy of itself
A test copy of featkpr on the homelab, so its own goals get runs and flips.
- Why
- featkpr's goals are drafted from its code, but nothing has run them yet. Its own test copy gives them runs and flips, and every change to featkpr becomes a test of featkpr.
- What it made possible
- A disposable featkpr on the homelab, seeded with made-up data, signed in as the owner and as nobody, with a script per goal rendered from its command. featkpr's own goals now get runs and wrong-user flips, away from production.
- What we know
- featkpr's own goals are drafted, and no run or flip names them yetthe goals v2 design pass ·
- The crawl may send forms on the throwaway copy only, never against productionthe product-three plan ·
- Released to production on 30 Sep; the test data is made up, a scrubbed production copy stays offthe register, featkpr as its own target ·
- What shipped
- a throwaway featkpr on the homelab, with no network beyond itself and no production setting
- made-up data by default; a scrubbed copy of production stays switched off
- a script per goal, rendered from the goal's command with no model call
Shipped 30 Septhe map
featkpr maps its own code: its parts, and the goals a change can alter
featkpr's own parts as modules, goals linked by events, and the goals its own pull requests touch.
- Why
- An event-sourced tool is not shaped like BookStack. Mapping featkpr itself shows the readers work on a second kind of app, and gives its own pull requests goals to be judged by.
- What it made possible
- featkpr now reads its own parts as the modules of its map and links its goals through the events they write. On its own pull requests it names each goal a change can alter by the goal's key, not by a route's name. Released in #930.
- What we know
- Naming goals by key was more precise than by route name, measured on featkpr's recent merged pull requeststhe register, self-impact ·
- Modules and event links measured offline on production's code, with no paid callthe register, featkpr on featkpr ·
- What shipped
- featkpr's own parts become the modules its features are named in
- goals linked through the events one writes and another reads
- on featkpr's own pull requests, the goals a change can alter, named by key; a file in no part is said to be unseen, never "0 goals"
- featkpr's own features named in production: 146 features in 4 modules, with 45 goals (read 1 Oct 2026)
Shipped 30 Sepplatform and the library
Add an app, as a guided flow, private repositories included
Repository, Access, First read, Answers, Go: an app added as one flow, private repositories included.
- Why
- Adding an app took hand-written setup files and a deploy, so only we could do it. As one flow with the token step in place, an owner can bring a private repository and watch its first map fill in.
- What it made possible
- Adding an app is now one flow of steps: Repository, Access, First read, Answers, Go. A private repository gets its token step right under the address, with a link that opens the platform's token page already filled in. The token is sealed the moment its check passes, and only its fingerprint is ever shown again. Released in #930.
- What we know
- Tim added a private repository and could not find where the token goes; the redesign puts it under the addressthe add-an-app design pass ·
- The key that seals tokens set on the service; private repositories no longer stop at "no key"the register ·
- A token page with its fields filled in ahead works on GitHub, GitLab and Codebergonboarding research, platform docs ·
- Released in #930 with direction B, "The route"the release ·
- What shipped
- the steps Repository, Access, First read, Answers and Go, with one next action on each screen
- for a private repository, the token step inline, from a token page that opens filled in
- the token sealed as soon as it checks out, only its fingerprint shown; a token that cannot do the job is never kept
- the key that seals tokens live in production since 29 Sep
Shipped 30 Sepdecisions
Goals get an overview, a compare view and a page each
Every goal in one list, two to four compared side by side, and a page per goal.
- Why
- Choosing a goal through a list of names made them hard to compare. With every goal on one sheet, next to what proves it, choosing becomes reading a list.
- What it made possible
- The Goals screen now opens on a Ledger of every goal: what proves it, the roles that can reach it, its relations and its last run, sortable and filtered in the address. Two to four goals can be compared side by side, and each goal has its own page. Released in #930.
- What we know
- Direction A, the Ledger, chosen of three for choosing and comparing goalsthe goals overview design pass, approved ·
- Released in #930; the goal relations were loaded again on 30 Sep: 731 linksthe release, and production's API ·
- What shipped
- /goals: every goal in one sortable list, grouped by module, with proof as N of M facts
- compare two to four goals: the links between them first, then their facts, roles and relations row by row
- a page per goal, with previous and next through the filtered list
- the relations between goals, loaded on 30 Sep: 731 links, 22 goals with a paired-run proof on the Ledger
Shipped 29 Sepdecisions
The first relations between goals, proven by paired runs
Two goals' tests run on one fresh copy, so a relation between them is proven, not guessed.
- Why
- The map says how features lead into each other. Until a run shows it, a link such as "creating a book enables turning it into a shelf" is only read from the code. A paired run turns it into a fact, or finds the bug that stops it.
- What it made possible
- A relation read from the code is a guess until a run shows it. featkpr now runs two goals' tests on one fresh copy of BookStack to prove that one enables or disables the other. Of the 28 pairs it could run, 27 were proven, 0 refuted and 1 left unproven by a real BookStack bug, now reported upstream.
- What we know
- 229 links of the kinds a pair can run; 28 had a runnable test at both endsthe pair plan at BookStack 1633b3ab ·
- 27 proven, 0 refuted, 1 unproven, in 39 legsrun-scripts lane 36580253632, folded in production ·
- Restoring a deleted page revision answers 500 instead of 404, reproduced on v26.09.1 and reported as #6233BookStack's issue tracker on Codeberg ·
- What shipped
- 27 of 28 runnable pairs proven, 0 refuted, 1 unproven, at BookStack 1633b3ab
- 39 legs, 167 seconds of legs, about 7 minutes of homelab lane
- the unproven pair is BookStack issue #6233: restoring a deleted page revision answers 500 instead of 404
- 201 more pairs wait for tests of their goals
Shipped 29 Sepdecisions
Goal model v2: typed goals, their relations and a proof per fact
Goals as typed changes, linked by kind, with each fact's proof named.
- Why
- "Covered" meant three different things before, which is how one card read 0 while every test had passed. A goal made of facts, each with its own proof, says exactly what is known and what is not, and the relations say how one feature leads into another.
- What it made possible
- A goal is now a typed change: who does it, the commands they send, and the record going from one state to another, with what can stop it and what it leaves behind. Goals are linked by kinds of relation (enables, disables, leads to and more), each fact of a goal says which run proves it, and the app shows goals per goal, around a goal, by role, by feature and as a matrix.
- What we know
- Proof per fact, served by one read per goal, built on the runs and flips already stored (no new kind of record)the register, goal model stage 3 ·
- Direction A (the goal drawn as its change) for the goal page, the compass for what is around it, the switchable matrixthe goals v2 design pass, approved ·
- What shipped
- a goal as a typed change: an actor, commands, a record going from one state to another, what stops it, what it leaves behind
- relations between goals by kind, such as enables, disables and leads to
- a proof per fact: the outcome, each refusal, each role and each side effect says which run proves it, or that nothing does yet
- the goal views: a goal's own page, around it, by role, by feature, a matrix, and in a pull request
Shipped 28 Sepplatform and the library
Fast CI records every test before it skips any
Every test's inputs recorded, and what skipping would save reported, with nothing skipped yet.
- Why
- A pull request waited close to an hour for its tests, much of it for a runner. Recording what each test depends on first shows which runs could safely be skipped before anything is.
- What it made possible
- featkpr's own pull-request and nightly lanes now record a fingerprint of each test's inputs and report what a skip would have saved, while still running every test. A release whose code is exactly a tree a green lane already tested reuses that result.
- What we know
- Stage 1 merged: the pr and nightly lanes record and report, and skip nothingthe register, fast CI stage 1 ·
- Stage 2, the skipping, is built and off until a week of records shows no mismatchthe register, the morning brief ·
- What shipped
- each test's fingerprint: the functions it ran, the files it read, its dependencies and its image
- a report of what the next stage would skip, with nothing skipped
- a stored green that later fails empties the store and pages Tim
- the nightly run stays the full, no-skip ground truth
Shipped 28 Sepon top: changes and releases
featkpr reads its own code and reviews its own pull requests
featkpr maps its own Python and React code and posts a verdict on its own pull request.
- Why
- A second stack shows the readers are not shaped around BookStack, and reviewing its own changes every day is the quickest way to find where featkpr is wrong.
- What it made possible
- featkpr now maps itself, a second stack (Python and React): 207 candidates and 39 goals read from its own code, with no model call. Its first verdict went up on its own pull request #798.
- What we know
- 207 candidates, 39 goals and 108 code anchors read from featkpr's own code, with no model callthe production store ·
- Its surfaces, counted in the repository: 40 API operations, about 24 screens, 72 commandsthe product-three audit ·
- The pull request's code is only read; the shipped service writes the verdict, so the tool never judges itselfthe product-three design ·
- What shipped
- 207 candidates read from featkpr's own API, commands and screens
- 39 goals drawn from its own code
- first verdict on its own pull request #798: pass, 0 goals touched
- its own changes go dev → a daily release pull request → prod, and featkpr reviews the release
- Python (FastAPI routes, click commands) and React screens read; GitHub repositories followed by webhook
- what reviewers said, from people, bots and agents, kept as evidence beside the verdict
Shipped 28 Sepon top: changes and releases
How your app ships, drawn and approved
featkpr reads how an app ships, proposes the flow, and a person approves the drawing.
- Why
- "Proven" needs a place: proven on the development branch is not proven in the release. Knowing the flow lets every verdict say which stage it speaks for, and a release's verdict cover everything merged since the last one.
- What it made possible
- featkpr reads how an app ships (branch names, tags, merge history), proposes one of nine flows with its evidence, and a person fixes the drawing and approves it. The approved drawing then shows what featkpr does on each arrow.
- What we know
- Nine flows it can propose, drawn from Kargo's stages, Sentry's releases, Octopus lifecycles and GitHub environmentsrelease-flow research ·
- BookStack has no promotion pull requests: development is merged into release, then tagged; featkpr reads it as a flow of its ownBookStack's branches and tags, read from Codeberg ·
- Three editor designs drawn on real flows; the drafting board chosen, with an outline view for keyboard usersthe release-flow design pass ·
- What shipped
- nine flows it can propose, each with its evidence
- BookStack read as development → release by a pushed merge, then tags
- a release's verdict covers everything merged since the last one
- the map follows BookStack's development branch, never a pull request's head; names carried across the move for less than a cent
Shipped 28 Sepon top: tests and proof
A test copy that behaves like real hosting
A test copy with real mail and a real queue, and a report of how close it is to hosting.
- Why
- A test that passes on a copy unlike real hosting says little about real hosting. Reporting how close each copy is, on every run, lets a goal say where it was proven.
- What it made possible
- The copy featkpr tests now sends real mail, runs a real queue, and says how closely it copies real hosting: 11 of 17 checks on the production-like tier, 4 of 17 on the everyday one, with the same results on both.
- What we know
- Production-like copy: 11 of 17 checks match real hosting, the everyday copy 4; 311 tests passed on both, and none changed result between themthe comparison at BookStack's development tip ·
- Mail of all 7 kinds caught in one run, where the day before none wasthe run at BookStack's development tip ·
- Only the copy with a real queue showed that a queued comment mail for a page deleted before it sends failsthe production-like run ·
- An independent review of the first design found four places where it would have made verdicts wrong, among them users hard-coded so the wrong-user runs could silently skipthe environments review ·
- What shipped
- mail really sent and caught: 7 of 7 kinds, a new user's sign-up included
- people as personas with a role and a mailbox; the wrong user is derived, never skipped
- a fidelity report on every run
Shipped 27 Sepdecisions
Goals that carry their proof, and the first merge-request verdict
Each goal keeps its own record of proof, and the first verdict on a real pull request.
- Why
- A goal is what a person wants to reach, such as publishing a page. When each goal carries its proof, a change is judged by the goals it touches, not by the lines it edits.
- What it made possible
- A goal now keeps its own record of proof, computed from runs. Each drafted goal is checked by a second model, and its code anchors are put to a vote of three cheap models, before a person sees it. The first verdict on a real pull request went up: BookStack's #6213, in a private mirror. It read "needs a look, 2 goals touched, 0 proven, nothing ran": on 27 Sep featkpr did not yet run a pull request's own code. It did on 28 Sep.
- What we know
- A checking model caught 46 of 48 overclaiming goal sentences across the drafts testedthe drafting-model experiment ·
- A vote of three cheap models caught 94% of planted anchor errors with 2 false alarms, where one model alone raised about 40the drafting-model experiment, on planted cases ·
- The first checked run: 103 of 168 goals walked by a flow, 243 flows in allthe register ·
- First verdict on BookStack #6213: needs a look, 2 goals touched, 0 proven, nothing ranfeatkpr's private mirror ·
- What shipped
- each goal's record of proof, live 27 Sep 14:30 UTC
- goals checked by a second model and a vote of three, 103 of 168 walked by a flow
- how complex each goal is, drafted from what drives it; a person's word is feedback on the draft
- the first merge-request verdict, on BookStack's pull request #6213
- replies to the verdict's comment are read back, shipped 27 Sep (replies arrive since 27 Sep night)
- built and shipped: what a test changed (effects) and zero-code OpenTelemetry; effects recorded on BookStack's run of 28 Sep
- the crawl may edit and delete what it made: verified on a test copy of BookStack on 27 Sep, 4 edited, 4 deleted, nothing else touched
Shipped 26 Sepon top: tests and proof
The first tests run, with the wrong-user check
Each test is sent again as the wrong user, and must then fail.
- Why
- A passing test only means something if it can fail. Sending each test again as someone who should get the opposite answer proves the permission check exists, and turns a green run into evidence.
- What it made possible
- Proof that a permission check exists: each test is sent again as the wrong user, someone who should get the opposite answer, and must then fail. And a check that lists what featkpr missed when it started again with no help.
- What we know
- 304 tests ran and passed, 0 failed; 269 of them proven by the wrong-user checkBookStack's run at 0f5164ec, 17:42 UTC ·
- Run again at BookStack's development tip: 311 tests, 276 proven, 0 failedthe production store, exported ·
- Starting again with no help, featkpr missed 605 of 2,372 items; the check lists each one with its reasonthe fresh-start audit ·
- What shipped
- every test passed on the first run, 0 failed, and most were proven by the wrong-user check (the counts are in the report of 26 Sep)
- the Runs page
- the missed-items check: 605 of 2,372 missed
Shipped 25 Sepflows
The crawl sends forms
The crawl fills in forms, and flows are drafted from what it really did.
- Why
- A flow drawn from real screens can be judged by a person in seconds: they see the path and keep it or drop it. Sending forms is what lets the crawl reach the screens behind a save.
- What it made possible
- Flows drafted from what the crawl really did: a goal, then the flow a person takes to it, screen by screen, for a person to keep or drop.
- What we know
- 167 screens captured and 8 forms sent, signed in as Adminthe admin crawl at 0f5164ec ·
- 149 flows ending at 89 features now wait on a person's keep or dropthe app's Flows screen ·
- What shipped
- 167 screens captured as Admin
- flows drafted to goals
Shipped 24 Sepplatform and the library
Sign-in, and a second app
Sign-in for owners, and Shlink read and named beside BookStack.
- Why
- A pipeline built around one app proves little. A second app on another stack shows which parts are general and which were only BookStack's.
- What it made possible
- Shlink beside BookStack in one deployment: the first sign that the pipeline is not built for one app.
- What we know
- Shlink read from its code: 20 features named from 28 routesShlink's map export ·
- What shipped
- the products screen and switcher
- Shlink read and named
Shipped 22 Septhe map
The first map, and the name featkpr
BookStack's routes grouped into named features, module by module.
- Why
- The map is what every later step hangs on: flows are drawn across its features, tests are written per feature, and a change is traced to the features it reaches.
- What it made possible
- BookStack's routes, grouped into features by module, for $0.99 of model calls. The map every later step hangs on.
- What we know
- BookStack's map today: 298 features in 13 modulesthe production store, exported ·
- Of the routes BookStack's own route list names, the reader dropped 16, all console commands no reader handles yetthe fresh-start audit ·
- What shipped
- features named by module
- the name featkpr
Shipped 21 Sepdecisions
The first build goes live
The web app and its API, with the decisions waiting on a person as cards.
- Why
- A product owner needs one place that shows what waits on them. The screens were designed as one system before any was built, so every screen added since has had a place to go.
- What it made possible
- An app a product owner opens: the screens were designed as one system first, then built.
- What we know
- Three whole design candidates drawn and compared before building; the simplest correct one chosen, with the best ideas of the other two grafted inthe design choice ·
- What shipped
- the web app and its API
- decisions waiting on a person, as cards
Shipped 18 Sepplatform and the library
The specification and its test plan
A written design with three rules, and a test plan every part is checked against.
- Why
- Three rules keep the product honest: nothing a model judges changes a mechanical result, a suspected bug is never quietly accepted as the new normal, and naming organises features but never deletes one. The test plan holds every part to them before it merges.
- What it made possible
- Every part of the build is checked against a written test plan before it merges.
- What we know
- The naming pass raised precision from 0.26–0.44 to 0.764; allowed to drop candidates, it lost 21 of 130 features, so naming may never deletethe design, measured on BookStack ·
- On the one real regression in BookStack's history, a model judge called it "just a rename" three times out of three; the mechanical check got it rightthe design, measured on BookStack ·
- Nine templates wrote tests for 20 of 20 revision cases with no model call; all 20 passed, and all 20 failed as the wrong userthe design, section 9 ·
Shipped 17 Sepplatform and the library
Fourteen research reports, and a first app
Fourteen research reports, and BookStack chosen as the first app to measure.
- Why
- A claim about one app is only worth something if the next app can be counted the same way. The research fixed a counting method first, so every later number on this site has a method behind it.
- What it made possible
- BookStack chosen, and a counting protocol every later app is measured on, so a claim about one app can be checked on the next.
- What we know
- The market map found no vendor holding a map of an app's features and how they relate; its verdict was to go ahead on the mapresearch report T1, the market map ·
- BookStack counted on a ten-count protocol: 93 screens, 77 API operations, 13 modulesresearch report T2, the counting protocol ·
- A commercial AI testing agent run on BookStack as the line to beat: it reached 40 of 93 screens and 6 of 42 features, and no permission gateresearch report G1.1, a trial run ·
- What shipped
- BookStack counted at its v26.05.5 release
- a shortlist of the next three
Shipped 8 Sepplatform and the library
The project starts
One question: can a tool list what a web app does, and prove it on the running app?
- Why
- Most teams hold no written record of what their product does: documentation drifts and tests only look at the running end. The project set out to build that record first and to put everything else on top of it.
- What it made possible
- The question: can a tool list what a web app does from its code, and prove it on the running app?
- What we know
- The repository's first commit, two days ingit history of the repository ·
Now: on dev, shippingplatform and the library
One commit everywhere
One commit everywhere, so a lane's crawl can be added to the map at the same commit as the code map.
- Why
- A map read at one commit and tested at another can claim things neither version does.
- Where it stands
- on dev, shipping: merged in #972, live with the next release
- What we know
- Merged to dev in #972; not in production yetthe release log ·
Now, this weekthe map
A richer first read
The first read of a new app gathers more of what its code says about each route and screen.
- Why
- Names and goals are only as good as what the first read hands them.
- Where it stands
- into next week
Now, this weekflows
Crawls from the homelab land in production
A crawl run on our homelab is admitted into production's map, reviewed first.
- Why
- Flows need the crawl's screens. Until a homelab crawl lands in production, an app's flows stay empty there.
- Where it stands
- crawls run in homelab lanes today; their results are not in production yet
Now, this weekplatform and the library
Fast CI's record week, before anything is skipped
A week of records with no mismatch before fast CI skips a single test.
- Why
- A skipped test that would have failed is worse than a slow one. A week of recorded fingerprints shows whether a stored green can be trusted before one is reused.
- Where it stands
- a week of records with no mismatch, and an alert on a mismatch, before the skipping is switched on
- What we know
- Skipping is built and off by default; it is switched on after a week of record-mode data and once an alert on a mismatch existsthe register, the morning brief ·
I need this featkpr.com/roadmap/timeline#fast-ci-record-week
Next week, 1 in order, not datedplatform and the library
A viewer role in featkpr
People who can look at an app's map and its reviews without changing them.
- Where it stands
- its design pass lands this week
Next week, 2 in order, not datedplatform and the library
Settings that apply live
A changed setting takes effect without a restart.
Next week, 3 in order, not datedplatform and the library
A read-only token
A token that can read an app's map and change nothing.
- Where it stands
- for agents and scripts
Next week, 4 in order, not datedflows
Immich's user guide, written from its map
A guide to an app's flows written from its map, first for Immich.
- Why
- A guide written from the map stays as current as the map.
- Where it stands
- steps with screens, who can do what, where it fails; first on Immich
- What we know
- Raised as an ideaTim ·
- Planned for next week, on Immichthe two-week plan ·
Next week, 5 in order, not datedon top: changes and releases
A pull request summary in plain words
What a change does to an app's features, said in a sentence a person reads at a glance.
- Where it stands
- first on Immich; its design pass lands this week
Next week, 6 in order, not datedplatform and the library
Altineris added through Add an app
Tim adds Altineris himself, through the same steps anyone would use.
- Where it stands
- start to finish, with no step done by us
Next week, 7 in order, not datedthe map
ae ask and an MCP server: agents ask featkpr
Coding agents ask featkpr about an app from the command line or over MCP.
- Why
- A coding agent changing an app should be able to ask what the app does before it changes it.
- Where it stands
- the map, read-only, from the command line or over MCP
- What we know
- Raised as an ideathe design notes ·
- Planned for next weekthe two-week plan ·
Next week, 8 in order, not datedplatform and the library
A token guard
featkpr never sends one code host's token to another.
- Why
- featkpr is about to poll GitHub repositories it doesn't own. A token meant for one code host must never reach another, so this fix comes first.
- Where it stands
- before featkpr polls GitHub repositories it doesn't own
The week after, 9 in order, not datedon top: tests and proof
One recipe for a new app's test lane
One recipe sets up a new app's test lane, instead of one hand-built lane per app.
- Where it stands
- starts next week
The week after, 10 in order, not datedthe map
Goals for Django apps, first on InvenTree
Goals drafted from a Django app's code.
- Where it stands
- starts next week
The week after, 11 in order, not datedon top: tests and proof
InvenTree's test lane, through the recipe
InvenTree reaches its first proof through the one lane recipe.
The week after, 12 in order, not datedplatform and the library
Skills for coding agents
Skills that teach coding agents to ask featkpr before they change an app.
Later, after these two weekson top: changes and releases
The merge-request verdict, posted with the change's own code run
The change's own code run beside the code it replaces, and a verdict on every push.
- Why
- Before merging, a reviewer wants to know which goals a change touches and whether their tests still hold. Running the change's own code beside the code it would replace turns "looks fine" into broke, held or not proven.
- In short
- the pull request's own code ran on BookStack #6213 on 28 Sep (0 broke, 19 held, 5 not proven); next, it posts on every push and fills the Goal sheets page
- What we know
- BookStack #6213: 0 broke, 19 held, 5 not proven; of those, 4 had no runnable test before the change and 1 passes even as the wrong userthe run of the change's own code ·
- An audit of the earlier pipeline: 28 verdicts written, all on requests already merged or closed; none ran a test or named a goalthe verdict audit ·
- A survey of pull-request tools found none that speaks in goals, shows a test proven able to fail, uses runtime effects as evidence and says what it cannot seea survey of vendor docs and public pull requests ·
- Five states with exact rules, and never green when nothing ranthe verdict design pass ·
I need this featkpr.com/roadmap/timeline#merge-request-verdict
Later, after these two weekson top: tests and proof
Effects and OpenTelemetry on BookStack's runs
What each test step changed behind the page: rows, mail, files and outside calls.
- Why
- A page can say "saved" while nothing was saved. Recording what each step changed behind the page lets a test prove the outcome, not only the screen.
- In short
- effects recorded on BookStack's run of 28 Sep at its development tip, not shown here yet; OpenTelemetry measured on one capture run, not on every run yet
- What we know
- BookStack's run at its tip recorded 1,688 activity-log entries, 518 database rows, 232 mails and 100 filesthe run at BookStack's development tip ·
- OpenTelemetry measured on one capture run, with no change to BookStack's codethe build log ·
Later, after these two weekson top: changes and releases
featkpr's verdict gating its own merges
featkpr's verdict on its own pull requests decides whether they merge. Today it is advice only.
- Why
- A verdict that can stop a merge has to be right first. featkpr earns that on its own changes before it asks anyone else to trust it.
- In short
- today the verdict on featkpr's own pull requests is advice only; it gates nothing
- What we know
- The verdict on featkpr's own pull requests is posted and read; it does not block a mergethe register ·
Later, after these two weeksplatform and the library
Fast CI skips tests whose inputs did not change
A test is skipped only when its inputs exactly match a stored pass.
- Why
- Most of a pull request's wait is tests that ran on the same inputs before. Skipping only exact matches, and re-checking a share anyway, cuts the wait without trusting a guess.
- In short
- stage 2: a test is skipped only on an exact match to a stored pass, with some re-checked anyway
- What we know
- Built and off: a skip needs an exact fingerprint match to a stored pass with no red, flaky or diverged run behind itthe register, fast CI stage 2 ·
Later, after these two weeksplatform and the library
The merge train
Pull requests merged in a queue, each tested on top of the ones before it.
- Why
- Two green pull requests can break each other once merged. A train tests each on top of the ones ahead of it, and a release is cut from a commit that was tested whole.
- In short
- stage 3: pull requests merge in a queue, and releases are cut from its green commit
- What we know
- Decided as the third stage of fast CI, after skipping has run safely for a whilethe register ·
Later, after these two weeksdecisions
More relations proven by paired runs
The rest of BookStack's pairs, then relations beyond enables and disables.
- Why
- 27 relations are proven so far. The rest of the map's links stay guesses from the code until their goals have tests that a pair can run.
- In short
- the other 201 BookStack pairs need tests of deleting a book, a page and a chapter first; then kinds beyond enables and disables
- What we know
- 201 of 229 links wait for a test of one of their goals, mostly deleting a book, a page or a chapterthe pair plan at BookStack 1633b3ab ·
Later, after these two weekson top: changes and releases
Where a goal counts as proven: a stage and an environment per product
Each goal says where it was proven: which stage, on which kind of copy.
- Why
- "Proven" alone hides where. A goal that reads "proven · production-like at prod" tells a reviewer what the proof covers, and old verdicts replay under the rule in force when they were made.
- In short
- the flow is live; next, each goal says where it was proven, e.g. 'proven · production-like at prod', never a plain 'proven'; Kargo later
- What we know
- First rules proposed: BookStack at its release, on the published release image; featkpr at prod, on the production-like copythe environments design ·
- Kargo's stages and "freight" borrowed for which commit each stage runsrelease-flow research ·
I need this featkpr.com/roadmap/timeline#proven-per-release-flow
Later, after these two weeksthe map
Goals found in the code
Each goal's inputs, outside calls and the records it changes, read from the code.
- Why
- Goals drafted from screens miss what the code knows: which record changes, what must exist first, what undoes it. Reading that from the code links goals to each other without a model.
- In short
- featkpr finds each goal's inputs and outside calls in the code itself
- What we know
- BookStack's code names 27 entities, 82 relations and 55 audit types; 54 of 164 goals map to a real change of an entitygoal-model research, measured ·
- Hand-checked: the resolver right on 58 of 60, filtered "enables" links 20 of 20, undo pairs 17 of 19goal-model research, one reviewer ·
- Letting a model invent summary goals from the bottom up misses 49–64% of themUCRBench ·
Later, after these two weeksplatform and the library
Keeps working when the code host is down
A queue, a mirror of the code host and an operations page.
- Why
- Verdicts have to arrive when the code host is slow or down. A local mirror and a queue that retries let featkpr keep reading changes and catch up by itself.
- In short
- a queue, a mirror and an operations page
- What we know
- Anonymous traffic to Codeberg stalled BookStack's chain until a token was addedonboarding research ·
- A full clone per request named as a risk of the verdict, with a mirror planned for itthe verdict plan ·
I need this featkpr.com/roadmap/timeline#survives-host-outages
Later, after these two weeksflows
Viewer and guest flows
Flows for every role, not only the admin.
- Why
- What a viewer or a guest can reach is where permission bugs hide. Flows per role show one goal as each person sees it.
- In short
- the crawl signs in as the admin today; other roles once Flows filters by role
- What we know
- A crawl as 8 roles: 144 routes fall into 22 patterns, and the code's permission checks explain 46 of the 47 role splitsthe branching study, measured on BookStack ·
- The crawl signs in as Admin todaythe admin crawl ·
I need this featkpr.com/roadmap/timeline#viewer-and-guest-flows
Later, after these two weekson top: tests and proof
Every state change traced during a run
Every state change traced during a run, and your product's own telemetry taken in.
- Why
- Effects say what a step changed; tracing says how the whole system moved while it did. Slow queries, stuck jobs and silent errors show there.
- In short
- and your product's own telemetry, any stack
- What we know
- Effects already recorded per step: rows, mail, files and calls to other hostsBookStack's run at its tip ·
I need this featkpr.com/roadmap/timeline#whole-system-tracing
Later, before the first teamon top: tests and proof
A wrong user for every test
A seeded user without the permission, for each test that has none today.
- Why
- A test with no wrong user passes whoever runs it, so it proves nothing about permissions. A seeded user without the permission gives every test someone to fail as.
- In short
- a seeded user without the permission for each test that has none today, so no test stays unchecked
- What we know
- 35 of 311 tests at BookStack's tip still have no wrong userthe production store, exported ·
- Content export is held by every seeded role, so no one can fail as that user yetthe environments build ·
I need this featkpr.com/roadmap/timeline#wrong-user-every-test
Later, before the first teamon top: tests and proof
Tests through a browser
The flows a person keeps, run as Playwright tests in a real browser.
- Why
- Tests call the app directly today. Running the kept flows in a browser proves the path a person actually sees, screen by screen.
- In short
- the flows a person keeps, run as Playwright browser tests
- What we know
- Research prototypes already infer an app's features to write browser tests: AutoE2E reports 79% feature coverage on its own benchmarkAlian et al., arXiv 2408.01894 ·
Later, before the first teamthe map
Node and Django readers
Readers for Node and Django apps, starting with Uptime Kuma and Paperless-ngx.
- In short
- Django, Hono, React Router and Next.js readers shipped on 30 Sep and 1 Oct; Uptime Kuma and Paperless-ngx are not read yet
I need this featkpr.com/roadmap/timeline#node-python-readers
Later, before the first teamthe map
How much featkpr misses, measured
How much featkpr misses, measured against a checked list; aiming to find 9 in 10.
- Why
- A map that never says what it misses cannot be trusted. Measuring misses against a list checked by hand turns "we found a lot" into a number with a method.
- In short
- aiming to find at least 9 in 10
- What we know
- Starting again with no help, featkpr missed 605 of 2,372 itemsthe fresh-start audit ·
- The gate set in research: find at least 9 in 10 of a 130-row list checked by handresearch report G1.3 ·
Later, before the first teamon top: tests and proof
Tests written in TypeScript too
Tests written in TypeScript beside the pytest ones.
- In short
- beside pytest
Later, before the first teamdecisions
Owners on features
Each feature with the person who answers for it.
Later, for teamsplatform and the library
Apps registered with each platform, and invites
A GitHub App and a Forgejo integration in place of tokens, with invites and roles.
- In short
- a GitHub App and a Forgejo integration in place of tokens; invites and roles
I need this featkpr.com/roadmap/timeline#platform-apps-invites
Later, for teamsplatform and the library
Teams and tenancy
Several teams on one featkpr, each seeing only its own apps.
Later, for teamsplatform and the library
The reader in your own CI
The reader runs in your own CI, so your code stays with you.
- In short
- your code stays with you
Later, for teamson top: tests and proof
Selenium and Cucumber outputs
Tests written out for Selenium and Cucumber too.
Later, for teamsplatform and the library
The first team on it
The first team using featkpr on its own app.
Later, researched onlyon top: tests and proof
Stand-ins for SSO, LDAP and webhooks
Stand-ins for single sign-on, LDAP and webhooks in the test copy.
Later, researched onlyon top: tests and proof
Fault injection
Faults injected on purpose, to see what breaks and what holds.
Later, researched onlyon top: tests and proof
Reading the flags and errors you already track
Read the feature flags and errors you already track: GrowthBook, PostHog, Sentry.
- In short
- GrowthBook, PostHog, Sentry
Later, researched onlyon top: tests and proof
Load tests with k6
Load tests written with k6 from the same map.
Later, decided 27 Sep, not datedplatform and the library
A private read-only demo
A read-only featkpr for people you invite, behind a one-time code.
- Why
- Seeing featkpr on a real product is the proof. A read-only demo lets invited people look on their own time, once the proof is worth showing.
- In short
- for people you invite, behind a one-time code, once the proof is worth showing; until then, the call is the demo
- What we know
- Demos planned with generated data only, reset when a viewer's session startsthe environments design ·
Later, decided 27 Sep, not datedthe map
Apps made of several services or repositories
Apps made of several services or repositories, linked by the calls between them.
- Why
- A goal already spans services; what breaks is "one repository at one commit". Linking a screen to the API it calls lets a change in one service reach the goals it touches in another.
- In short
- featkpr's own services first, linked by the 31 exact calls its screens make to its API; then Shlink and its separate web client; then a different version per environment
- What we know
- featkpr's screens call its API through 31 exact typed calls, so the links between them are exactthe multi-service study ·
- Shlink's server and its separate web client are a real two-repository case, already read on one sidethe multi-service study ·
Later, decided 27 Sep, not datedflows
Every way into a goal, not just the shortest
A flow for each real way into a goal, not only the shortest.
- Why
- People arrive at a goal from a link in a mail, a signed-out page or a refusal, not only from Home. Each real way in is a path a test should walk.
- In short
- a flow per distinct way in: a deep link signed in or out, a refusal with its message, the page after a save; one goal seen per role, per feature and as a matrix
- What we know
- The shortest path started through a "Recently viewed" list or the hidden profile menu in 72 of 90 cases, which a new user does not havethe branching study, measured on BookStack ·
- 11 ways in that are not links at all, such as a deep link, a signed-out resume or a token in a mailthe branching study ·
Later, decided 27 Sep, not datedon top: tests and proof
Test data from your own exports, masked
Tests run on a masked copy of your own export; pull requests and demos get generated data.
- Why
- Tests on realistic data find what tests on ten sample rows cannot. Masking with a key per product keeps records linked while no real name reaches a test.
- In short
- a real export masked with a key per product, only on trusted nightly runs; pull requests and demos get generated data
- What we know
- Masked data only on trusted nightly runs; code from outside contributors and demos never see itthe environments design ·
- The popular data synthesiser moved to a non-open licence, so generation uses plain statistics with a fixed seedthe environments design ·
Idea, raised by Tim 28 Septhe map
Examples from much larger products: Blender, LibreOffice
The map and one scenario's slice shown on much larger products.
- Why
- featkpr's idea is that each task stays about as small however large the app is. Products the size of Blender or LibreOffice would put that idea to a real test.
- The idea
- the map and a scenario's slice shown on products far bigger than BookStack, and not web apps, to test whether each task stays bounded; nothing read yet
- What we know
- Agents succeed on almost every task that takes a person under 4 minutes, and on under 10% of tasks over about 4 hoursMETR, NeurIPS 2025 ·
- Accuracy per step falls as steps pile up, even when the plan is givenSinha et al., ICLR 2026 ·
Idea, raised by Tim 27 Sepplatform and the library
An open library of every open-source app's features
The features featkpr reads from open-source apps, public, with a free program for the projects.
- Why
- Every open-source app deserves a map of what it does. A public library grows with each app featkpr reads, and gives the projects their map and tests back.
- The idea
- the features featkpr reads from open-source apps, public and growing, and a free program for the projects themselves (a grant or a partnership) to get their map and tests. Long term.
- What we know
- BookStack's 298 features and Shlink's 20 are searchable in the library todaythe library ·
Idea, raised by Tim 27 Sep; part of it runsplatform and the library
A demo environment per feature
A throwaway copy of the app per feature, with a read-only link for clients.
- Why
- A client wants to try the feature, not read about it. A copy per feature, reset for each viewer, shows it working without risk to anything real.
- The idea
- with a read-only link for clients; the throwaway copy it needs runs today
- What we know
- Throwaway copies run today: each run gets its own, labelled, and a cleanup removes leftoversthe environments build ·
I need this featkpr.com/roadmap/timeline#demo-env-per-feature
Idea, raised by Tim 27 Sep; part of it runsdecisions
Several models check every answer
Every model answer checked by other models, not only the goals.
- Why
- One model's answer is a guess; agreement between models is evidence. Checking everywhere a model answers keeps the drafts a person sees honest.
- The idea
- a second model checks every drafted goal, and three cheap models vote on its anchors; the idea is to do it everywhere a model answers
- What we know
- On anchors, a vote of three caught 94% of planted errors with 2 false alarms, where one model alone raised about 40the drafting-model experiment ·
- The weak spot: adding a missing anchor, right 10 times in 33, so the vote may drop but never addthe drafting-model experiment ·
I need this featkpr.com/roadmap/timeline#model-vote-everywhere
Idea, raised by Tim 27 Sepon top: tests and proof
Performance budgets per goal
Page speed and web vitals per goal, once browser flows exist.
- The idea
- page speed and web vitals, once browser flows exist
I need this featkpr.com/roadmap/timeline#performance-budgets
Idea, raised by Tim 27 Sepflows
Process mining on real traces
The flows people really take, mined from real traces.
- Why
- Drafted flows are what the app allows; real traces show what people do. Comparing them finds the paths nobody tests.
- The idea
- the flows people really take, once real traces exist
- What we know
- Kept as one half-day offline experiment, once real traces existthe branching design ·
Idea, raised by Tim 27 Sepflows
A phone crawl lane
The same flows walked at phone width.
- The idea
- the same flows at phone width
Idea, raised by Tim 25 Sepdecisions
A conversation that draws the flow
A conversation beside a canvas that draws the flow you describe.
- The idea
- a conversation beside a canvas that draws what you are talking about
I need this featkpr.com/roadmap/timeline#conversation-canvas
Idea, raised by Tim 22 Septhe map
A product wiki and a flags hub
What the product does, and what is switched on, in one wiki.
- The idea
- what the product does, and what is switched on
Idea, raised by Tim 22 Septhe map
Features from every source
Features read from code, docs, release notes and feedback, not code alone.
- The idea
- code, docs, release notes and feedback, not only code
I need this featkpr.com/roadmap/timeline#features-every-source
Idea, raised by Tim 22 Sep; part of it runsplatform and the library
Findings filed with maintainers
What featkpr finds in an open-source app, sent to its maintainers after a review.
- Why
- Finding a bug in someone's app is only useful if they hear about it. Filing reviewed findings upstream gives the projects something back for being read.
- The idea
- what featkpr finds in an open-source app, sent to its maintainers after a review; one candidate found 28 Sep on the production-like copy (a queued comment mail for a deleted page fails); nothing filed yet
- What we know
- One candidate found: a queued comment mail for a page deleted before it sends fails in BookStack; nothing filed yetthe production-like run ·
I need this featkpr.com/roadmap/timeline#findings-to-maintainers
Idea, raised by Tim 26 Sepdecisions
Quick questions in a corner of the screen
A decision answered in a corner of the screen you are on.
- The idea
- a decision answered where you are, instead of on its own screen
Idea, raised by Tim 27 Sepplatform and the library
A public demo
A public demo; whether it comes before or after the private one is open.
- The idea
- open question: whether a public demo comes before or after the private read-only one
Idea, raised by Tim 22 Sepplatform and the library
Pricing per seat, with a credit limit and top-ups
Per seat, with a credit limit and top-ups; no number is set.
- The idea
- Tim's instinct of 22 Sep; the price needs its own research, and no number is set
Idea, raised by Tim 27 Sepon top: tests and proof
Mail checked in several email clients
Mail checked as it renders in real email clients, not only caught.
- Why
- A sign-up mail that arrives broken in one client is a lost user. Rendering checks show what each client really displays.
- The idea
- today mail is caught and its subject checked; rendering in Gmail and Outlook later, on approval
- What we know
- Today mail of 7 kinds is caught and its subject checked, on every runthe run at BookStack's development tip ·
- A free HTML check comes first; renders in Gmail and Outlook are paid and wait for approvalthe environments design ·
Idea, raised by Tim 27 Sepplatform and the library
Cheaper, steadier model calls across providers
Each model served by several providers: fall back when one is busy, pick the cheapest that is good enough.
- Why
- Model calls fail when one provider is busy. Spreading calls across providers keeps runs steady and cheaper, with a quality floor no call goes below.
- The idea
- each model is served by several providers; fall back when one is busy and pick the cheapest above a quality floor; researched, about 16% off a goal-checking run
- What we know
- Naming providers and setting a price ceiling came to about 16% off a goal-checking runprovider-routing research ·
- Batch mode runs at about half price, and its median batch finishes in 7 minutesprovider docs, read in research ·
Sources: the two-week plan Tim approved on 1 Oct 2026, the register on dev, the design notes of 21 Sep to 1 Oct, the build log, the releases and production's deploy log. Dates ahead are estimates; the board at /roadmap holds the same items by state.
An idea of your own? #
Tell us when you ask for a demo. We read each request and write back; the walkthrough is on BookStack.