Our Working Principles

While we endorse the Government Design Principles powering the most successful technology programs in the public sector today, we think vendors need their own list too.

Our approach works backwards from a fundamental question: will the finished project make users feel that they're getting outstanding value for their tax dollars?

Our list isn’t about generic corporate values, but about how we accomplish this in practice.

1. Every dollar matters

We’re taxpayers too, and care about being good stewards. The core of Silicon Valley thinking is asking if there’s a better way—not just at the beginning, but before and during every step. There almost always is, especially in revisiting the why behind requirements.

Thinking from first principles drives costs down substantially. Not through cutting corners, but by rewriting the rigid workflows and playbooks that no longer serve constituents.

What if I have a fixed budget allotment that I need to spend in full?

We can help you get more than you bargained for by allocating your savings to additional items like employee training, product iteration, and prepaid support fees.

2. Hiring proven performers matters

We want governments to have easier access to elite technical talent—ie. to the people who passed ultra-competitive hiring bars and cut their teeth on unusually ambitious projects.

It wasn’t always possible to get them to work for or with the public sector. That’s gradually changed, and our role is to connect them with governments eager to hire them.

Our talent network isn' just familiar with the best tools. In many cases they made them.

Which Silicon Valley companies do GovTron's talent partners work for?

Our network includes established technical talent—including developers, designers, PMs, and user researchers—from Meta, Google, LinkedIn, Amazon, and more. We work to understand your needs during initial consultations and then assign each project component to the partner best suited for it. That way you're always getting the highest quality work, with none of your budget going towards their education.

3. Good design starts with users, not requirements

When a constituent uses a piece of software, it should be both easy and intuitive for them to get the result they’re entitled to. This is only possible with good design. And good design must work backwards from understanding what delights and frustrates users. 

We work with clients to ensure that requirements are (re-)written in a way that reflects what users actually want—or rather what they’d want if they knew what was possible.

What if our requirements are mandated and can't be changed?

The most effective response (at a pre-RFP stage) is usually working together to create a brief that outlines the expected cost savings—plus security and flexibility advantages—that can be unlocked by adapting requirements. Those who designed the initial mandates usually just want sure outcomes, and may be delighted to learn there are newer, better, and fully derisked ways to meet those ends. This approach is also now explicitly encouraged at a federal level.

4. Reusability matters

Unnecessarily reinventing the wheel makes software more brittle, more expensive, and less secure. By factoring in the best open-source tools and reusable code, we can leverage the continuous input of entire communities of top developers—while often saving on budget.

It's a bit like making a new car. You can build your own drivetrain and frame from scratch, sure. But that means expending significant extra capital instead of just taking advantage of the shared investments already improving and battle-testing those core components.

Our clients still own the code for all the custom work we do atop those shared components— forever, with no ongoing licensing fees, and with full documentation to allow any future contractors to easily pick up from where we left off.

What if we need something fully bespoke or can't use open-source components?

In cases where open-source and/or reusable components are truly off the table, we can still furnish an attractive bid for fully custom design. Our default is just to start by working with you to ensure it's truly necessary first, as legislators and policymakers are increasingly open to rethinking their historical objections here.

5. Good design requires deep historical literacy

Not all experience is equal. It’s not just about doing a lot of work, but about learning from as many historical projects and approaches as possible. What went wrong? What went right? 

We’ve modeled each step of our workflows around a genuine zeal to learn from the past. It's also the basis of our recruiting strategy. When we vet talent partners, one cornerstone criteria is how much they've internalized from project post-mortems. We select for smart people who demonstrate real curiosity about how and why things break and fail.

What's a hallmark of good literacy?

Silicon Valley tends to do things at scale. New features might be shipped to tens or hundreds of millions of users, often across dozens or more geographies and languages. With this complexity comes many potential failure points. We aim to recruit people who've honed strong intuitions about the tradeoffs between small failures (say an hour or two of downtime) and overall development costs.

6. The future matters too

We don’t live in a static world. While we always seek to deliver fully on current needs, we consider it equally important to ensure this doesn’t come at the price of future flexibility. The right design today should make adding new features in a year painless.

It's also crucial to design architectures with a mind to which tools, integrations, and languages may age poorly or lose support over time—and to future-proof them against the new vulnerabilities likely to arise as technology advances.

What does future-proofing look like practically?

Legacy contractors are notorious for using the tools they're most familiar with. While this lets them tap into the widest pools of available talent, it robs clients of both optimal performance and is more likely to leave them flat-footed as the industry moves on to the best new tools. This is why we use developers who work closest to the future. Though we'll never recommend tools that are too new to have suitable safety records, or that haven't yet cleared a minimum certainty of becoming widely adopted.

7. We use AI responsibly

Even the world’s best software companies have begun incorporating AI tools into their own development work. Used effectively and thoughtfully, they can be a type of magic. 

But some lean on them too much, else outsource their work to these tools entirely. While AI can enable strong performers to work far more efficiently, it must never be a substitute for human expertise. All components should also undergo robust QA testing before going live.

We use these tools responsibly—not just because it's good ethics, but because it's good strategy. Our long-term reputation matters, and we want to build software that holds up.

Where can I learn more about evolving best practices here?

We have a companion blog that we'll keep updated a few times a year to track our learnings and the ongoing consensus amongst responsible professionals.