The Build-or-Buy Question, Revisited

Why most organizations don't build their own software

The conventional wisdom about custom software development is that it's too expensive. It's a wisdom that has shaped how organizations buy technology for thirty years, and like most conventional wisdom, it's only partially right.

The cost was always real. Custom software historically required teams of senior engineers working for months or years, at rates only the largest organizations could absorb. But cost alone doesn't explain why the build-or-buy question got resolved against build so consistently, even for organizations that could have afforded it.

The deeper reason was dependency. Building meant becoming dependent on the people who built.

When a consulting firm wrote custom software for a client, that firm became, by default, the only group that fully understood how the system worked. The code was delivered. The documentation, often, existed. But the institutional knowledge — why was this designed this way, what does this module actually do, how do you safely change the database schema — lived in the heads of the people who wrote it. If they raised their rates, the client had limited leverage. If they moved on, the system became a liability.

This was the structural reason custom development was risky. Not just the price tag, but the dependency that came with it.

In 2026, that's no longer true. Or more precisely: it doesn't have to be.

What AI-assisted development actually does

The first generation of AI coding tools — GitHub Copilot, Amazon CodeWhisperer, similar autocomplete assistants — produced measurable but modest productivity gains. A peer-reviewed study published in Management Science in 2026, drawing on three field experiments with nearly 5,000 software developers at Microsoft, Accenture, and a Fortune 100 manufacturer, found that developers with access to GitHub Copilot completed roughly 26% more tasks per week than the control group ¹. GovTech Singapore, applying the same tools across public-sector projects, reported productivity gains of 21–28% ². A separate longitudinal case study at Norway's NAV IT, the technology division of a large public-sector agency, observed that Copilot users were consistently more active than non-users on commit-based activity metrics ³.

These numbers describe the autocomplete era. They are not the gains available in 2026.

What's now in production use is qualitatively different. Agentic AI development tools — the generation that emerged through 2024 and matured through 2025 — don't suggest completions. They read entire codebases, plan multi-file changes, write code, run tests, debug failures, and iterate until the work is finished. A senior engineer using these tools isn't typing faster. They are directing scope that previously required a team.

Rigorous productivity measurements of the agentic generation don't yet exist at the scale of the autocomplete-era studies. The tools are too new; the kind of field experiment that produced the published numbers takes years to design, run, and peer-review. What's available now are smaller case studies, vendor benchmarks, and the lived experience of working engineers — all pointing in the same direction. The autocomplete-era numbers should be read as a conservative floor. The actual gains, in the hands of senior engineers working on well-scoped problems, are substantially larger and growing month over month as the tools improve.

One finding from the autocomplete era is worth carrying forward, because it is even more true with agentic tools. The same Management Science study, along with subsequent research, found that productivity gains accrue most strongly to less-experienced developers. Separate research on open-source projects has documented a related effect: when AI-assisted code volume increases, experienced developers spend more time reviewing contributions from less-senior teammates, and their own original-code productivity decreases ⁴.

In other words: AI doesn't make senior engineers faster. It makes less-experienced engineers more productive, and shifts the bottleneck onto senior judgment.

This is the version that matters. The value of a senior team in 2026 isn't typing speed. It's the architectural decisions, the security questions, the maintainability choices, and the careful review that makes AI-generated code production-ready. AI multiplies what a small senior team can deliver, precisely because the senior judgment is doing the work AI cannot.

The compound effect, on a focused team, is substantial. Combined with modern practices that make custom software actually handoff-able — automated testing, comprehensive documentation, AI-assisted CI/CD — it changes what's possible for organizations that previously couldn't afford to commission systems built around how they actually work.

How this changes the build-or-buy calculation

The cost economics matter, but they're not the headline.

For most of the last three decades, organizations facing the build-or-buy question got two answers from the math. Off-the-shelf software was modest in cost but came with hidden friction: the months of training, the workflow compromises, the permanent drag of doing things the vendor's way instead of the way that actually worked best for the organization. The license cost was visible. The hidden costs were absorbed quietly, year after year, line item by line item.

Custom software fit the work. It eliminated the adoption friction. But it was expensive, slow, and — most importantly — created the dependency problem described above. For most organizations, buy was the rational choice almost every time. The math was the math.

Two things have changed.

The cost side has fallen substantially. A focused senior team using modern AI tooling can deliver custom-fitted software at a fraction of the historical cost. Not at off-the-shelf prices, but in a range that's now accessible to mid-sized organizations and serious public agencies.

