Software audit checklist
How to assess a struggling software project: a software audit checklist
Your project is late, over budget or breaking with every release, and you need to know why before you decide what to do. These are the areas to review, and what to look for in each.
Updated
Written by Jesse Sanders, CEO & Enterprise PrincipalReviewed by Kevin Schuchard, Director of Engineering
What a software audit should answer
To assess a struggling software project, review six areas, not only the code: code and architecture, tests, the release pipeline, security and access, process, and ownership. Then talk to the people who build and use the system, and sort what you find into what blocks the team today, what puts the business at risk, and what only slows things down.
An audit is worth doing only if it answers three questions: what is wrong, what to fix first, and what the fix will cost. A list of a hundred problems with no order does not help you decide.
Review every area below, not only the code. Many struggling projects are stuck because of the release process, the tests or unclear ownership, not because the code is beyond repair. Not sure the project needs this yet? Start with the signs a software project needs a rescue.
The checklist
1. Code and architecture
Where the system is fragile, and what blocks the next feature.
- Which parts of the code break most often, and which ones nobody wants to touch
- Whether the framework and libraries are on supported versions, with a known upgrade path
- How tightly the parts depend on each other: can one change ship without changing five others?
- Duplicated logic, dead code and business rules that live only in the code
2. Tests
Whether a change can be made safely, or only carefully.
- Whether automated tests exist, run on every change and pass reliably
- Whether the business-critical paths are covered, not only the easy ones
- How often a release breaks something the tests did not catch
3. Release pipeline (CI/CD)
How code gets from a laptop to production, and where it breaks.
- Every manual step between a merged change and production
- Whether test, staging and production environments match
- How a bad release is rolled back, and how long that takes
- Whether database changes are versioned and applied by the pipeline
4. Security and access
Gaps that put data at risk, and access that should not exist.
- Passwords, keys and tokens stored in the code or in shared documents
- Dependencies with known vulnerabilities
- Former vendors, contractors or employees who still have access
- Who can deploy to production, and whether that is logged
5. Process and backlog
Why estimates miss and work stalls.
- How work is written: does each story say what done means?
- Estimates against what actually happened over the last few months
- How priorities are set, and how often they change mid-sprint
6. Ownership and knowledge
Whether you could keep going if one person or one vendor left.
- Who owns the code repositories, cloud accounts, domains and app store accounts
- Whether the system is documented well enough for a new engineer to run it
- Knowledge that only one developer or one vendor holds
7. Pain points from the people involved
The problems the team and the users feel most.
- Interviews with the engineers who build it and the people who use it
- The ten problems they would fix first, in their own words
- Where those problems match what the review above found, and where they do not
How to run the assessment in five days
For a single product, this plan fits in a week if access is ready on day one. A larger system takes longer, but the order is the same.
- Day 1
Access and inventory
Get read access to the repositories, the backlog, the pipeline and the cloud accounts. List every system, service, framework and version, and every account the product depends on, with its owner.
- Day 2
Code, architecture and tests
Read the parts that change most often and break most often. Run the test suite and note what it covers, how long it takes and how often it fails for reasons unrelated to the change.
- Day 3
Release pipeline and security
Follow one change from merge to production and write down every manual step. Scan dependencies for known vulnerabilities, search the code for secrets, and compare the access list with the people who still work on the project.
- Day 4
Process and interviews
Compare the last few months of estimates with what shipped. Interview the engineers and a few users, and ask each for the three problems they would fix first.
- Day 5
Triage and write-up
Rate each area, group the findings into blockers, risks and slowdowns, and put them in order. Write the result as a short report with an order of work, not a list of everything you found.
Rate each area
Give every area on the checklist one rating, with one sentence of evidence. A rating without evidence is an opinion; evidence without a rating is hard to act on.
- Red
- Blocks delivery or puts data or the business at risk now. Fix before new features.
- Amber
- Slows the team or adds risk over time. Plan a fix in the next few months.
- Green
- Works well enough. Leave it alone unless a later fix depends on it.
What to collect first
Most delays in an assessment come from waiting for access. Ask for these before the first day.
- Read access to every code repository, including old branches
- The backlog and the last three to six months of finished work
- Pipeline configuration and the history of recent deployments
- The list of incidents, rollbacks and hotfixes since the last major release
- The list of people and vendors with access to code, cloud and production
- Contracts, statements of work and any architecture documents
Mistakes to avoid when you assess your own project
- Reviewing only the code. The release process, the tests and ownership are where many projects are really stuck.
- Asking only the people who built it. They know the system best, and they are also the closest to it. Talk to the people who use it too.
- Listing everything with no order. A long list of problems with no priority does not tell anyone what to do on Monday.
- Judging from one bad week. Look at the last three to six months of releases, incidents and estimates, not only the latest one.
- Skipping the access review. Former staff and vendors with live credentials are a risk you can remove in a day.
What to do with the results
Sort what you found into three groups: what stops the team today, what puts data or the business at risk, and what only slows things down. Fix the first two groups first. Release problems and missing tests usually come before new features, because every later fix depends on them.
Then decide whether to fix the system you have or replace part of it. How to decide between rescue and rebuild covers the signs for each. If the people who built the system are gone, secure the accounts first: how a project takeover works.
Want an independent audit instead?
Briebug's Technical Assessment reviews every area on this list: the code and architecture, the stories and agile process, CI/CD, security and your top 10 pain points. It takes about 1 week for a fixed fee of $10K, and ends with a triage report and a milestone-based estimate. The report is yours to take to anyone.
Comparing outside reviews? See what a fixed-fee technical assessment should include and cost.
Common questions
What is a software audit?
An independent review of a software project: the code and architecture, the tests, the release pipeline, the security and the way the team works. A good audit ends with what to fix, in what order, and what the work will cost, not only a list of problems.
Is a software audit the same as a code audit?
A code audit reviews the code itself. A software audit, or technical assessment, also reviews the process, the release pipeline, security and ownership, because a struggling project is often stuck in those areas rather than in the code.
Who should do the audit, our team or someone outside?
Someone outside the project, if you can. The team that built the system is too close to it, and a vendor that wants the follow-on work has a reason to find problems. An independent review whose report you own avoids both.
Why review more than the code?
Because the problems people blame on the code often start somewhere else: in the release process, the tests, the way work is planned, or in knowledge that only one person holds. An audit that reads only the code can miss the cause.
How long does a software audit take, and what does Briebug's cost?
Briebug's Technical Assessment takes about 1 week for a fixed fee of $10K. It ends with a comprehensive report, a triage report of what to fix in what order, and a milestone-based estimate. The report is yours to take to anyone.
Get an independent software audit in about a week.
Book a short call with a senior engineer. We will scope the assessment and confirm the fixed fee before you commit.