BarbagalloDigital

My own project Website: johnbarbagallo.info

A record of work that a stranger can check.

My professional site: the work history, the write-ups of past projects and the résumé behind this business. I designed, wrote, built and host it, and I release it the same careful way every time.

The johnbarbagallo.info homepage, headline "I build web systems that hold up."
My own project johnbarbagallo.info, captured from the live site. Not client work.

One release, start to finish

The same seven steps every time, with the numbers from the latest release record.

  1. Tagrc13

    Built from a tagged commit, so the code behind the live site is always known.

  2. Test547

    Browser tests at desktop and phone sizes, none failing on the release run.

  3. Record92

    Files in the release, each fingerprinted, so any change to one shows up.

  4. Stage92/92

    Files uploaded beside the live site and checked there, before visitors see any change.

  5. Switch1 step

    The new version goes live in one move. The old one stays beside it, ready to restore.

  6. Verify180/180

    Checks of the live site after the switch, at desktop and phone sizes.

  7. Close0

    Ways in left open: the temporary server access is removed, then confirmed refused.

At a glance

Built with
Astro and TypeScript, as a static site with no database to break
Tested with
Playwright browser tests at desktop and phone sizes, with axe accessibility checks against WCAG 2.2 AA
Hosted on
A server I run, with security headers set at the web server
Released
Seven recorded production releases, each with a written deployment record

How it was built

The problem it solves

Anyone can say they've done the work. The site is built so a reader can check. Each case study marks its evidence as verified, pending or withheld.

How a release goes out

Each of the seven recorded releases followed the same written procedure, and each one left a record behind it.

  • The release is built from a tagged commit, so the exact code behind the live site is always known.
  • A checksum of every file is recorded, then checked on the server before the switch and again after it.
  • The new version goes in beside the live one, and the switch is two renames. The old version stays beside it, so a rollback is two renames back.
  • Server access for a release is a temporary key, limited to one address, removed afterwards and confirmed refused.

Checking the live site without tripping its own defences

During one early release, my verification run asked the server for protected files, and soon after, the server's intrusion protection blocked my address for ten minutes. Those requests were the likely trigger.

The verifier was rebuilt after that. It makes one request at a time, spaced out, never asks for protected or hidden files, and stops after three failures in a row instead of retrying.

One release, in numbers

From the release record of RC13, deployed on 12 November 2026:

  • 547 browser tests passed at desktop and phone sizes on the release run, with none failing.
  • 92 of 92 files matched their checksums on the server, before the switch and after it.
  • 91 of 91 public files matched their checksums on the live site, in 92 requests.
  • 180 of 180 checks passed in the live browser check after the switch, and 159 of 159 touch checks at three phone widths.

Details that take care

A before-and-after comparison slider that works by keyboard and touch, with a fallback when scripts are off. A career timeline that shows a gap instead of hiding it. A contact bar on phones that steps aside for the menu and the footer.

What this doesn't show

The limits, stated plainly, so you can weigh the evidence.

  • It’s a personal site. It has no customer accounts, no shop and no forms that store data, so it shows release discipline, not a complex application.
  • Traffic and enquiries aren’t published here.
  • Some of its write-ups wait on a former employer’s permission, and say so on the page.

What it shows about how I work

This is my own project, not client work. Here's what it says about my habits.

  • On my own sites, the previous version stays ready to restore when I release a change.
  • I write down what was tested and what passed, so the record outlasts my memory of it.
  • I check accessibility while building, not afterwards.

Want your site built, or looked after?

Start with the free check: one page on what your customers see, written by me.

Free, one page, no login.

Get a free website check