Build or Rent? When AI-Built Internal Tools Should Replace Your SaaS

Why This Question Landed on Your Desk This Year

A year ago, an office manager who wanted a custom intake form, a matter-tracking dashboard or a contract-renewal tracker had two choices. They could rent another SaaS subscription or ask a developer for a quote. Now there is a third choice. Someone on staff opens an AI coding assistant, describes the tool in plain English and has a working prototype by the afternoon. Business press has taken notice, with recent coverage arguing that small business owners are renting software that AI could build in hours, and with reporting that AI spending is becoming very hard for businesses to budget.

Both stories are true, and that is the problem. The prototype really is quick to build. Owning it costs more than it seems. This post is for the owner, managing partner or operations lead who has to decide which subscriptions to cut and which internal tools to build. It also covers what has to be in place before anything AI-built touches client data.

Our short answer is that you should build narrow, internal and low-blast-radius tools. Keep renting anything that holds regulated data, moves money or serves as a system of record. Whatever you build needs an owner, an identity provider and a security review before it goes live.

What AI Coding Tools Are Actually Good At, and Where They Fail

Adoption is no longer the question. In the Stack Overflow 2025 Developer Survey, 84% of respondents said they use or plan to use AI tools in their development process. The same survey found that more developers distrust the accuracy of AI output than trust it. People who write code for a living use these tools and check the output carefully.

Productivity gains are also less certain than the demos suggest. A randomized controlled trial by METR found that experienced open-source developers took 19% longer to finish tasks when they used AI tools. Those developers had expected the tools to speed them up. The study measured skilled engineers on large, mature codebases, which is a different situation from a staff member building a small form app. The lesson still carries over, because building feels faster than it is and the cost shows up later in debugging and maintenance.

In our experience, AI-built tools tend to work well in these cases:

• Single-purpose internal utilities such as a conflict-check lookup form, a PTO request tracker or an internal FAQ search.
• Glue between systems you already own, such as moving data from a Microsoft Form into a SharePoint list and alerting a Teams channel.
• Reporting and dashboards over data you already export.
• Throwaway prototypes that help you decide what to buy.

They tend to fail in these cases:

• Anything that needs real authentication, role-based permissions or audit logging.
• Anything that stores or processes regulated or privileged data.
• Anything that handles payments, trust accounting or payroll.
• Anything that needs to keep working after the person who built it leaves.

The Security Bill Comes Due After Launch

The strongest argument for caution is the security record of AI-generated code. Veracode’s 2025 GenAI Code Security Report tested code from more than 100 large language models. It found that 45% of the code samples introduced a security flaw from the OWASP Top 10, the industry’s standard list of the most critical web application risks. A non-developer who ships that code has no practical way to tell whether their tool falls into that 45%.

The breach data points the same way. IBM’s Cost of a Data Breach Report 2025 puts the average US breach cost at $10.22 million. It also found that breaches involving shadow AI, meaning AI tools used without IT’s knowledge or approval, cost organizations noticeably more on average. Of the organizations that reported a breach of an AI model or application, 97% lacked proper AI access controls. A tool built over a weekend and hosted on someone’s personal cloud account fits that description exactly.

The Verizon 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled to 30%. That number cuts both ways. Renting SaaS adds vendor risk, which is one reason building looks attractive. A homegrown tool, however, has no vendor security team, no SOC 2 report and no one patching it at 2 a.m. You become the vendor and take on all of that work.

Build vs. Rent vs. Managed Build: Side-by-Side

Most businesses are really choosing among three options. Staff can build the tool themselves with AI, the business can keep renting SaaS, or the business can have a tool built and run under an IT partner’s governance.

Factor	Rent SaaS	Staff-Built with AI	Managed Build (IT/AI Ops Partner)
Time to first working version	Fast if a product fits	Fastest	Moderate
Fit to your exact workflow	Generic; you adapt to it	Exact	Exact
Security review before launch	Vendor’s responsibility; verify with SOC 2 or ISO 27001 reports	Usually none	Built in
Identity and access (SSO, MFA, offboarding)	Usually supported	Often missing or improvised	Tied to Microsoft Entra ID or your existing identity provider
Patching and dependency updates	Vendor handles it	Nobody, unless someone is assigned	Scheduled and monitored
Survives the builder leaving	Yes	Often no	Yes, with documentation
Compliance evidence (audit logs, data maps)	Vendor provides some	Rarely exists	Produced as part of the build
Cost profile	Predictable recurring subscription that grows with seats	Low up front, unpredictable later	Higher up front, predictable to run
Vendor lock-in	High	None	Low, because you own the code
Best for	Systems of record, regulated data, payments	Prototypes and personal productivity	Internal workflow tools that touch business data

