It starts innocently enough. Someone inside the organization has an idea for an application that would solve a frustrating problem. Maybe it would replace a cumbersome spreadsheet, streamline an approval process, or give clients a better way to submit information.
A few years ago, the idea might have stalled as soon as someone asked what it would cost to build. Now, with tools such as Claude Code and Codex, a moderately technical person can create something functional over a weekend.
By Monday morning, there's a working application. It looks surprisingly good. People can click through it. The basic workflow works. Leadership begins to wonder why the organization should spend tens or hundreds of thousands of dollars on a commercial platform when someone has apparently built an alternative in two days.
It's a fair question. AI-assisted development really has changed what organizations can build, how quickly they can test an idea, and who can participate in the process.
But a successful weekend project only answers the first – and usually, the easiest – question: Can we make this work?
The harder question to answer is whether the organization should build it, especially once people begin to depend on it.
Some applications can afford to be imperfect
Not every application needs enterprise-level infrastructure, around the clock support, or an elaborate governance model.
Someone might build a small internal tool that saves a team a few hours each month. If it stops working for a day or two, employees can return to the spreadsheet or the manual process they used before. If the tool is eventually abandoned, the loss may be annoying, but it's unlikely to create a crisis.
That can be a great use of AI-assisted development. The cost is limited, the risk is manageable, and the organization gains something useful without making a major investment.
The calculation changes when the application supports a critical business process, becomes the place where important information lives, or is used by customers, clients, donors, grantees, patients, research participants, or business partners.
If an internal productivity tool is unavailable for a few days, the organization may be inconvenienced. If a client-facing portal prevents people from submitting time-sensitive information, exposes confidential data, or produces unreliable records, the consequences are entirely different. The stakes also rise when an application contains regulated data, creates official records, or must meet security, privacy, accessibility, or records-management requirements.
Software has a way of becoming important gradually. A useful experiment gains more users. More information is added. Someone connects it to another system. The original workaround is retired. Before long, the application that began as a weekend project is now part of the fabric of the organization and how it operates.
By then, walking away from it may no longer be easy.
The real question is whether the organization wants to own it
When organizations compare buying and building, they often put the price of a commercial product next to the apparent cost of producing the first version of a custom application.
That comparison has always been incomplete. AI has made it even more misleading.
The cost of generating the initial code may now be quite low. The cost of owning the resulting application has not disappeared.
Depending on the system, ownership may include:
- Hosting, monitoring, backups, and recovery
- Identity management, access controls, and security testing
- Privacy, compliance, and records-management requirements
- Data architecture and integration maintenance
- Quality assurance and testing
- Documentation, training, accessibility, and user support
- Enhancements and changes to underlying models, frameworks, libraries, and services
- Continuity, migration, and eventual retirement
AI can help with many of these activities. It can diagnose problems, generate documentation, and support future changes. But most of the difficult decisions involved in maintaining organizational software aren't purely technical.
Someone still needs to decide which changes to make, what to prioritize, and which requests to decline. Someone needs to understand the business processes well enough to recognize when the application is producing the wrong outcome, even if the code is running properly. A human must be accountable for security, data quality, testing, documentation, support, and continuity.
These responsibilities may seem manageable during the early days, but it gets increasingly challenging over time. The original builder leaves, changes roles, becomes consumed by other priorities, or loses interest in a project that was never really part of their job. An integration changes. A library is retired. A security issue emerges. Users ask the application to support processes that were never contemplated in the original design.
At that point, the organization may still have working software without having a sustainable product.
Building the first version is also a commitment to years of ownership. Leadership should understand what that commitment will require before the application becomes part of how the organization operates.
Technical debt is rarely only technical
We regularly help organizations untangle systems that have become expensive and difficult to change. In most cases, the code itself is only part of the problem.
Over time, the system has accumulated undocumented business rules, inconsistent data, one-off exceptions, manual workarounds, and integrations that no one fully understands. Employees adjusted their work to accommodate the platform. Critical knowledge about how it operates may be concentrated in one or two people.
Replacing the system usually begins with reconstructing how the organization’s own processes actually work—before anyone can make a sound decision about new technology.
Which steps are truly necessary? Which were created to work around a limitation in the existing system? Why does one department handle the same information differently from another department? What version of the data can be trusted? What needs to be retained, migrated, archived, or discarded?
The is where the weekend-project math begins to really fall apart.
The original application may have been inexpensive to create. Several years later, the organization may spend a substantial amount of money redefining business processes, cleaning up information, documenting requirements, rebuilding integrations, and managing a transition to something more sustainable.
What looked like technical debt has become organizational debt.
Buying software doesn't make these problems disappear
Commercial, off-the-shelf platforms come with their own risks and frustrations. They can be expensive, overly complicated, poorly implemented, or badly matched to the organization's needs. Vendors raise prices, discontinue features, and make product decisions that might not align with every customer's priorities.
Organizations can also make a commercial platform nearly impossible to maintain by customizing it around every preference, exception, and historical process. Buying a platform does not relieve leadership of responsibility for requirements, governance, data, security, adoption, or business-process design.
Part of the value of a commercial platform is having a vendor manage areas such as infrastructure, routine maintenance, security engineering, product testing, technical support, and continued development on behalf of many customers.
Sometimes that's well worth the licensing cost. Sometimes it's not. The point is to compare the real tradeoffs, rather than comparing a multi-year commercial contract with the cost of generating the first version of an application.
Buy versus build is not a binary decision
Most organizations have more than two choices.
The might purchase a commercial platform and use it largely as designed. They might configure the platform around their terminology and workflows. They might build a few integrations or specialized components while keeping core information in an established system. They might create a small application that helps employees interact with several existing platforms more efficiently.
This middle ground is one of the most promising uses of AI-assisted development.
An organization may not need to build its own CRM, grantmaking platform, document management system, or customer portal. It may benefit enormously from building a focused tool that fills a genuine gap around one of those systems.
There's a meaningful difference between building an application that helps someone complete a task and building the authoritative repository for the underlying information. There's a difference between automating a low-risk internal workflow and creating the interface through which clients submit confidential data.
In many cases, the best decision may be to keep core records in a stable commercial platform while selectively building the workflows, interfaces, or automations that make it more useful.
There's another option that technology conversations too often overlook: simplifying the business process(es).
If a commercial product supports 85% of what the organization needs, it's worth asking whether the remaining 15% represents a genuinely important requirement. Sometimes it's necessary, but frequently it consists of variations and exceptions that have accumulated over the years and shouldn't be reproduced in a new system.
A custom build can preserve or handle almost any process, but that doesn't mean that process should continue to exist.
Questions executives should ask
Executives don't need to evaluate code or choose the technical architecture for a platform. But they should make sure their organization is considering the full lifecycle of the proposed application.
Before deciding to build, leadership should ask these questions:
- What would happen if this application were unavailable for a few hours, a few days, or permanently?
- Who will use it, and what information will it contain?
- What security, privacy, accessibility, retention, contractual, or regulatory requirements apply?
- Is this capability genuinely distinctive, or are we recreating functionality that established products already provide?
- Are we evaluating the cost of creating the first version or the cost of owning the system for the next five years?
- Who will be accountable for product decisions, maintenance and continuity if the original builder leaves?
- Could we meet most of the need by configuring an existing platform, building a smaller complementary tool, or simplifying the process?
- Are we choosing to build because it is the best long-term decision, or becomes producing the first version suddenly looks inexpensive?
The goal is to make the best decision with a clear understanding of which responsibilities the organization is taking on and who will manage them.
Look beyond the initial build
AI-assisted development gives organizations options that would have been unrealistic only a few years ago. Small and mid-sized organizations can now create useful tools, test ideas, and solve specialized problems without assembling a traditional software development team. That's a significant opportunity.
It's also possible to build something much faster than the organization can develop the governance, skills, and operating practices needed to sustain it.
The most important part of the buy-versus-build decision comes after the demo, when everyone has seen that the idea can work. Leadership must consider what happens when the application contains important information, supports daily operations, accumulates integrations, and becomes something people can't easily work without.
The prototype may take a weekend, but the organizational commitment can last for years.
