Paperphyte/Our delivery

Our delivery.

We help clients measure their software delivery. Here are our own numbers for this site — the four DORA metrics, computed from the repository and the hosting every time the site is built. Nothing hand-written.

Last 88 days, from 15 June 2026. Computed 10 Sept, 17:11 when the site was built.

Deployment frequency10.6per week133 deployments: 83 code changes and 50 content rebuilds.
Lead time for changes1 minMedian from commit to live. 90% within 4 min, 90 commits.
Change failure rate0%0 of 133 deployments needed a restore.
Time to restoreNo failed changes in the window, so nothing to measure.

Deployments per week

Code changes are pushes to main. Rebuilds are when Sanity publishes content and triggers a new build of the same code.

25507515 Jun13 Jul10 Aug7 Sept

Hover a week for its numbers.

Latest deployments

WhenWhatKindLead time
10 Sept, 17:06114b50c feat(leverans): the site's own DORA metrics at /var-leveransCode2 min
10 Sept, 16:23b0172af feat(startsidan): mini wait-time calculator in the tools sectionCode1 min
10 Sept, 16:08fd03bc3 feat(sok): client-side search over posts, glossary and toolsCode1 min
10 Sept, 15:479e3c247 feat(ordlista): glossary links on service and assignment pagesCode1 min
9 Sept, 15:20e8d0263 docs: Backstage post and utvecklarportal term in the changelog and TODOCode2 min
9 Sept, 15:1971e495a docs: build-once blog post in the changelog (#15)Rebuild
9 Sept, 15:1871e495a docs: build-once blog post in the changelog (#15)Rebuild
9 Sept, 15:1671e495a docs: build-once blog post in the changelog (#15)Rebuild
9 Sept, 15:1571e495a docs: build-once blog post in the changelog (#15)Rebuild
9 Sept, 14:5071e495a docs: build-once blog post in the changelog (#15)Code4 min

How we count

Deployment
Every time a new version of the site goes live in production on Vercel — recorded as a successful deployment status in GitHub. A push to main gives one; a publish in Sanity gives a rebuild of the same code.
Lead time
From when a commit was written (author date) until the first deployment containing it went live. For squash-merged pull requests, from the branch's first commit.
Failed change
A build that failed in production, or a deployment whose commit was later reverted on main.
Time to restore
From the failed deployment to the next one that went live.

The source is GitHub's deployment and commit APIs for the repository, read when the site is built; nothing is fetched in your browser. The window is thirteen Swedish calendar weeks. The site has no monitoring that could catch a failure in production after the fact, so a failure nobody reverted is not counted — that is the honest limitation.

Why we publish this

We help clients measure and improve exactly these four numbers — the DORA metrics — so it would be odd not to publish our own. This site is a small, single-developer project with a static build; the figures are not a benchmark for a product team, but the mechanism is the same one we set up for clients: measure from what actually happened, publish the numbers, let the trend drive the work.

Want the same for your own delivery? That is what Delivery Engineering is about. The wait-time calculator puts a price on the minutes between commit and verdict.

Say hello

Got a problem worth solving?

Chat with us on WhatsApp. We reply within 48 hours.