In practice, most firms end up with a mix of all three. The mistake to avoid is a staff-built tool quietly becoming a system of record without anyone deciding that it should.

A Five-Question Test for Every Tool on Your List

Run every SaaS renewal and every build idea through these five questions. If any answer is yes, keep renting or use a managed build. Staff should not build that tool alone.

1. Will it store or process confidential client data, personal information or privileged material? If it will, it falls under your confidentiality and privacy obligations, covered below.
2. Does it move money or affect financial records? Billing, trust accounting, payroll and vendor payments should stay on established platforms with audit trails.
3. Will people outside your organization use it? An external-facing app is open to attack from the whole internet, and the OWASP flaws Veracode measured become exploitable.
4. Would losing it for a day stop billable work? If so, it needs backups, monitoring and an on-call owner, and an AI prototype has none of those.
5. Is there exactly one person who understands it? If so, you are holding key-person risk, not owning software.

If all five answers are no, a staff-built tool is a reasonable choice, provided it meets the guardrails described later in this post.

The California and Professional-Responsibility Layer

For LA firms, and for law, entertainment and professional-services firms in particular, the build decision is also a compliance decision.

California privacy regulations. The California Privacy Protection Agency finalized regulations covering cybersecurity audits, risk assessments and automated decision-making technology in 2025, and the obligations phase in from 2026. If your business meets the CCPA thresholds, any new tool that processes personal information has to fit into your data inventory and risk-assessment process. An undocumented internal app is exactly the kind of gap an audit uncovers.

Attorney ethics. The American Bar Association’s Formal Opinion 512 says lawyers using generative AI must account for competence, confidentiality, communication and reasonable fees. The State Bar of California’s practical guidance on generative AI also warns against entering confidential client information into AI tools that lack adequate confidentiality protections. These rules apply to the coding assistant and to the tool it builds. If a paralegal pastes real matter data into a public AI service to debug an app, that is a confidentiality problem regardless of how good the app turns out to be.

Entertainment and production data. Unreleased scripts, talent contracts and deal terms are commercially sensitive even when no statute covers them. Apply the same five-question test to them.

Minimum Guardrails Before Any AI-Built Tool Goes Live

If a tool passes the five-question test, it still needs these controls before anyone relies on it:

• Use company accounts only. Build and host the tool on business-owned tenants such as Microsoft 365, Power Platform or Azure. Never use personal GitHub, Vercel or Google accounts.
• Sign in through your identity provider. Users log in with Entra ID or your current SSO and MFA, so the tool is covered when you offboard an employee.
• Use no real client data while building. Work with synthetic or redacted data until the tool has been reviewed.
• Have a second person review the code. Ideally that reviewer checks it against the OWASP Top 10. If the tool calls an LLM, also check it against the OWASP Top 10 for LLM Applications, which covers prompt injection and data leakage.
• Assign a named owner and a backup owner, and record both in your IT documentation.
• Track dependencies. Know which libraries the tool uses and who will update them. NIST’s Secure Software Development Framework (SP 800-218) is the reference model, and CISA’s Secure by Design principles explain why the builder is responsible for security.
• Decide on retirement up front. Set a review date when the tool either becomes a managed asset or gets shut down.

What to Do This Quarter

1. Export your SaaS renewal list for the next 12 months and note who uses each tool and what data it holds.
2. Run the five-question test on each subscription. Most systems of record will stay rented, and some narrow single-purpose subscriptions may turn out to be easy to replace.
3. Find the shadow tools already in use. Ask department leads what people have built or connected on their own. Shadow AI is far easier to govern once you know it exists.
4. Publish a short AI build policy that lists approved platforms, bans client data in public AI tools and requires review before launch.
5. Pilot one internal tool under the guardrails above, and measure how long it takes to maintain as well as how long it took to build.

The businesses that benefit from this shift treat AI-built software as real software. It gets an owner, sign-in through the identity provider, a security review and a retirement plan.

We Solve Problems runs both managed IT and AI operations for clients across Los Angeles and the US, so we handle the build-or-rent decision and the security work that comes after it. We help clients find the manual workflows worth automating, build those tools on infrastructure they own and secure them alongside Microsoft 365 and the rest of their environment. We have particular depth with entertainment-law and professional-services firms. If you are about to renew a stack of subscriptions or have already found a few homegrown tools, talk to us before you decide.