What Building Federal Government Applications Taught Me About Software Engineering

The technology was familiar. Everything around it changed.

After more than two decades in software, telecom, startups and engineering leadership, I assumed I had met most of the ways building and running software can be hard. Then I started working on federal government applications, and it was a different experience, though not because the technology was harder. We were still building web applications, designing APIs, working with databases, deploying infrastructure and troubleshooting production, on Python and Django, React, Vue, Ruby on Rails, PostgreSQL, AWS and the usual tools.

What changed was everything surrounding the software: the security requirements, accessibility, documentation, change management, operational controls, the authorization process, and even how we were allowed to word a message to a user. Building software for the federal government is not only delivering features. You also have to demonstrate that the software is secure, accessible, maintainable and operated according to the requirements that apply to it, and that changed how I approach engineering.

Building federal government applications teaches an engineer that quality has more dimensions than working code. Security has to be demonstrable, accessibility has to be designed in, communication has to be understandable, changes have to be traceable, operations have to be documented, and risk has to be evaluated continuously. None of those is unique to government, and government is where they stop being optional.

Applications that support federal programs

My government work includes systems that support federal small business certification programs: applications that help businesses interact with a program, submit information and work through a certification process. I built FedPath, a tool for small businesses finding federal contracts, partly because I had seen how hard those processes are from the inside.

From an engineering seat the challenges are recognizable: complex business rules, several user roles, long application workflows, document management, integrations with other systems, data validation, reporting, and keeping a system current as the program rules change. What government adds is a set of responsibilities that stay invisible in a startup. A change that looks simple in the code may need security review, accessibility validation, documentation and additional testing before it can ship. At first that feels like process for its own sake. Over time I understood what each piece of it was protecting.

FedRAMP: implementing a control and proving it works

Security was not new to me. My career started with router access control lists, NetScreen firewalls and a managed security service, and it continued through application and cloud security. Federal cloud security formalized it to a degree I had not worked under before. FedRAMP, the Federal Risk and Authorization Management Program, is the standardized approach to assessing and authorizing cloud services that federal agencies use.

The lesson that mattered most was the difference between implementing a security control and demonstrating that it operates effectively. It is one thing to say access to production is restricted. It is another to show who has access, how it was approved, how authentication is enforced, how privileged access is controlled, how access is reviewed, how every change to it is recorded, and what happens the day someone leaves. The same applies to logging, vulnerability management, encryption, incident response and configuration management. Security is a set of operational responsibilities as much as a set of technologies, and the responsibilities need evidence.

One distinction is worth being precise about. A FedRAMP authorization covers a cloud service offering within a defined boundary. It does not authorize every application deployed on that infrastructure. The application still carries its own responsibilities and may face additional agency requirements, and designing a government system means knowing which controls you inherit from the platform and which you own.

Authority to Operate: what production-ready means

In commercial software, deploying usually comes down to whether the organization believes the system is ready. In federal environments the decision is formal. An Authorizing Official evaluates the system’s risk and decides whether to grant an Authority to Operate, an ATO. The engineering team does not make that decision. It contributes to it, by implementing controls, maintaining documentation, addressing findings and providing technical evidence: system security plans, control assessments, risk assessments, plans of action (POA&Ms) for open findings, configuration management, vulnerability management, continuous monitoring, incident response procedures and contingency plans.

What struck me was how closely that work sits on top of ordinary engineering. A deployment pipeline is no longer only a way to ship code. It is the record of what changed, when and by whom. Logging is no longer only for troubleshooting. It supports auditability, security investigations and continuous monitoring. Infrastructure configuration is no longer only a DevOps concern. It is part of the system’s documented security posture. Production readiness means more than the application working. It means the organization can show that the risks are understood and managed, and the engineering has to produce that showing as a by-product of doing the work well.

Section 508: accessibility is an engineering responsibility

Section 508 requires covered federal information and communication technology to meet applicable accessibility standards, which for web applications means the Web Content Accessibility Guidelines at the required level. In practice it means designing for how people with disabilities use the system, which a development team focused on whether a feature looks right will miss. Does it work with a screen reader? Can it be operated entirely from the keyboard? Are the form fields labelled? Are validation errors understandable without seeing them? Is the contrast sufficient? Can someone get through a long workflow without relying on visual cues? Those are engineering questions as much as design questions.

A certification application makes it concrete. A business owner completes a long form, uploads documents, reviews the information and submits. If a validation error is only red text, some users never learn what went wrong. If a custom dropdown ignores the keyboard, some users cannot complete the form at all. If focus is not managed when a modal opens, a screen reader user loses their place. A feature can pass every functional test and still be inaccessible, which is why accessibility belongs in design, implementation, testing and the acceptance criteria. Automated tools catch some of it; keyboard and assistive-technology testing by a person catches the rest. I treat it as part of software quality rather than a step at the end, which is why it is a release gate in the public-service modernization case study.

Plain Writing: the hardest problem wasn’t technical

The requirement I find most interesting is Plain Writing. Federal agencies have a responsibility to communicate clearly with the public, and the Plain Writing Act and the guidance around it ask for communication people can understand and use. For a government application that is not decoration. Imagine a small business owner applying for a certification who does not know the difference between an eligibility requirement, supporting documentation, a certification decision and a program-specific rule, and the interface explains itself in legal and administrative language. The software can work perfectly and the person still cannot finish. That is a product problem, and usually an engineering problem too, because the words come out of the code.