More importantly, the dependency problem is solvable — if you design for it from day one. The pieces are well-understood, but they have to be built in deliberately:

The source code belongs to the client, in the client's version control, under the client's account. There is no vendor escrow, no conditional release language, no scenario in which the client doesn't have the code.

The documentation is comprehensive enough that someone who didn't write the system can read it and understand the architecture. Not API references generated by tooling, but actual explanations of why the system was built the way it was, what the trade-offs were, and what to look out for.

The automated tests cover the system thoroughly enough that future changes can be made with confidence. When a maintenance engineer modifies a function, the tests tell them whether they broke something. This is what makes a codebase actually maintainable rather than nominally maintainable.

The CI/CD pipeline is configured so that the client's team can ship updates without help from the original vendor. The same automation tools that built the original system are documented and operable by anyone with reasonable engineering literacy.

And critically, in 2026, the AI-assisted maintenance workflows that made the original build affordable are also available to the client's engineers. A future maintenance change that would have required hiring a senior contractor for a week can now be done by a more junior engineer, with AI assistance, in an afternoon.

This last point is what changes the dependency calculation entirely. It's no longer the case that "we built it so we own you." A well-architected codebase, with comprehensive documentation, automated tests, and AI-assisted maintenance workflows, can genuinely be handed off. The institutional knowledge lives in the artifacts, not in the people.

This is what your software, your code, your team's to maintain actually means when said honestly. It's not a slogan. It's a discipline that has to be built into every project from the first commit.

The thirty-year-old build-or-buy tradeoff has, for the first time, become a real choice for organizations of moderate scale. Not just because custom is cheaper, but because custom no longer means dependency.

What to ask before you commission custom software

The dependency-free approach is straightforward to describe and surprisingly hard to verify. Plenty of consultancies will say all the right things about source code transfer and documentation, then deliver work that quietly preserves the old dependency dynamic. The questions below are the ones that distinguish a vendor who genuinely transfers ownership from one who only says they do.

Where will the source code live during development? A vendor who answers "in our repository, and we'll deliver it at the end" is preserving optionality for themselves. The right answer is in your version control system, under your organization's account, from the first commit.

Who can read and understand the documentation? Ask to see a sample of documentation from a previous project. If it's auto-generated API references, that's not documentation — it's code prettified. Real documentation explains decisions, trade-offs, and the things a future engineer needs to know that aren't visible from the code itself.

What test coverage will be in place at handoff? "We test our code" is not an answer. The answer should be a specific approach: unit tests for business logic, integration tests for system boundaries, an explicit coverage target, and the test suite delivered alongside the code so your team can run it themselves.

Who operates the CI/CD pipeline after handoff? If the vendor is the only party who can deploy code changes, the dependency problem hasn't been solved — it's just been moved to a different layer. The pipeline should be documented, runnable by your team, and not dependent on credentials or accounts the vendor controls.

What does the maintenance handoff actually look like? A handoff is not a Zoom call and a binder. It's working sessions where your team makes real changes to the code, ships them through the pipeline, and demonstrates they can do so without the vendor's help. If the vendor doesn't propose this kind of explicit transfer, ask them to.

These questions are simple, but they reliably separate vendors who have internalized the no-lock-in commitment from those who treat it as marketing language.

Why this matters for Guam specifically

For most of the last three decades, building custom software was effectively out of reach for Guam's local agencies and businesses. Off-the-shelf software was either ill-fitted to local needs or built for markets that didn't include territories. Mainland firms quoted six- and seven-figure budgets for purpose-built solutions. The choice, again and again, was to live with what was available — or to do without.

This is why so many of Guam's local agencies and businesses operate, today, on systems that were deemed outdated decades ago. The math never worked out for them to commission something custom. The window during which a focused local team could deliver modern systems at accessible cost simply didn't exist.

That window now exists.

Guam is a small place. That sentence is sometimes used as a constraint, a limit on what's possible, and it is in some respects. But in 2026, it is also an asset.

Transformations that take a decade in a mainland state can happen in eighteen months here. The same property that made Estonia the world's most digitally-advanced government — being small enough to actually transform — applies to Guam. Estonia's population is roughly 1.3 million, about eight times Guam's ⁵. By December 2024, every Estonian state service had been digitized; residents file taxes, vote, register companies, and access medical records through a unified digital identity system ⁶. This wasn't accomplished by hiring Big Four consultants for a decade. It was accomplished by deciding, at a national level, that information infrastructure was a strategic priority, and then building it with focused, small teams over a manageable horizon.

