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 85 days, from 6 July 2026. Computed on 28 September 2026, when the site was built.

Deployment frequency13.5per week163 deployments: 105 code changes and 58 content rebuilds.
Lead time for changes1 minMedian from commit to live. 90% within 4 min, 113 commits.
Change failure rate0%0 of 163 deployments needed a restore.
Time to restore–No 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.

2550756 Jul3 Aug31 Aug28 Sept

Hover a week for its numbers.

Latest deployments

WhenWhatKindLead time
28 Sept928a4f0 fix(var-leverans): build stamp shows the date only, no timeCode2 min
28 Septbb4964b feat(seo): Person schema on /konsulter, sameAs links, post authors as the same PersonRebuild–
28 Septbb4964b feat(seo): Person schema on /konsulter, sameAs links, post authors as the same PersonCode2 min
28 Septcd41025 fix(footer): deploy stamp shows the date only, no timeCode2 min
28 Sept94e1f1f fix(matomo): track from the consent click, one page view per pageCode2 min
28 Septc0e5744 feat(head): touch icon, web manifest, RSS discovery link and security.txtCode2 min
26 Sept7052596 docs(changelog): four new glossary terms and the Drönarfoto link in the Mux postCode–
26 Sept7052596 docs(changelog): four new glossary terms and the Drönarfoto link in the Mux postCode3 min
26 Septf286f81 docs(changelog): the policies are publishedRebuild–
26 Septf286f81 docs(changelog): the policies are publishedCode3 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.