Many companies know that their software is business-critical, but not how healthy it really is from a technical perspective. The application runs, but new features are getting slower, bugs appear more often or nobody on the team can say with confidence whether the architecture is still fit for purpose. That is when a software audit becomes useful.
A software audit is a structured technical assessment of an existing application. The goal is not to label code as "good" or "bad" in general. A good audit answers concrete questions: How maintainable is the system? Which security risks exist? Where is technical debt accumulating? Which modernization steps are sensible? And should the company continue building on the system or rethink parts of it?
Short answer: A software audit checks code quality, architecture, security, data model, performance, operations, tests and maintainability. A compact audit often costs 5,000 to 15,000 EUR. A deeper technical audit with code review, security check, infrastructure review, interviews and roadmap frequently ranges from 15,000 to 40,000 EUR. Very large or regulated systems can require more effort.
When does a software audit make sense?
An audit makes sense whenever technical uncertainty blocks a business decision. Typical situations include:
- Existing software needs to be taken over by a new agency.
- A web app or platform is becoming slower to develop.
- Security or privacy questions are unclear.
- A company is preparing an investment, acquisition or technical due diligence.
- An MVP needs to become a production platform.
- A legacy system creates high maintenance cost.
- Internal developers warn about technical debt, but there is no neutral assessment.
- Leadership needs a roadmap with effort, risk and priority.
An audit is especially valuable before large budgets are committed. Understanding risks before modernization is cheaper than discovering halfway through a project that the data model, tests or architecture cannot support the plan.
What should a software audit check?
The exact scope depends on the system. A public website needs different checks from a B2B customer portal, mobile app or SaaS platform. Common areas include:
| Area | What it checks |
|---|---|
| Code quality | readability, structure, duplication, error-prone areas, conventions |
| Architecture | layering, modularity, dependencies, scalability |
| Security | authentication, permissions, input validation, secrets, known vulnerabilities |
| Data model | consistency, migrations, integrity, performance, future readiness |
| Tests | coverage of critical flows, automated tests, manual risk |
| Operations | deployment, monitoring, backups, logs, rollback, ownership |
| Performance | loading times, database queries, API latency, frontend bundles |
| Maintainability | documentation, setup, onboarding, technical debt |
The result should not be a long list of abstract criticism. A good audit prioritizes: What is critical? What should be fixed soon? What belongs on the roadmap? What can be accepted deliberately?
Code review: what code quality really means
Code quality is not an aesthetic concern. It determines how quickly new features can be built, how safe changes are and whether other teams can take over the system.
A code review in an audit checks for:
- clear responsibilities in components, services and modules
- understandable naming and structure
- error handling and edge cases
- unnecessary duplication
- files or functions that are too large
- direct database access in the wrong places
- mixing UI, business logic and data access
- dependency on individual people or undocumented knowledge
Poor code does not automatically mean that everything must be rebuilt. Often a focused technical roadmap is enough: stabilize critical areas, add tests, decouple modules and build future features with clearer rules.
Architecture review: can the system still grow?
Architecture determines whether software can grow. A system can work well in version one and still become a blocker later when roles, tenants, integrations or data volumes increase.
Important audit questions include:
- Is the application separated sensibly into frontend, backend, data and infrastructure?
- Are business logic and presentation clearly separated?
- Are interfaces documented and versionable?
- Can new features be added without large side effects?
- Is the system prepared for multiple user groups, tenants or roles?
- Are certain areas especially risky in every release?
- Does the architecture still match the current business model?
Especially in web app development, architecture is more than framework choice. What matters is how data, permissions, processes and operations work together.
Security audit: the most important risks
A software audit does not replace a full penetration test, but it can reveal many security risks early. Key areas include:
- insecure authentication or sessions
- missing server-side permission checks
- sensitive data in logs or error messages
- unsafe file uploads
- outdated packages with known vulnerabilities
- API endpoints without sufficient authorization
- secrets or API keys in the repository
- missing rate limits
- missing backup and recovery concept
For portals, internal tools and SaaS products, it is not enough to check only login. The system must ensure that every user can only see and change data that belongs to their role.
Operations and monitoring review
Many risks appear only after launch. That is why operations belong in a technical audit. An application can look functionally solid and still be operated in a risky way.
An audit should check:
- How is deployment handled?
- Are development, staging and production environments separated?
- Are builds automated?
- Are errors captured?
- Is uptime and performance monitored?
- Are backups available and tested?
- Is there a rollback strategy?
- Who reacts to critical incidents?
If these points are missing, that is not a minor detail. Without an operating model, every future change becomes riskier. This connects directly to software maintenance.
What does a software audit cost?
Cost depends on system size, technology, documentation, access and required depth. As a rough orientation:
| Audit type | Typical scope | Realistic range |
|---|---|---|
| Quick check | repository, setup, rough risks, short report | 3,000 to 8,000 EUR |
| Technical audit | code, architecture, dependencies, tests, operations, roadmap | 8,000 to 20,000 EUR |
| Security and architecture audit | permissions, APIs, infrastructure, data model, risk analysis | 15,000 to 40,000 EUR |
| Due diligence audit | technical assessment before investment, acquisition or takeover | individual, often from 20,000 EUR |
A cheaper audit can be useful for an initial assessment. For business-critical decisions, the audit should be deep enough to evaluate risks reliably.
Software audit process
A structured process avoids shallow tool reports. A typical audit looks like this:
- clarify the goal and decision question
- prepare access to repository, documentation and infrastructure
- review local setup or staging environment
- analyze architecture and data model
- trace critical flows in the code
- check dependencies and security risks
- evaluate tests, CI/CD and operations
- interview product or engineering stakeholders
- prioritize risks
- create a roadmap with effort and sequence
The most important point is the decision question. An audit for an acquisition is different from an audit for modernization or an audit before a new feature roadmap.
What should the audit deliver?
The result should be understandable for both engineering and leadership. It should not only explain what is wrong, but what should happen next.
Useful deliverables include:
- management summary
- technical risk matrix
- prioritized action list
- architecture and code findings
- security and privacy notes
- maintainability and development assessment
- quick wins
- medium-term modernization roadmap
- recommendation: continue, refactor, modernize or replace
Clear prioritization matters. Not every issue is urgent. An audit should distinguish between "critical", "important", "later" and "acceptable with awareness".
Audit vs. relaunch vs. modernization
An audit is not modernization. It is the basis for a decision. After the audit, there are usually three paths:
| Result | Useful next steps |
|---|---|
| System is stable | maintenance, add tests, small improvements |
| System has technical debt | roadmap for refactoring, documentation and better tests |
| System blocks growth | step-by-step modernization, new architecture, migration |
| System is high risk | replacement strategy or controlled rebuild |
Especially with legacy software, an audit is a better first step than an immediate rebuild. Often parts can be stabilized before deciding what should be replaced.
Checklist before starting an audit
Before the audit starts, companies should prepare:
- access to repository and relevant branches
- technical documentation if available
- information about hosting and deployment
- list of important user flows
- known bugs and technical pain points
- architecture diagrams or system overviews
- access to staging or test environment
- information about database, APIs and integrations
- contact person for business questions
- goal of the audit: decision, takeover, modernization or security
The better this information is prepared, the less time is spent on basics and the more audit budget goes into real assessment.
When is an automated scan not enough?
Automated tools are useful. They find known vulnerabilities, outdated packages, linting issues or simple security warnings. They do not understand whether a business rule is correct, whether a permission model fits the domain or whether an architecture supports the roadmap.
A tool can report that a dependency is outdated. It cannot reliably decide whether a module should be decoupled before the next product expansion. That requires technical judgment, product context and operational experience.
Final thoughts
A software audit is most valuable when a company faces a technical decision: continue building, modernize, take over, invest or replace. It creates transparency around risks, cost and the right sequence of work.
The best audit does not end with criticism. It ends with a roadmap. Then uncertainty becomes a plan: what needs to happen immediately, what improves maintainability and which steps make the product more stable in the long run.