Guam isn't going to replicate Estonia. But Guam has the property that makes Estonia's outcome possible: small enough scale to actually move. A single department's worth of system replacement here is a single department; in California, the same change would touch ten thousand stakeholders.

The opportunity this creates is specific. The U.S. Department of the Interior's Office of Insular Affairs administers technical assistance, capital improvement, and discretionary funding programs that are specifically available to Guam, American Samoa, the U.S. Virgin Islands, and the Northern Mariana Islands ⁷. Other federal agencies — HHS, Treasury, Commerce — administer programs with set-asides for U.S. territories. Some of these go partially uncaptured year after year, not because the funds aren't available, but because the institutional capacity to track applications, manage reporting requirements, and coordinate across agencies isn't there. When a Guam agency operates on twenty-year-old database software and tracks federal program eligibility in spreadsheets and email threads, it is not failing. It is doing its job with the tools it has. But the tools are limiting what's possible.

Modern information systems would change that. Not by replacing the people doing the work, but by giving them visibility into what they're already doing, in time to act on it. A grant management system that surfaces upcoming deadlines. A reporting pipeline that aggregates data from multiple programs into a single dashboard. An inter-agency information-sharing layer that doesn't require people to email PDFs back and forth. These aren't aspirational systems. They're the basic infrastructure of every well-run modern public organization, and they have been historically out of reach for Guam's agencies.

That is no longer the case.

What it would actually take

The easy version of this argument elides the hard parts.

Capturing this opportunity requires local presence, sustained over years. Mainland firms cannot do this work. They can be hired for specific engagements, but they cannot be the partner an agency calls when something breaks at 2 AM, or when a new federal program is announced and there are six weeks to apply. The systems built in 2026 will need to be maintained, updated, and adapted in 2028, 2030, and 2035. The organizations capable of doing that work are organizations that are here.

It requires senior judgment, not just AI-assisted volume. The productivity multiplier is real, but it amplifies the quality of the engineer using it. Bad architecture assisted by AI is bad architecture, faster. The work that creates value is the work of deciding what to build, how to structure it, and what compliance and security questions to surface. That is the work of someone who has done it before.

It requires honoring the no-lock-in commitment as a discipline, not a slogan. Real source code transfer. Real documentation. Real test coverage. Real CI/CD that the client can operate. Real training. It means designing every project so that the consulting firm could disappear tomorrow and the client would still have a working, maintainable system. Not every consulting firm operates this way. The ones that do are operating against the short-term incentive to keep clients dependent. It is a deliberate choice, and it has to be visible in the actual deliverables.

And it requires working with organizations as they are, not as one wishes they were. Guam's agencies and businesses operate in specific political, regulatory, and fiscal contexts. The work isn't to impose mainland best practices on them. The work is to listen carefully, understand the constraints, and build systems that fit. Sometimes that means a less ambitious system that the team will actually adopt, rather than a more ambitious one that gets shelved.

These conditions aren't unique to SK102. Any organization that wanted to do this work seriously would face the same requirements. They are, however, conditions worth taking seriously, because they describe what it actually takes to make this work mean something for Guam.

What's possible from here

If a meaningful number of Guam's agencies and businesses commissioned modern, well-fitted information systems over the next five years, the cumulative effect would be substantial. Not because any single system would transform the island, but because the aggregate visibility — into costs, into compliance, into program eligibility, into the data that decisions actually depend on — would compound. Better information, deployed across enough organizations, makes better decisions possible.

This is not an argument that depends on optimism about technology. It is an argument about the unit economics of a specific kind of work, applied to a specific place, at a specific moment when the math has finally changed.

The systems that Guam's organizations have been told they can't afford are now within reach. Whether that opportunity is captured depends on choices made over the next several years — by the agencies and businesses considering modernization, and by the local technology firms committing to the disciplines that make modernization durable.

The simplest first step, for any organization considering this work, is a conversation. SK102 can be reached at info@sk102.co. No pre-packaged pitch, no expectation of commitment.

— Samuel S. Kim, Founder, SK102 LLC. Tamuning, Guam · April 2026.

Notes

The productivity research cited above describes the autocomplete-era of AI coding tools (GitHub Copilot and similar IDE-integrated suggestion systems). It serves as a conservative floor for understanding what AI-assisted development can do; the agentic-tool generation now in production use produces substantially larger gains, though rigorous field experiments at comparable scale are still being conducted and peer-reviewed.