Modern software development is supposed to be iterative.
You build an early version, put it in front of the people who will actually use it, listen to their feedback, and adjust. The goal is not to expect every requirement to be perfect on day one. The goal is to discover misunderstandings while they are still inexpensive to correct.
That process sounds obvious today. Earlier in my career, however, it was often not how government software projects worked.
When Requirements Passed Through Too Many People
Before founding Honor Tech, I worked as a salaried government employee building software, databases, reports, and integrations for court operations.
The work was important. The systems supported judges, clerks, administrators, investigators, bond companies, and other people whose responsibilities depended on accurate and reliable information.
The challenge was not usually a lack of technical skill or good intentions. It was the distance between the person requesting the software and the person building it.
A requirement might begin with a judge or division leader. That person would explain the need to an administrator, who would pass it to an IT director or manager, who would eventually describe it to the developer.
By the time the requirement reached me, it may have passed through several people, each interpreting it through a different perspective.
Sometimes I was fortunate enough to meet with the administrator. Direct access to the judge, clerk, investigator, or other person who would actually use the feature was less common.
The result was a kind of quasi-waterfall process:
The software might have matched the written requirement perfectly and still missed the real operational need.
That is one of the most important lessons I learned in government technology: a technically correct solution can still be the wrong solution.
The Problem Was Not That People Did Not Care
It would be easy to blame the process on judges, administrators, managers, or IT departments. That would also be unfair.
Judges had courtrooms to manage. Clerks had deadlines, filings, records, and members of the public waiting for assistance. Investigators had active cases. Administrators were balancing policy, staffing, budgets, and competing priorities.
Many stakeholders simply did not have several hours available for software discovery meetings.
There were also notable exceptions. Certain judges, division directors, and administrators went out of their way to meet with me, explain their processes, review early versions, and provide feedback. Those projects usually benefited from that involvement.
They also demonstrated something important: stakeholder access is not merely a courtesy to the development team. It is one of the strongest predictors of whether the finished software will reflect how the organization actually operates.
Why Late Feedback Is So Expensive
A misunderstanding discovered during a sketch or prototype may take a few minutes to correct.
The same misunderstanding discovered after development may affect the database, user interface, security rules, reporting, integrations, training materials, and testing.
Consider a seemingly simple request such as, “Add a status field.”
Before building it, a development team should understand:
The request may only require one field on the screen, but the business rule behind that field can affect the entire system.
When developers cannot speak with the people who understand those rules, they have to fill in the gaps. Even careful and reasonable assumptions can be wrong.
Contracting Changed the Conversation
Later, as a contractor and eventually as the founder of Honor Tech, I noticed a meaningful improvement in stakeholder involvement.
I believe part of the reason was financial accountability.
When an organization is paying a contractor by the hour, by the milestone, or according to a defined project budget, leaders tend to monitor the work more closely. Meetings are scheduled. Deliverables are reviewed. Questions receive faster answers. Someone pays attention to whether the project is using its budget effectively.
As a contractor, I was kept on a much shorter leash than I had been as an internal employee.
That was not a negative experience. In many ways, it was the responsible choice.
Government budgets are public resources. When money is overspent, misused, or left unused, someone may have to explain why. Frequent reviews, milestone approvals, demonstrations, and budget checks help protect both the agency and the contractor.
That oversight can also improve the software.
Regular demonstrations force everyone to compare what is being built with what the organization actually needs. A stakeholder can see the workflow, react to it, and identify problems before the project reaches its final stages.
The shorter leash often produces a tighter feedback loop.
Go-Live Is Where the Real Workflow Appears
My time as a government employee also gave me another valuable perspective.
After a system went live, judges, clerks, background investigators, bond companies, and other users would sometimes contact me directly.
You might expect communication to pass through management or a formal support structure. In practice, that insulation was not always present. When I later became a manager, I worked to improve that process so employees were not constantly interrupted and requests could be prioritized properly.
Still, those direct conversations taught me lessons that would have been difficult to learn from a requirements document.
I saw how people actually responded to new software.
I saw the hesitation that appeared when a familiar button had moved.
I saw users develop workarounds because a process that seemed efficient during development did not fit the pace of a real courtroom or clerk’s office.
I saw how a small delay could become a serious problem when repeated hundreds of times.
I also saw the difference between a software bug and an adoption problem. Sometimes the system was functioning exactly as designed, but the terminology was unfamiliar, the next action was unclear, or the interface did not match the user’s mental model of the process.
Those are real software problems, even when no error message appears.
Direct access to users also enabled faster bug-fix cycles. Instead of receiving a vague report after it had passed through several people, I could see the issue, ask what the user had been doing, understand the operational impact, and resolve the underlying problem.
Without that direct context, the same issue might have taken several cycles to reproduce, interpret, and correct.
User Adoption Is Part of Software Quality
A system is not successful merely because it compiles, passes automated tests, and satisfies a written list of requirements.
It must also work for the people using it under real conditions.
That means considering:
This is especially important in government and judicial environments, where software often supports complicated rules, sensitive information, public-facing services, and processes that cannot simply stop because a system is confusing.
Training helps, but training cannot compensate for a workflow that was designed without understanding the people performing it.
What I Carry Into Honor Tech Projects Today
These experiences continue to shape how Honor Tech approaches software development.
We do not assume that a written requirement tells the entire story. We look for the operational reason behind the request.
We encourage clients to involve the people who will use the system, not only the people approving the budget. Managers understand organizational goals, but frontline users understand the exceptions, bottlenecks, and workarounds that occur every day. A successful project needs both perspectives.
We also favor early demonstrations over late surprises.
A prototype, workflow mockup, or partially working feature can answer questions that a long document cannot. People often struggle to describe exactly what they need, but they can quickly identify what feels wrong when they see it.
That is not a failure of the stakeholder. It is part of how software discovery works.
The development team’s responsibility is to make feedback possible before every decision becomes expensive to reverse.
Better Software Comes From Better Access
The biggest lesson from my years developing software for courts was not about a programming language, database, or framework.
It was about communication.
Every layer between the developer and the end user creates another opportunity for context to be lost. Sometimes those layers are necessary, especially in large organizations. The answer is not to remove management, governance, or accountability.
The answer is to create deliberate opportunities for direct understanding.
Let the developer observe the real process.
Let users see the software before it is finished.
Let managers review progress while there is still time to change direction.
Let budget owners understand what is being built and why.
And after launch, pay attention to what users are actually experiencing, not only whether the system is technically online.
The goal is not to eliminate every change request. That is unrealistic. The goal is to discover the important changes early enough that they improve the project instead of derailing it.
At Honor Tech, we build custom applications, databases, integrations, reports, and business systems around the way organizations actually work. That begins with technology, but it succeeds through access, feedback, and a willingness to listen before the software is considered finished.