Pipeline timings, query plans, operational imports, and the shape of a clinical data platform.
●Recorded pipeline timings
Pipeline refresh
11–16 min → <20 sec
A shorter pipeline cycle on the same server.
Inspect the evidence 2 measurements+
Pipeline cycle cut from 11–16 minutes to under 20 seconds
Over several rounds of measured fixes, the pipeline cycle went from 11 to 16 minutes down to under 20 seconds.
Context
A drayage logistics operator, dispatch and billing pipeline that had to finish inside a working shift.
Measured
11 to 16 minutes
Method
Timed end to end on the production pipeline before the change
Scope
One full refresh cycle of a pipeline that runs every minute, dispatch and billing data
Measured
6.8 to 17.3 seconds (under 20 s)
Method
Project audit of the rebuilt cycle, two orders of magnitude tighter
Scope
One full refresh cycle on the same sources, after the last round of fixes
●EXPLAIN ANALYZE
Container lookup
31.4 → 1.19–1.59 ms
Container search, measured with query plans.
Inspect the evidence 2 measurements+
Keystroke search answered in about a millisecond
Indexed lookups on a table searched on nearly every keystroke return in about a millisecond.
Context
A drayage logistics operator, operations console with a container lookup that is searched on nearly every keystroke.
Measured
31.4 ms
Method
EXPLAIN (ANALYZE, BUFFERS) with index and bitmap scans turned off, so Postgres read the whole table: pattern ILIKE '%7152%', LIMIT 20
Scope
The whole container lookup table
Measured
1.19 / 1.52 / 1.59 ms
Method
Same query shape against the trigram index across three consecutive runs
Scope
The whole container lookup table
●Austin’s account of the engagement
Call-list import
7 days → <5 min
Call lists loaded without seven days of hand-keying.
Inspect the evidence 2 measurements+
Call list loading cut from seven days to under five minutes
Cut loading an outbound call list from seven days of hand-keying to under five minutes, and completed calls rose from about 300 to nearly 3,500.
Context
A healthcare services company made outbound customer-satisfaction calls for its clients. Each client sent a list of about 5,000 calls, and six people keyed every record into the triage information system by hand before the calling could start.
Measured
7 days to under 5 minutes
Method
Recalled from the work in 2007 to 2010 and written down on the date shown: six people keying one list by hand, against an import loading the file the client sent
Scope
One outbound customer-satisfaction list of about 5,000 calls
Measured
about 300 to nearly 3,500 calls completed
Method
Recalled, as above: completed calls out of the roughly 5,000 listed, before and after the six people who had keyed the list moved to calling full time; one of them became the outbound manager
Scope
The same list size, with the same six people
●Delivered repository & load tests
Clinical data quality
6 APIs. One data picture.
Field verification and facility metrics, without patient details on the dashboard.
Inspect the evidence 7 measurements+
A clinical analytics dashboard built from scratch over HL7
Built a clinical analytics dashboard from scratch that shows, for any facility, whether each field arrives where reporting and billing expect it, and turns HL7 messages into facility metrics from daily to yearly without putting a patient's details on screen.
Context
A national physician services company. Oracle fed InterSystems IRIS, which held the HL7 messages from its facilities; the dashboard copied them into SQL Server, parsed them and measured the facilities from them.
Measured
79 commits from 12 February to 24 March 2026
Method
The delivered repository's commit history
Scope
The version of the repository delivered in February and March 2026, one developer; the work itself ran across the whole engagement
Measured
6 .NET 10 APIs on a shared framework, a Vue 3 dashboard, and a Next.js rewrite under way
Method
Read from the solution, project and package files
Scope
The delivered repository
Measured
Every tracked field shown per facility with that facility's three most recent values, marked verified or needs review separately for HL7 and flat-file feeds, with the reviewer recorded; each field tagged billing, analytical or other
Method
Read from the field verification screen, its API and the metric column tables
Scope
The facility field verification feature
Measured
Daily metrics per facility: completeness of billing, analytical and other fields, HL7 against flat-file completion, verified and unverified field counts, and the verification rate
Method
Read from the daily metrics aggregation job
Scope
The analytics service
Measured
HL7 copied from IRIS into SQL Server in batches of 25,000 rows; metrics rolled up daily, weekly, monthly, quarterly and yearly
Method
Read from the archive job and the metric aggregation jobs
Scope
The archive and analytics services
Measured
Load-tested with 6 million generated records, 100,000 per facility across 60 facilities
Method
Read from the test data generator in the analytics job service
Scope
The analytics service
Measured
About 2 billion records across years of data
Method
Austin's account of the production data. The code does not record it, and it was not reproduced: the local load test used 6 million generated records
Scope
The production data the dashboard was built to measure
02 / 4 claims
Software people can keep changing.
Test repairs, code structure, and maintainability. Each result keeps its own repository and measurement scope.
●Test suites & merged changes
A useful test suite
0 of 103 → 111
Browser tests repaired, plus 458 unit and integration tests added.
Inspect the evidence 3 measurements+
A never-passing browser suite repaired to 111 passing tests
A browser suite that had never passed (0 of 103) was repaired to 111 passing tests, and a unit and integration layer that did not exist was added: 458 tests. 569 tests in all, 530 of them added.
Context
An industrial manufacturer's web application, where the existing browser tests had never passed and there were no unit or integration tests.
Measured
0 of 103 to 111 browser tests passing
Method
Playwright run at the start of the engagement, and counted again with all four pull requests merged
Scope
The client's browser (end-to-end) suite
Measured
0 to 458 unit and integration tests
Method
Counted with all four pull requests merged: 207 client tests on Vitest and 251 server tests on Jest, where none existed before. 129 of them are unit tests behind job, part and subtask validation, which a browser suite would need a test per route to cover
Scope
The new unit and integration layer
Measured
569 total, 530 added
Method
Counted with all four pull requests merged: 111 browser, 207 client, 251 server
Scope
Every test in the application, both layers
●Repository analysis
Repository code health
7.91 → 9.53
Code health, measured with the same tool and settings.
Inspect the evidence 2 measurements+
Repo code health raised from 7.91 to 9.53
Repo code health moved from 7.91 to 9.53, the hotspot score from 5.35 to 9.29, and the worst file from 1.0 to 6.05.
Context
A multi-language codebase: a Python dispatch engine plus its TypeScript web clients.
Measured
7.91 / 5.35 / worst 1.0
Method
Baseline recorded by the code-health tool on the August state of the repository
Scope
Whole repository, tool defaults
Measured
9.53 / 9.29 / worst 6.05
Method
Re-run of the same tool, sync at HEAD, no Python file left in the bottom twenty
Scope
Whole repository, same tool defaults
●Repository diff & type checks
Dispatch engine structure
36 → 0 type errors
A dispatch engine restructured into focused modules.
Inspect the evidence 2 measurements+
Dispatch engine type errors cut from 36 to 0
One restructure took a dispatch engine from 22 to 60 modules and its type errors from 36 to 0.
Context
A Python dispatch engine carrying accumulated defects, restructured in a single commit.
Measured
22 to 60 modules, 36 to 0 type errors
Method
git show --stat and git ls-tree on the commit before and after
Scope
180 files changed, +14,615 and -9,896 lines, one commit
Measured
+14,615 / -9,896 lines
Method
Same commit's diffstat
Scope
180 files in one commit
●Static source count, not a test run
An unshipped build
880 test attributes
A carefully built prospect project that never shipped.
Inspect the evidence 3 measurements+
880 xUnit test attributes in a build that never shipped
A greenfield .NET solution whose end client never signed the contract, so it never shipped, still carries 880 xUnit test attributes: 803 [Fact] and 77 [Theory]. Nobody asked for them.
Context
A .NET solution built alone from an empty repository for a prospect who never signed. It never went to production and earned nothing. There was no deadline, no acceptance test, no customer and no auditor to require a test suite.
Measured
1 author, 42 commits
Method
git shortlog -sn --all on the repository: every commit is Austin's. The history starts with his own commits on 2026-08-17, repository hygiene and then the solution skeleton and build configuration, so the tree was started from nothing
Scope
The whole history of the repository
Measured
880 test attributes: 803 [Fact], 77 [Theory]
Method
A static count of [Fact] and [Theory] attributes in the C# files, leaving out build output, across 3 test projects: unit, integration and analyzer tests. A [Theory] runs once for each of its data rows, so 880 is the least number of test cases that run, not the total
Scope
Every C# file in the repository
Measured
9.56 of 10; maintainability 9.58, performance 9.99
Method
repowise 0.54.0 health with its defaults, run in-process with no AI model and no network. Its score starts at 10 and subtracts points: 0.32 for the shape of the code and 0.12 for its change history, which leaves 9.56. Those two are deductions, not scores out of 10
Scope
872 files, the whole repository
03 / 3 claims
From code to something useful.
Products, payment infrastructure, and the release process around them.
●Git history & deployment runs
First commit to production
12.5 hours
First commit to first production deploy. The product was still in evaluation.
Inspect the evidence 6 measurements+
A new SaaS in production 12.5 hours after its first commit
Pawsitively, Aternex's first product, reached its first production deploy 12.5 hours after its first commit; over its first four days it merged 158 pull requests, none with a failing check, and its six production projects are held to 100% line and branch coverage.
Context
Pawsitively, multi-tenant software for dog daycare, boarding and training businesses that Aternex designed, built and runs without a client brief, with AI assistance. A .NET 10 and Blazor application on PostgreSQL 18, released by GitHub Actions to a self-hosted machine.
Measured
12 h 33 min
Method
git log: first commit 2026-10-17 09:13 UTC; gh run list for the deploy workflow: first run, successful, started 2026-10-17 21:45 UTC
Scope
From the first commit in the repository to the first successful production deploy
Measured
240 commits and 158 merged pull requests
Method
git rev-list --count on main and gh pr list --state merged; 88, 60, 55 and 37 commits on 17, 18, 19 and 20 October (New York time); 210 of the 240 commits are co-authored with Claude
Scope
The whole history, which begins on 2026-10-17 with no earlier work
Measured
0 merged pull requests with a failing check; 158 of 159 deploys succeeded, 63 s at the median
Method
gh pr list --state merged with each pull request's check results; gh run list for the deploy workflow, run start to finish
Scope
Every merged pull request and every deploy to 2026-10-21 01:09 UTC; main now requires eight checks, added over the first day
Measured
3,186 test methods; 100% line and branch coverage
Method
2,743 [Fact] and 443 [Theory] attributes across 753 test files; scripts/coverage.py fails any of the six production assemblies below 100% line and branch coverage, on every pull request
Scope
The six production projects: Domain, Application, Contracts, Infrastructure, Server and Web; browser-only start-up code and generated code are excluded
Measured
48,179 lines of tests for 33,332 lines of production code
Method
Raw line counts of the C# and Razor files under tests/ and src/, blank lines included
Scope
The whole repository at commit c04602f1
Measured
98 / 100 / 100 / 100 on mobile; 100 in every category on desktop
Method
Lighthouse 12.6.1 with simulated throttling, three runs each, in the Lighthouse workflow against the production build: performance, accessibility, best practices and SEO; largest paint 2.4 s on mobile and 0.54 s on desktop, blocking time 0 ms, layout shift 0
Scope
The public home page, first view
●Austin’s account of the role
A gateway becomes a business
Gateway → own business
Built from scratch at Ministry Brands; became Payment Brands.
Inspect the evidence 4 measurements+
A payment gateway built from scratch as employee seven
Built a payment gateway from scratch as employee number seven, and it grew into its own business.
Context
At Ministry Brands, 2014 to 2018. The gateway processed the company's card traffic and was later spun out as a separate company, Payment Brands.
Measured
Built from scratch
Method
Role history as confirmed by the subject, including the spin-out
Scope
Own role and the company's own record
Measured
$15B+ a year across 90+ brands
Method
Austin's recollection of his time at Ministry Brands, and videos he made then that are no longer available. No public source confirms it
Scope
The gateway's yearly processing volume and the number of brands on it
Measured
From 14 to 800 developers, through 90+ acquisitions
Method
Austin's recollection of his time at Ministry Brands, and videos he made then that are no longer available. No public source confirms it
Scope
The company's developer headcount and acquisitions while Austin was there
Measured
Employee number seven
Method
Austin's recollection of his time at Ministry Brands, and videos he made then that are no longer available. No public source confirms it
Scope
Austin's own start at Ministry Brands
●Austin’s account of the role
The release process
60% less deployment time
An earlier role’s release-process improvement.
Inspect the evidence 1 measurement+
Deployment time cut by 60%, deployment errors to zero
Cut deployment time by 60% and deployment errors to zero.
Context
InhabitIQ, 2021 to 2022: property management software whose CI/CD pipelines were tuned to run the unit tests in every build.
Measured
-60% deployment time, deployment errors to zero
Method
Recorded at the time from pipeline durations and failed deployments before and after the rework; not re-measured since. The exact day was not kept, so the date shown is the end of 2022, the last year of the role
Scope
The standard release pipeline
04 / 3 claims
Earlier Aternex builds.
Historical measurements of the previous website and its commerce demo. These are not performance scores for this Astro site.
●Historical GitHub Actions runs
Previous site: releases
80 sec median release
Previous website, measured in October 2026.
Inspect the evidence 3 measurements+
Site checks in about five minutes, releases in 80 seconds
Measured in early October 2026, every change to this site passed its checks in about five minutes, browser tests included, and a release took a median of 80 seconds.
Context
Aternex's own website: a Next.js static export served from Azure Storage behind Azure Front Door, with a contact API on Azure Functions, all defined in Terraform and released by GitHub Actions on self-hosted runners.
Measured
297 s median for the pull request checks, 150 to 692 s across 17 runs
Method
GitHub Actions run durations of the CI workflow, which runs formatting, types, lint, unit tests with coverage, the export build and the browser tests; browser tests re-run only for the pages and code a change touched
Scope
The 17 successful CI runs on 2026-10-03 after browser tests began running once per change
Measured
80 s median for a release; 64 to 124 s for nine of 12, and 263 to 280 s for the other three
Method
GitHub Actions run durations of the deploy workflow
Scope
The 12 successful releases on 2026-10-03 after browser tests began running once per change
Measured
2,372 unit tests at 100% line, branch and function coverage; 0 copied blocks of 50 or more tokens
Method
Vitest coverage thresholds and jscpd run before every push and on every pull request
Scope
The whole repository
●Historical Lighthouse runs
Previous site: mobile performance
100 / 100 / 100 / 100
Previous website’s mobile Lighthouse scores on 2 October 2026.
Inspect the evidence 2 measurements+
Mobile Lighthouse: 100 on 2 Oct 2026
The home page measured on 2 October 2026 scored 100 in every Lighthouse category on mobile, and its reload was answered by the site's own service worker without waiting on the network.
Context
Aternex's own website: a Next.js static export served from Azure Storage behind Azure Front Door, with a contact API on Azure Functions, all defined in Terraform and released by GitHub Actions on self-hosted runners.
Measured
100 for performance, accessibility, best practices and SEO; largest paint 1.4 s, blocking time 30 ms, layout shift 0
Method
Three Lighthouse 13.5 runs against www.aternex.com with its simulated mobile device and network
Scope
The home page published on 2 October 2026, before the visual profile redesign and Lineicons CDN integration
Measured
21 requests and 235 KB on the wire for a first visit; 0 KB before the page shows on a reload, with DOMContentLoaded at 11 ms
Method
Encoded bytes from the Chrome DevTools Protocol and the navigation timing entry, in headless Chromium at 1350 px wide
Scope
The home page, first visit with an empty cache, then three reloads with the service worker in control
●Historical browser & build tests
Commerce demo architecture
Postgres in the browser
The previous site’s furnishings demo, with startup, transfer, and storage measurements.
Inspect the evidence 10 measurements+
A furnishings business on Postgres inside the browser
A complete furnishings business runs on Postgres inside the visitor's browser: in a mid-range phone profile it is ready to query in under two seconds once the engine is downloaded, and it keeps nothing on the device until the visitor signs in or changes something.
Context
Ochre Nocturne, the flagship demo Aternex built end to end: a home furnishings retailer with a storefront, a designer trade programme, a back office, delivery and reporting on one set of data. It is a Next.js static export; the database is PGlite (Postgres compiled to WebAssembly) in a Web Worker, kept in IndexedDB, and the site is served from Azure Storage behind Azure Front Door.
Measured
1.89 to 1.91 s
Method
e2e/flagshipEngine.spec.ts in Playwright's Pixel 7 profile with the CPU slowed four times through the DevTools protocol, against the production build on a local edge; three runs on an idle machine, alternated with the build measured that morning (1.75 to 1.76 s)
Scope
Start-up: from the start of the engine check to a seeded database ready to query, once the engine is downloaded
Measured
3.8 MB
Method
curl against www.aternex.com with Chrome's Accept-Encoding: 3,829,407 bytes of brotli for the three engine files (16,778,719 bytes uncompressed)
Scope
The database engine, downloaded only on the first sign-in, add to bag or back-office visit; browsing downloads none of it
Measured
99 to 100
Method
Lighthouse 13.5, mobile, simulated throttling, three runs per page against www.aternex.com: performance 99 to 100, accessibility 100, best practices 100; largest paint 1.5 to 1.6 s, blocking time 40 to 80 ms, layout shift 0
Scope
The story page (275 KB in 21 requests) and the store home (419 to 424 KB), first view
Measured
0.58 MB, then 5.08 MB
Method
e2e/flagshipMeasure.spec.ts (E2E_MEASURE=1) against www.aternex.com in the Pixel 7 profile with the CPU slowed four times; response bodies and headers as Playwright reports them, the database worker included; three runs. The first view is larger than Lighthouse's because the Pixel 7 screen is denser (2.625 against 1.75 pixels per point), so the browser picks larger product photographs: 253 KB of images against 99 KB
Scope
Bytes on the wire: the store's first view, then after signing in opens the database
Measured
0.8 s, 1.2 to 1.7 s, 0.5 s
Method
e2e/flagshipMeasure.spec.ts against www.aternex.com, Pixel 7 profile, CPU slowed four times, three runs: search 0.76 to 0.85 s, placing an order 1.21 to 1.72 s, opening the dashboard 0.44 to 0.49 s, signing in including the engine download and start-up 3.78 to 3.80 s
Scope
From the action to the result on screen: search (answered from the page, without the database), checkout and the dashboard
Measured
8.4 MB, all of it freed
Method
navigator.storage.estimate() in e2e/flagshipMeasure.spec.ts before and after signing in, the first change the demo keeps, then the Remove demo data control, which reported 8.4 MB freed; IndexedDB and every flagship key were gone afterwards
Scope
On-device storage: 748 bytes before signing in or changing anything (the site's service worker), 8.38 MB after it; what remains after removal is the main site's own page cache
Measured
2,372 tests in 27.3 s
Method
vitest run on one 16-core machine, 27.2 to 27.4 s over three runs (593 of the tests cover the flagship); Playwright lists 1,322 browser tests across a desktop and a phone profile, each re-run only when its pages or code change
Scope
Unit, database and component tests for the whole site, and the browser tests behind them
Measured
5 minutes, then 80 s
Method
GitHub Actions run times for the 17 successful CI runs and 12 releases on 2026-10-03 after browser tests began running once per change: CI median 297 s (150 to 692 s), release median 80 s (64 to 280 s), on self-hosted runners
Scope
From a pushed change to every check passing, and from a merge to the site being live
Measured
$27.52
Method
The costs each image run recorded: $17.22 for the first full set, $1.01 of trials and logos, $9.02 to regenerate 133 colourways from each product's first photograph, and $0.27 for that trial
Scope
All product photography, inside a thirty dollar budget
Measured
$0.75 in 7.7 minutes
Method
The copy pipeline's own run log: three drafting model families and two revisers wrote copy for 115 products for $0.72, after a five-product trial for $0.03. Every answer was validated for structure, length and banned words; a separate model and a keyword scan then checked each product's copy against its facts, and eleven products with invented details were rewritten by hand
Scope
Product copy for the whole catalogue
A conversation is a good place to start
What would progress look like for you?
Let’s define a useful outcome and how we’ll know the work made a difference.