Government applications carry complex business rules, and the user should not have to understand the implementation to complete a task. Instead of exposing internal terminology, the interface should say what to do next. “Validation failed due to missing required documentation” is accurate and useless. “Upload your ownership document before continuing” is actionable, provided the wording reflects the program’s actual requirement, which it has to. Complex rules do not require a complicated experience, and the best software I have shipped for startups and consumers followed the same principle: help people understand what to do next.

Security controls shape the architecture

Government security requirements reach into architecture, and access control is the clearest case. A typical application starts with a few roles. A government system may need permissions by program responsibility, organizational boundary and specific action: who can view an application, who can edit it, who can approve or reject it, who can open a sensitive document, who can export, and what happens when someone’s responsibilities change. Those decisions land in backend authorization, API design, database access and frontend behaviour at the same time.

Hiding a button in React does not stop anyone from calling the API. Authorization is enforced on the server, on every request, against the specific record, the point I made in API architecture lessons. Audit logging asks its own questions: which actions must be recorded, what each record captures, and how the records are protected from the people they describe. Security requirements are never isolated tasks on a backlog. They shape the system.

Security doesn’t end at deployment

A system that was secure the day it was authorized becomes vulnerable if nobody maintains it. Software changes, dependencies acquire vulnerabilities, configurations drift, new threats appear, and users join and leave. Continuous monitoring is how an organization notices and responds, and from an engineering seat it means vulnerability scanning, dependency management, infrastructure monitoring, security logging, access reviews, configuration assessment, patching, incident response and tracking remediation to closure.

The hard part is folding that into normal engineering operations. Treated as a separate function, security becomes a bottleneck and a source of surprises. Considered throughout the development lifecycle, it becomes routine. That is why I value automation: automated tests, dependency checks, infrastructure validation and deployment controls make the security work consistent and leave a trace. Automation does not replace review or judgment. It removes the repetitive part and makes the evidence a by-product. On my teams, vulnerabilities are monitored and fixed as high-priority work, in government and out of it.

Documentation and change management

The biggest adjustment is documentation and change management. In a startup, a feature is requested, someone writes it, it is reviewed, and it ships. Government environments may add steps depending on the authorization boundary, the change classification, the contract and the agency’s procedures: a security impact analysis, formal approval, documentation updates, additional testing. When the change is small, that is frustrating. The purpose is to reduce risk and keep accountability, and once you have seen what an untraceable change costs in a system people depend on, the purpose is easier to respect.

The leadership challenge is making those processes effective without manufacturing bureaucracy. A process nobody understands or follows improves nothing. A process that creates heavy manual work slows delivery without buying proportional safety. The target is requirements that are clear, automation for everything that can be automated, and controls that address real risks rather than ceremonial ones.

What it taught me about leadership

Most of my career was spent where speed and flexibility were essential, and startups still need to deliver fast with little. Government work adds accountability, accessibility, security and operational control. I have learned the two are not opposites. You can build efficiently with strong engineering discipline, and it takes planning: security requirements identified early, accessibility in the acceptance criteria, documentation that evolves with the system, testing that covers the non-functional requirements as well as the functional ones, and a team that understands why each requirement exists.

As an engineering leader I see my job as helping developers work within those constraints, which means explaining what problem a process solves rather than announcing another process. Engineers who understand the purpose implement the requirement well and find the ways to make the workflow lighter. The ones who were only told to comply do the minimum and resent it, and the system is worse for it. I wrote about how I try to run that conversation in how I run engineering.

The requirements, on one page

The whole thing fits on one page once you see it as a cycle with three kinds of actor: the agency, which decides; engineering, which builds and supplies the evidence; and the monitoring that runs after authorization and feeds the next assessment. The figure is simplified from the NIST Risk Management Framework, and the step where most engineers first meet it, Implement, is only one of six.

Beyond FedRAMP, the ATO, Section 508 and Plain Writing, an engineering team on a federal system works inside a wider set of frameworks. Which ones apply depends on the agency, the system boundary, the data and the contract, and the authoritative text is at FedRAMP, NIST, Section508.gov and PlainLanguage.gov rather than in any blog post. The table is the map I keep in my head.

Still learning

Every industry has taught me something. Carrier networks taught me infrastructure reliability and capacity planning. Telecom taught me performance, routing and operating cost. Startups taught me to work with little and make practical architectural decisions. Digital publishing taught me traffic, monetization and business performance. Federal applications have taught me security authorization, accessibility, compliance and accountability. Different environments, different requirements, and the same fundamentals underneath: understand the problem, understand the constraints, build the right solution, measure the result, keep improving.

Those disciplines are not only for government. A startup does not need an authorization process, and it still benefits from good access control, accessible interfaces, clear documentation and reliable deployment. The skill is applying the level of rigor the system’s risks and the business actually call for. The biggest lesson for me is that building software means more than making something work. It means making something people can trust, understand, use and maintain, and that is what I will carry into whatever I build next.

Short answers