How it ships

What it is

The Software Development Survey is a scored assessment across ten named dimensions, from how work enters the backlog to how a release is watched once it is live. Every finding names its evidence: a command, a file, a document history, or an interview, so nothing hides behind an opinion, and every command is written down so a skeptical engineer can re-run it. It ends with a written verdict and a ranked list of what to fix first, ordered by risk against cost to fix.

What you receive

• 01

  Where work starts

  We read your backlog and interview the people who fill it: which items are committed work, which are ideas, and how anyone would tell the difference from the list alone. Then we take the last few things your team actually shipped and check whether a written plan preceded the first line of code, and who owned it.

• 02

  How it gets built

  We read the commit history directly: who pushes straight to the default branch, whether a change requires a review from someone who did not write it, and whether that requirement is enforced by the platform or only observed as a habit. A rule that exists but does not fire on its own is a different finding from one that does.

• 03

  What proves it works

  We check whether automated tests exist, whether they run on every change, and whether a red run actually blocks a release or only gets noticed after the fact. The evidence here is a command, run once, read-only, against the existing suite.

• 04

  How it reaches customers

  We read the deploy path: whether staging exists for every tier that changes, whether a rollback is a rehearsed command or a memory, and whether a health check runs after a restart. Then we ask about the last time something broke in production: who found out first, and how long after it broke.

• 05

  Who is on the hook

  We check whether decisions are written down as they are made or only live in chat and in heads, and whether the host configuration actually matches what the repository says it should be. The last row is safety: named accounts, secrets kept out of the repository, and a guard layer between any AI agent and the machine, with a ledger.

The Survey ends with a scored assessment, a ranked gap register, a prioritized fix list, and a written verdict closing with the commands a skeptical engineer can re-run to check each finding.

What it needs from you

• Read-only access to your repository, deployment path, and hosting environment
• Forty-five minutes with the engineering lead, for the interview rows
• Where a multi-tenant boundary exists, a named scope and test credentials for a hands-on check
• Time on the calendar for the work to run, agreed before it starts

How it ends

The Software Development Survey ends with a written verdict, not a slide deck. You receive a ranked list of what to fix first, ordered by risk against cost to fix, and the commands behind every finding so your own engineers can re-run them. A Blueprint proposal follows only where the findings warrant one.