Software Quality Notes for Solo-Devs

Last updated October 18, 2025

For log of changes, click here: log

(!) DISCLAIMER: This is an evolving document! As I learn new things, I will add to this, so keep checking!

Software quality is both the most difficult thing and also among the most important things solo-devs have to focus on. It is difficult because most software quality guides are written with organizations or corporations in mind. Without the frameworks and the peers to guide you, it becomes very hard to ensure that your solo projects are up to standards.

Luckily, your solo projects most likely don't need that much rigor. But it's still good to keep an eye on quality, both as a good habit for if you go into a traditional dev job and also just for your own peace of mind and sanity. The number of projects I've created that have crashed and burned because I didn't adhere to some standard of quality is embarrassing.

Hence, here are some notes I've taken based on my own research and study of software quality. Use at your own pleasure and discretion.

Elements of Software Quality

MAIN SOURCE: Practical Guide to Software Quality Management, John W. Horch

To ensure software quality you first have to make sure that you begin correctly.

"Well begun is half done." - Politics, Aristotle

This means delineating precise requirements, so that you know exactly what you are attempting to accomplish.

Without knowing what you are even going to do, how will you do it in the first place? Even if you have a vague concept of what it is, without more specificity you will likely suffer from lack of objective, and being overwhelmed by the possibilities.

Clearly state the problem you are trying to solve. Properly define what you require from a solution, and deeply understand what it is that you want.

These take up among the first few stages of the Software Life Cycle (SLC). There are some commonly defined stages in the SLC, and for solo-devs these are:

• Concept Definition (What is the problem?)
• Requirements Definition (What do we want from a solution?)
• Design and Coding
• Testing (Prove that your solution is "correct")
• Deployment and Operation
• Maintenance (Improve the solution)

Aside from the beginning, you must also keep up the quality throughout the SLC.

The eight elements of software quality are:

• Standards
• Review
• Testing
• Defect Analysis
• Config Management
• Security
• Education
• Vendor Management

Standards

Standards govern the entire SLC and development process.

Standards are consistent, uniform, rigorous, and enforceable. They do not change or contradict each other, they have oversight over every relevant detail, and they are active and working throughout development.

Of course, you will often have to make your own standards. It is rare enough for you to have to refer to standards created by an external organization. Either way, standards are useful so you may standardize certain aspects of your work that would be tiring to keep thinking about otherwise, or to provide a structure for your thinking.

For example, when you create documentation or a game design document, the format of these will often be governed by a standard.

How you write out your requirements formally may also be governed by a standard, such as EARS format.

It is up to you to decide what to standardize. A good starting point is documents containing development information, or perhaps even how to write commit messages. But there is no need to make standards of everything. Oftentimes, guidelines (recommendations) and your own common sense will be enough. Don't put so much rigor that it becomes stifling to code.

Also, standards must be necessary, feasible, and measurable. Without these, they are not enforceable.

There must be a reason for a standard to exist, otherwise it is a waste of time and you will likely become frustrated with it.

The standard must also actually be possible to follow, and ideally follow easily after some initial acclimatization.

Finally, you need to be able to check that you are following the standard.

Review

In the corporate world, reviews are intended to keep your peers and managers up-to-date on what's happening in development.

Since you're on your own, they're instead a way for you to keep track of the progress you have done thus far, and to collect your thoughts on the best way to proceed forward.

WALKTHROUGH/INSPECTION: You walk through the software component, explaining its purpose, so that you or your peers can identify defects

PROCESS REVIEW: You examine your workflow, your processes, and your methodologies to see what you could be doing better to make your work easier.

AUDITS: These are examinations of your work to ensure that they are consistent. For example, a physical audit compares your final code to your final documentation. And a functional audit compares test results with requirements.

Testing

This makes sure that the software requirements are being satisfied by the software.

Testing is NOT done after you design software, but IN PARALLEL.

Unit and Module Tests are done to ensure the fitness of each isolated module.

Integration Testing is done when modules are combined into subsystems.

System Testing is the testing of the entire system finally.

As you proceed through these, the level of detail and sophistication you will need in your test reports increases.

Test reports should include expected output, actual output, and a conclusion based on discrepancies (or lack thereof) in the former two.

Defect Analysis

This involves detection, correction, and change control.

When a change is requested, the situation must be verified. Afterwards, the change may be made. If it is correct, it may then be reported and installed into the system.

Defect information can be used to determine patterns of defects, helping you improve your development process.

Configuration Management

Consists of identification, control, and accounting.

Identification: Naming of components.

Control: Preventing unauthorized changes.

Accounting: Versioning and change history.

Accounting, for example, is mostly handled by Git commit history. Generally, version control systems like that help out a lot in many aspects of configuration management. Since you're a solo-dev, I think that this especially will mostly be done informally.

Security

This means protecting your data from physical threats, data theft, and malware. Remember to back up! Also, if your software is data-centric (and many are), be sure to cleanse and validate the data going into it, because many software malfunctions are actually due to malformed data.

Education

Basically, make sure you know how to use the tools you're given, and make sure the user knows how to use the application. Also make sure you know how to operate the system and install it, such as when you have to troubleshoot for several platforms. Aside from that, for solo devs this does not extend far.

Vendor Management

This entails getting the user's confidence that the product is of quality.

I assume the products you will be creating are mostly going to be off-the-shelf, in which case the user ultimately has to trust you. But there are of course things you may do to convince them.