Sure, AI Can Build It. Good Luck With That.

Fine. Let’s Say You Build It.

Ask any AI coding assistant to build you a text-blast app for your members, and it will happily oblige before your coffee gets cold. It’s the question we hear on almost every call: couldn’t we just build this ourselves with AI? A scrappy team with a laptop and a chatbot really can spin up something that pings people’s phones by Friday — that part’s not in dispute. What’s in dispute is what happens after Friday. “We built something that works” and “we’re running a member communication program that still works in three years” are very different sentences, and the fun part is exactly where they stop overlapping. Nobody demos the part where the app quietly breaks six months later, and nobody notices for a week.

The Build Is the Fun Part. Everything After Is the Bill.

Here’s the part that never makes it into the demo: decades of software engineering research say the build itself is the cheapest, easiest, most satisfying chunk of a software project’s whole life — and everything after it is where the real spending happens. A 1981 survey of 487 organizations found that maintenance already ate up more than half of all software staff time, back when “maintenance” meant fixing a mainframe report, not fighting an iOS permissions update.¹ Later estimates put lifetime maintenance costs as high as 90 percent of a system’s total cost.² And this isn’t ancient history: a 2020 McKinsey survey of enterprise CIOs found that 10 to 20 percent of the budget earmarked for new products gets quietly redirected to fixing existing systems instead, with accumulated “tech debt” amounting to 20 to 40 percent of the value of the entire technology estate.³ Separately, a global survey of more than 1,000 developers by Stripe found they spend roughly 42 percent of their working week — about two full days — dealing with technical debt and bad code, adding up to an estimated $300 billion a year in lost productivity worldwide.⁴ Translation: the app your team builds this weekend isn’t the project. The project is what happens eighteen months from now, when the push-notification API changes, a dependency quietly stops being supported, and the one person who understood the code has taken a new job and, understandably, stopped answering your Slack messages. Someone still has to own that, and “we’ll figure it out” isn't an ownership plan. And to be clear about the source of those numbers: that’s enterprise data, from teams with dedicated engineering staff and a maintenance budget line. A nonprofit team building this on nights and weekends doesn’t get a smaller bill — it just has nobody budgeted to pay it.

AI Is Great at Writing Code. It’s Less Great at Writing Safe Code.

This isn’t a knock on anyone’s coding skills — it’s a documented feature of the tools themselves, and it hasn’t gotten better with newer models. A 2023 Stanford study had people write code with and without an AI assistant, then checked the results for security holes. The AI-assisted group wrote consistently less secure code—and felt more confident about it than those who skipped the AI entirely.⁵ A separate study of GitHub Copilot found that about 40 percent of its generated code, across 89 test scenarios, had a potentially exploitable vulnerability.⁶ The problem hasn’t aged out, either: a 2025 study running 80 security-relevant coding tasks across more than 100 large language models found that 45 percent introduced a known vulnerability class, with newer models no more secure than older ones, and failure rates ranging from 38 percent in the best-performing languages to more than 70 percent in Java.⁷ And if that code causes a breach? GitHub’s own Copilot terms put the responsibility in writing: users “retain all responsibility for Your Code,” suggestions included — GitHub isn’t on the hook for what it helped write.⁸ So: fast, cheerful, and contractually not anyone’s problem but yours. Fine for a weekend hobby project. Less fine for something holding member names, contact details, and program eligibility data — the kind of thing a bad actor would very much like to have, and the kind of thing your organization would very much like to explain never got exposed.

Compliance Doesn’t Care How Proud You Are of Your DIY App

Different organizations answer to different rules here, but none of those rules get waived because you built the thing yourselves. Housing authorities operate under specific federal requirements — HUD’s own guidance tells PHAs to safeguard the personal information of the people they serve and to have an actual plan for when something goes wrong, consistent with the Privacy Act and the E-Government Act.⁹ Nonprofits and CBOs without a HUD looking over their shoulder still answer to funders, boards, and the people they serve — just with fewer footnotes. What doesn’t change across any of it is who’s on the hook when something breaks. A vendor-built platform usually comes with an independent security review and an incident-response plan, because a breach is the vendor’s problem too. A homemade app quietly hands all of that back to whoever’s still around to answer for it — typically with zero budget attached and zero time carved out for it. That doesn’t put anyone out of compliance by itself. It just means nobody’s checking your work but you.

What You’re Actually Buying

None of this is a case against AI, or against your team messing around with it — go build something fun on a Saturday. It’s a case for being honest about the difference between “building an app” and “running a program people are still using in year three.” That second part is what Patter COMPASS is built to carry across the nonprofits, CBOs, and housing authorities it works with — the maintenance, the security review, the compliance paperwork that never makes it into a demo, so it doesn’t get reinvented, department by department, every time the person who understood the code moves on. Build the fun thing on the weekend. Just don’t stake your member program on it.

Notes

1. Lientz, B.P. and Swanson, E.B. (1981), cited in Koskinen, J., “Software Maintenance Costs,” University of Eastern Finland (2015).

2. Erlikh, L. (2000), cited in Koskinen, J., “Software Maintenance Costs,” University of Eastern Finland (2015).

3. McKinsey & Company, “Tech Debt: Reclaiming Tech Equity” (October 6, 2020), based on a July 2020 survey of 50 CIOs at financial-services and technology companies with revenue above $1 billion.

4. Stripe, “The Developer Coefficient” (2018), a survey of more than 1,000 developers and 1,000 C-level executives conducted with Harris Poll.

5. Perry, N., Srivastava, M., Kumar, D., and Boneh, D., “Do Users Write More Insecure Code with AI Assistants?” Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS ’23).

6. Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., and Karri, R., “Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions,” 2022 IEEE Symposium on Security and Privacy (SP).

7. Veracode, “2025 GenAI Code Security Report” (July 30, 2025): 80 curated coding tasks tested across more than 100 large language models, evaluated with Veracode Static Analysis against the OWASP Top 10.

8. GitHub, “GitHub Copilot Product Terms” (accessed 2026): users “retain all responsibility for Your Code,” including any Copilot suggestions incorporated into it.

9. U.S. Department of Housing and Urban Development, Office of Public and Indian Housing, Notice PIH-2015-06, “HUD Privacy Protection Guidance for Third Parties” (April 23, 2015).