Why Tech Workers Should Build Municipal Infrastructure Instead of Startups
- the Institute
- 4 days ago
- 10 min read
Network Theory Applied Research Institute
In March 2023, Silicon Valley Bank collapsed. Within 48 hours, startups across the country lost access to payroll accounts. Engineers showed up for work on Monday unsure if Friday's paycheck would clear. By Thursday, the Federal Reserve intervened to prevent complete financial contagion. The crisis resolved—this time. But for three days, thousands of tech workers confronted a reality their equity packages had obscured: their careers depended entirely on venture capital's continuous functioning, and venture capital had just demonstrated it could evaporate overnight.
Between 2022 and 2024, major tech companies laid off over 400,000 workers—not because the workers were unproductive, but because venture capital funding cycles demanded it. Meta eliminated 21,000 positions. Amazon cut 27,000 jobs. Google, Microsoft, Salesforce—the "stable" companies that promised career security—all executed mass layoffs within the same eighteen-month period.
If you're a software engineer, this is your industry now: brilliant technical work that evaporates when funding rounds fail, when growth targets miss, when market sentiment shifts. You optimize ad click-through rates for two years, then watch your entire product line get shut down because it doesn't scale to unicorn projections. Your GitHub contributions become private repositories you can't show future employers. Your work disappears.
Municipal counter-automation offers a different trajectory: building permanent public infrastructure that serves communities rather than shareholders, with stable employment that doesn't depend on VC cycles, in places where you can actually afford to live.
Stable Work Without VC Volatility
Municipalities don't have "funding rounds." Fire departments existed before software and will exist after any individual platform fails. When you build COER for Oakland Fire Department, that work doesn't evaporate because a Series B round fell through or a CEO decided to "pivot to AI." The contract completes. The software deploys. The department uses it for decades.
Compare this to typical startup employment: join a company, ship features for two years, watch the acquirer shut down your product or lay off your team. Or worse—watch your carefully-built software get locked behind paywalls, buried in proprietary silos, or discontinued because it doesn't scale to unicorn growth targets.
AGPL-3 municipal software lives forever in your portfolio. Every commit is public. Every feature you ship benefits hundreds of departments simultaneously. You build once, and the impact propagates. This is how Linus Torvalds built a career: visible contributions to permanent infrastructure that outlasted any single employer or market cycle.
Geographic Freedom and Economic Viability
Silicon Valley's median home price exceeded $1.5 million in 2024. San Francisco rents average $3,500 for a one-bedroom apartment. Seattle isn't far behind. New York tech workers pay similar amounts. The math doesn't work: six-figure salaries get consumed by rent and cost of living, leaving little to save or invest. You're earning well but building nothing—the housing market extracts faster than your salary accumulates.
Municipal counter-automation work happens anywhere. If you're building COER, you can work from Sacramento or Syracuse, Chattanooga or Cheyenne. The fire department doesn't care if you commute to an office—they care if the software routes emergency calls correctly and enables collective intelligence networks. Your cost of living drops by 50-70% while your impact expands. That $120,000 salary in Boise has more purchasing power than $200,000 in San Francisco, and you're building infrastructure your neighbors actually use.
But there's a deeper economic shift here. Instead of one employer (Google, Meta, Amazon), you have dozens of municipal clients. Oakland contracts you for COER deployment. Berkeley hires you for feature customization. The county brings you on for mesh network integration. You're not an employee dependent on one company's health—you're infrastructure expertise that multiple communities need. Diversified income streams replace single-employer dependency.
Some developers work full-time on municipal contracts. Others contribute part-time while maintaining other employment. The freelance developer model that worked for web development in the 2000s now applies to public infrastructure software—except with AGPL-3, your improvements feed back into commons that benefit everyone, including you on the next project. You're not competing with other developers; you're building on their work and they're building on yours.
Real Technical Challenges, Visible Impact
Consider what you're actually building with municipal counter-automation:
Distributed intelligence networks where thousands of citizen nodes broadcast observations to expert hubs in real-time
Hub-and-spoke architectures that route emergency information bidirectionally between first responders and incident commanders
Fault-tolerant systems where any node failure reroutes automatically across mesh networks
Privacy-preserving aggregation that generates statistical intelligence from voluntary reports without surveillance infrastructure
Real-time coordination protocols for incident commanders managing distributed observer networks during active emergencies
Edge computing optimization for hardware running in fire stations and city halls, not data centers
Multi-language interfaces serving communities from São Paulo to Mumbai
These aren't CRUD apps wrapped in React. This is infrastructure engineering—distributed systems, network topology, fault tolerance, security architecture. The technical challenges that drew you to computer science before you spent three years optimizing checkout funnel conversion rates.
And the impact is visceral. When Sacramento deploys COER and emergency response times decrease because incident commanders receive real-time intelligence from citizen observers, you know your code mattered. When wildfire coordination improves because residents broadcast evacuation status directly to emergency coordinators, you see the difference. When a small rural department gets enterprise-grade collective intelligence capabilities they could never afford commercially, you understand what you built.
Compare this to optimizing ad targeting: you'll never know if your improvement increased purchases or just annoyed users into clicking to make the ads stop. You'll never see the downstream effects of your recommendation algorithm. You'll never understand if your work made anything better. Municipal infrastructure software shows you exactly what it does and who it serves.
Ownership and Technical Agency
Here's what happens with proprietary software development: you write brilliant code, your employer owns it, and you have zero control over what happens next. They can close-source it, discontinue it, sell it to a patent troll, or simply let it rot unmaintained. You invested months of expertise, and it vanishes into corporate archives. Your professional legacy is PowerPoint slides in a VP's quarterly review deck.
AGPL-3 inverts this relationship. You write code for Oakland Fire Department. That code is yours and theirs and everyone's simultaneously. If Oakland's vendor relationship with you ends, you can still maintain the software. If another department wants features Oakland doesn't need, you fork the project and build them. If Oakland stops maintaining their instance, you can take over maintenance or any other department can.
You have technical agency—the ability to continue improving your work regardless of any single client's decisions. Your code lives in public repositories, permanently accessible. Future employers can examine your actual contributions, not just read your claims about what you built behind corporate firewalls. You build a career on visible technical work, not on storytelling about invisible proprietary systems.
This is what open source promised before corporations figured out how to capture it through permissive licenses and proprietary services. AGPL-3 keeps that promise intact: improvements circulate, knowledge propagates, and no single entity can enclose the commons. When you contribute to municipal infrastructure, you're building something that outlasts any individual employment relationship.
Community Integration Instead of Isolation
Tech workers often live in cities but remain disconnected from them. You work in SoMa or Capitol Hill, surrounded by other engineers, eating lunch at company cafeterias, socializing through workplace Slack channels. Your friends are other tech workers. Your conversations revolve around stock options, offer negotiations, and which companies are hiring. The city becomes scenery you pass through between apartment and office.
Building municipal software integrates you into the actual city. You meet fire chiefs and emergency coordinators. You sit in department meetings and understand how public services actually operate. You see your work deployed in the buildings you pass on your commute. When your neighbor discovers you built the software their fire department uses, that's a different conversation than explaining you optimized TikTok's engagement algorithm.
The abstractions of "users" and "stakeholders" become specific people whose work you're supporting. You understand how the incident commander uses the Janus-facing interface you designed. You see how distributed citizen reporting improves coordination during actual emergencies. You watch fire marshals use statistical models built from voluntary safety inspections to allocate department resources. The software isn't an abstraction—it's infrastructure woven into how your community functions.
This isn't nostalgia for small-town community. It's recognition that building public infrastructure creates relationships that building ad platforms never will. When Silicon Valley engineers gather, they talk about which company is acquiring whom, which framework is hot this quarter, whose startup just raised funding. When municipal infrastructure developers gather, they talk about which departments deployed new features, which emergency coordination protocols worked during the last wildfire season, which improvements propagated across the mesh network. One conversation is about markets. The other is about infrastructure.
The Skills You Develop Outlast Any Platform
In 2010, being a Rails developer was lucrative. In 2015, it was iOS development. In 2020, React and Node.js dominated job postings. In 2024, everyone suddenly needed "AI/ML engineers." The platform du jour changes constantly, and your expertise depreciates accordingly. You retrain every three years, chasing whatever framework venture capital currently favors.
But distributed systems, mesh networking, fault tolerance, security architecture, database optimization, API design—these fundamentals persist across decades. When you build municipal counter-automation infrastructure, you're developing skills that transfer across any technical domain. The fire department coordination system you build today teaches you principles applicable to supply chain logistics, hospital networks, energy grid management, or any other complex distributed system.
The Janus-facing architecture you design for emergency response? That pattern applies to public health coordination, transportation networks, environmental monitoring—any domain where expert coordination depends on distributed ground truth. Hub-and-spoke topologies, bidirectional information flow, privacy-preserving aggregation—these aren't trends. They're fundamental patterns in how distributed intelligence networks function.
And because it's open source, your learning is bidirectional. You study how other developers solved similar problems in different municipalities. You fork implementations from Porto Alegre to understand their approach. You contribute improvements that developers in Bangalore will build upon. The entire global community becomes your continuing education program. You're not learning whatever framework your current employer demands—you're developing expertise in permanent infrastructure patterns.
This is how you build a career that outlasts platform hype cycles: by developing expertise in fundamentals rather than temporary frameworks, by contributing to permanent infrastructure rather than proprietary products, by building skills that serve any distributed system rather than one company's current technology stack.
Exit from Ethical Compromise
A 2023 survey of tech workers found that 67% felt their work "didn't contribute meaningfully to society," and 54% experienced ethical concerns about their employer's products. Engineers at Meta knew Facebook's algorithms amplified misinformation and damaged teen mental health. Amazon engineers understood AWS enabled ICE surveillance infrastructure. Google engineers protested Project Maven—military AI they didn't want to build.
These ethical compromises aren't personal failures. They're structural outcomes of building for platforms designed to extract maximum value from users. When your employer's business model depends on surveillance, manipulation, or monopoly, your brilliant engineering serves those ends regardless of your intentions. You can be the most ethical person in your company, and your work still enables systems that make the internet worse.
The cognitive dissonance becomes unbearable. You're smart enough to understand what you're building. You read the internal research showing your recommendation algorithm increases radicalization. You see the data on how engagement optimization creates psychological dependency. You know the privacy violations your surveillance infrastructure enables. But you also have a mortgage, student loans, health insurance tied to employment. So you compartmentalize. You tell yourself it's not your decision. You focus on the technical challenge and ignore the systemic outcome.
Municipal counter-automation eliminates this tension. The fire department isn't optimizing for engagement—they're coordinating emergency response. The hospital network isn't harvesting data for advertisers—they're managing patient care. Schools aren't building psychological dependency loops—they're facilitating education. The stated purpose is the actual purpose. There's no hidden extractive agenda underneath.
You can explain your work to your family without euphemisms. You can look at your career trajectory without cognitive dissonance. You build things that make the internet—and the physical world it coordinates—work better for the people who use it. When someone asks what you do, you say "I build emergency coordination systems that enable collective intelligence networks" and that's the complete truth. No corporate speak. No obfuscation. Just infrastructure that does what it claims to do.
What You're Actually Choosing Between
The choice isn't between idealism and pragmatism. It's between two different pragmatic paths:
Path One: Venture Capital Employment
Salary: $150,000-$250,000 in high-cost cities
Rent: $2,500-$4,000 monthly
Equity: Illiquid, probably worthless
Stability: Layoffs every 18-24 months
Portfolio: Private repositories you can't show
Impact: Optimizing metrics that extract value from users
Geography: San Francisco, Seattle, New York
Career arc: Retrain every 3 years as platforms change
Work: Often ethically compromising, always extractive
Path Two: Municipal Infrastructure
Income: $80,000-$150,000 across diversified municipal clients
Rent: $800-$1,500 monthly in mid-size cities
Ownership: AGPL-3 code you control permanently
Stability: Municipalities don't have layoff cycles
Portfolio: Public repositories demonstrating real skills
Impact: Building collective intelligence infrastructure
Geography: Anywhere
Career arc: Developing permanent expertise in distributed systems
Work: Serving stated community purposes, no hidden extraction
The venture capital path requires you to earn more because it extracts more. The municipal infrastructure path lets you keep more of what you earn because the living costs less and your work builds equity you actually own—not company equity that evaporates in layoffs, but technical equity in the form of public contributions to permanent infrastructure.
After five years on Path One, you've moved between three companies, survived two layoff cycles, and accumulated illiquid equity worth maybe $50,000 if you're lucky. Your GitHub shows private repositories and one contribution to a framework that's now deprecated. You can afford rent but not home ownership. You've optimized ad targeting and engagement metrics. You can't explain your work without corporate euphemisms.
After five years on Path Two, you've worked with a dozen municipal clients, built infrastructure deployed across hundreds of departments, and accumulated publicly visible contributions to permanent projects. You own a home in a city where that's still possible. You've developed expertise in distributed systems, mesh networking, and collective intelligence architecture. When you explain your work, people understand what you built and why it matters.
Which five years would you rather have on your resume? Which trajectory builds the career you actually want?
Learn More
Municipal Software Development:
Tech Worker Economics and Organizing:
Open Source Infrastructure:
Distributed Systems and Network Architecture:
Join the Municipal Infrastructure Movement
NTARI's municipal counter-automation strategy needs developers who understand clean room methodology, designers who can build Janus-facing interfaces that turn distributed observers into collective intelligence, translators who can maintain multilingual documentation, and strategists who can identify which monopolized software categories to tackle next.
If you're a tech worker who recognizes that the current industry trajectory serves neither workers nor communities, there's a practical alternative: building permanent public infrastructure that outlasts any individual company or funding cycle.
Join NTARI's Software Development Studio in our Slack workspace where we're building COER and planning the next counter-automation deployments. This is where clean room teams coordinate, where Janus-facing architecture gets designed, where mesh deployment strategies get tested, and where tech workers who want stable careers building meaningful infrastructure find each other: https://ntari.org/sds
Or support the research, development, and hardware manufacturing that makes cooperative municipal infrastructure possible. NTARI operates as a 501(c)(3) nonprofit—we answer to communities, not shareholders. Your contribution funds the work that creates stable, meaningful employment for tech workers while building infrastructure that serves the public: https://ntari.org/#give
The question isn't whether you'll continue working in tech. The question is whether you'll spend the next five years optimizing engagement metrics for platforms that extract value from users, or building collective intelligence infrastructure that serves communities. Both paths require the same technical skills. Only one builds the career—and the internet—you actually want.
Comments