How it ships

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 whether anyone could tell the difference from the list alone. Then we take the last few things your team shipped and check whether a written plan came before the first line of code, and who owned it.

• 02

  How it gets built

  We read the commit history: who pushes straight to the default branch, whether a change needs a review from someone who did not write it and whether the platform enforces that or people follow it out of habit. A rule that 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 failing run blocks a release or only gets noticed afterward. The evidence is a command, run once and read-only, against your existing test 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.

• 05

  Who is on the hook

  We check whether decisions are written down as they are made or live only in chat and in people's heads, and whether the host configuration 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 with a ledger between any AI agent and the machine.

The Survey ends with a scored assessment, a ranked gap register, a prioritized fix list and a written verdict that closes 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, a ranked list of what to fix first and the commands behind every finding, so your engineers can re-run them. We propose a Blueprint only where the findings warrant one.