Build vs. Buy in 2026: How AI Has Changed the Calculus for Internal Tooling

Table of Contents

The Blank Slate

I joined Amastra with a simple inheritance: nothing.

Well, to be fair, I had a Gmail account, but it was that and a dream. No time tracking system. No way to manage client engagements. No employee onboarding flow. No engineering tooling beyond what Google and the open source community provides.

For most CTOs stepping into this role, it’s overwhelming. For me, it felt like an opportunity to delve into that which I’ve missed - building.

The last time I had this kind of greenfield moment, I would have made very different decisions. I would have spent weeks evaluating Workday, BambooHR, Salesforce, toggl, Asana, Clockify, and a dozen other SaaS platforms. I would have built a requirements matrix, created a proof-of-concept evaluation plan, and likely chosen something with the brand recognition and “enterprise credibility” to justify the cost and inflexibility later.

But we’re not living in that world anymore.

In the span of my first few weeks at Amastra, I made a series of build/buy decisions that wouldn’t have made economic sense even twelve to eighteen months ago. And the shift isn’t some philosophical (or selfish) preference for building. It’s mathematical. It’s about leverage. It’s about how AI has fundamentally changed the equation for what it makes sense to build versus what it makes sense to buy. And that equation seems to be changing week-over-week or even day-over-day lately. (honestly, is anybody able to keep up with Google and Anthropic’s release notes recently? I’m trying to and it’s hard…)

The Old Mental Model

Let’s be honest about how this decision tree worked before:

Buy if:

The off-the-shelf solution is mature and battle-tested
The cost of building is higher than the cost of the license + operational overhead
Your requirements are standard and don’t need customization (or at least too much of it)
You want to avoid the hiring burden of maintaining custom software

Build if:

No solution exists
Every existing solution is missing ~40% of what you need
You have a team with excess capacity
Your requirements are so unique that customization won’t cut it

The problem with that model is that it forces false binary thinking. Most teams end up in the middle: buying something that solves 70% of the problem, then building custom extensions to fill the gaps. You get the worst of both worlds: license costs, operational overhead, external dependencies, and internal maintenance burden all at once.

The other problem is that “cost of building” was a high barrier. Building a time tracking system “properly” meant hiring someone, setting up infrastructure, designing schemas, building a UI, handling auth, managing data migrations. You’re looking at weeks of effort before you have something usable. Building an onboarding system meant even more: state machines, conditional logic, integrations with payroll and identity providers. I’d like to consider myself a fairly strong dev, but past me would still take months to build even POCs of these systems out if fully dedicated to it.

That calculus has shifted.

The Paradigm Shift: AI as Leverage and Economics

Here’s what changed: AI fundamentally altered both the velocity of building and the economics of small teams.

On leverage: A single engineer with proper AI tooling can prototype and ship internal tools that would have required a 2-3 person team two years ago. I’m not talking about toy projects. I’m talking about production systems handling real business logic, with proper testing, observability, and maintainability baked in from the start.

On economics: The cost of building custom tools has dropped precipitously. Where you previously needed to allocate a full-time engineer for weeks or a contractor for tens or hundreds of thousands of dollars, you can now iterate and ship in days for $10s or $100s of tokens. The operational overhead of maintaining custom software (monitoring, logging, alerting, deployment) has been commoditized. The cost of infrastructure is negligible and already has been trending this way through the past decade of Cloud - GCP, AWS, OCI, Netlify, Cloudflare… tons of generous free tiers to play with. The cost of the AI tools themselves is measured in dollars per week, not tens of thousands per month.

When you combine these two factors, the break-even point moves dramatically. There’s now a whole category of problems where building a simple, custom solution is cheaper than buying an inflexible enterprise tool. More importantly, it’s faster. And in a startup, velocity is often more valuable than perfection.

What We’ve Built, What We’ve Bought

Let me be concrete about the decisions we made thus far:

We bought: Google Workspace, a PAM solution for credential management, and a few other standard enterprise tools. These are commodity decisions. Workspace made sense because we’re Google-native (our entire security stack is built on GUS and Google Cloud), and there’s no competitive advantage in rebuilding email. The PAM solution is a mature, audited tool that handles compliance requirements we need.

We built: Time tracking, engagement management, and employee onboarding. Each of these started as a problem without a clean solution, and each is now a custom system tailored to how Amastra actually works, without any frill or fluff we don’t need.

Time Tracking

This started as an exploration in OSS options such as Kimai and Solidtime, both excellent open source options in the space. However, after noodling with both, each provided a rigid structure that was extraneous to our needs and not malleable enough without frankly re-writing large portions in a fork.

The key insight here was that time tracking isn’t actually a complex problem; it’s just that most SaaS solutions or OSS alternatives bundle 50 features you don’t need. We needed: capture, simple reporting, Workspace integration, and tie-ins to our engagement system. That’s solvable in a week with the right approach.

Engagement Management

ERP has been a fascinating area to dive into. Systems like SAP or NetSuite are complex and expensive to the point of having extensive mythology and jokes around just how crazy their implementations can be. I also have experience in doing custom modifications/additions on Microsoft Dynamics 365 from an internship but don’t miss those days either.

This is where the leverage became obvious. We needed a system that understood our sales pipeline, tracked client projects through distinct stages, and created line items for billing. We needed a cohesive, API and AI-first interface to the brain behind the business— not to hand over client financials to an LLM, but to orchestrate our own internal data and workflows more intelligently. Every off-the-shelf solution we looked at forced us to think in their mental model, not ours. Building our own meant we could design the domain model to match our business logic exactly. Having clear, cohesive engagement archetypes specific to us is a huge aid on this front.

Employee Onboarding

Joining Amastra is something that I wanted to feel custom and personal. Rather than being thrown a Gmail and a dream as I was, I want every employee to have a curated experience specific to their role - with clear audibility and visibility for our leaders. Rather than logging into 13 different portals and managing items between personal and professional accounts with half-baked integrations depending on payroll, identity, tech assets, trainings, etc., I wanted a “single pane of glass” (I know, I know… I hate myself using the phrase too) to keep things simple.

Onboarding is procedural and state-driven. That makes it perfect for a custom system. You want clear ownership, transparency into what’s happened and what’s pending, and integrations with your specific tools (Workspace, identity provider, HR systems, etc.). Most off-the-shelf onboarding tools are designed for large enterprises with 47 approval gates and complex compliance workflows. We needed something simpler and more tailored.

The Technical Foundation: AI Agent Management

Here’s where the AI leverage became concrete for me. Building these systems wasn’t cheap because we hired brilliant engineers or shipped it offshore. It was efficient because we applied patterns and practices that maximize AI assistance while maintaining quality standards.

This deserves its own detailed exploration, but here’s the executive version of what’s made this possible:

Test-Driven Development with AI

I approached internal tooling the same way you’d approach a security-critical system: tests come first. Not because it’s a best practice (it is), but because it’s the only way to keep AI-generated code trustworthy at scale.

The pattern I follow:

Design a detailed implementation plan collaboratively with a more “creative” model, oftentimes Gemini 3.1 Pro of late
Review that implementation plan with a stronger coding agent and suggest changes iteratively (both human and AI suggestions) with something like Sonnet 4.6
Transition to define the desired behavior in tests. Clear, explicit, narrow test cases.
Generate implementation code using those tests as the spec.
Run evals against the tests to verify correctness.
Iterate on the implementation until evals pass.

This removes most of the “AI hallucination” problem. The AI isn’t generating code in a vacuum; it’s generating code that passes tests you’ve defined. If the test is wrong, you find that out quickly. If the implementation is subtly broken, the test catches it.

Specifically for complex logic systems with many interdependent modules (onboarding, ERP), having grounded test cases was paramount in preventing code sprawl and “ghost in the machine” bugs as the systems scaled in complexity.

SKILLS.md and Agent Orchestration

Every piece of functionality, every integration, every workflow gets documented in a structured format. Not comments in code. A separate, detailed SKILLS.md file that describes:

What the system does and why it exists
How to use it (inputs, outputs, side effects)
Known limitations and assumptions
Examples of correct usage
How it integrates with other pieces

This serves two purposes:

First, it creates a knowledge repository that both AI and humans can reference. When building the next piece of functionality, the AI can read existing SKILLS.md files to understand the architecture and what’s already available.
Second, it forces clarity. If you can’t write clear documentation for a piece of functionality, the functionality itself probably isn’t clear. Honestly, I feel like the qualities of a good leader / people manager are laid bare in this process. The people that just push paper, delegate without direction, and shout to “plzfix” will have the same frustrations with an AI as they will with a human. Thoughtful, meaningful instructions with examples, do’s / don’t’s, and lessons learned from your own experience go a long way in making these frontier intelligence’s truly something special.

Lastly, don’t rebuild the wheel! There are many ingenious devs shipping a lot of excellent content in skills files of their own. One example of amazing content I found useful these past few weeks is Impeccable by Paul Bakaus.

Fleet Management and Model Delegation

I don’t use a single AI model for everything. Even if we’re a Google strike team here at Amastra, the frontier labs are shipping models and bespoke tooling around them each with their own strengths and weaknesses that deserve thoughtful consideration. I’ve been specifically using Anthropic and Google’s models, as they have built different tools optimized for different tasks. And since GOOG owns some of Anthropic… it’s not really cheating on Google… is it??

For rapid prototyping and exploration, I use Gemini Flash predominantly. It’s fast, cheap, and good enough for “let me brainstorm this thing” thinking. Similarly, for fast updates to existing code bases (where it’s just a little bit too complex for a regex find/replace in the IDE, but not enough that you really need to think to do it), Flash or even Haiku have been awesome.

For all creative thinking, design, and system planning that stitches across disparate modalities, Gemini Pro has really shone bright.

For core system logic, I use Claude Sonnet as my primary workhorse (and occasionally Opus for genuinely hard problems). Initial builds off of a spec are usually Opus. The quality difference is noticeable when it matters.

For certain types of tasks (data transformation, integration code), specific models consistently outperform others depending on the scaffolding in place. However, this seems to seriously change day-by-day depending on the latest release within Claude Code or Antigravity. It’s gone from Flash, to Haiku, to Gemini Pro, to Sonnet. The key here has been our Amastran principle of Fail Fast, Pursue Obsessive Mastery, which means we strive for continuous improvement and execute necessary failures quickly to maximize learning and enable rapid iteration. In this case, it’s rapid prototyping on the latest release patch for ideal model harnessing.

The orchestration layer (my Google Keep scratch notes I’m slowly maturing into a more formal system) tracks which model performed best for which type of task. Over time, this will become a router that automatically delegates work to the most appropriate model. For now, manual routing with good notes has been sufficient. You’re not paying Opus prices for everything, but you’re also not using Flash when you need reliability for more complex thinking.

Note: interestingly and worth noting, there is such a thing as overfitting a model that is “too smart for its own good” to a simple problem. I’ve consistently ran into the issue where something like an Opus or Pro will overthink the problem at hand and change things I didn’t intend to.

Tool Integration and Hooked Execution

Across all of these model flavors, I find myself using 3 primary modalities:

Claude Code for terminal-based execution and iteration
Gemini CLI for similar work to Claude Code but with a new token quota to burn against
Antigravity as the always-open IDE for human updates to code as agents work (and with great harnessing / orchestration of agents for updates within its interface directly as well)

Custom webhooks get used for synchronization and cross-system communication, but I’m still exploring how to make the most of this layer.

This is where true leverage emerges. The AI isn’t writing code that a human then runs. The AI writes code, deploys (sandboxed!), monitors the results, and iterates. You’re compressing the build-deploy-test feedback loop from hours to minutes.

Evals and Continuous Verification

None of this works without rigorous evaluation, same as if you shipped code off to human teams to write in isolation. I run evals at multiple levels:

Unit-level: does the generated code pass its own tests?
Integration-level: does the system work correctly with other components?
Deployment-level: are we seeing errors? Are latencies acceptable? Is the behavior correct?

The important shift here is that evals aren’t something you run once before shipping. They’re continuous. Every time you regenerate or improve a system, you’re running the full eval suite. It’s cheap to do (microseconds for most evaluations), and it catches regressions immediately. Plus, the best part - you can make AI help write these too!

The Insight: Prototype Before Planning

The outcome of all this is surprisingly simple: it’s now cheaper and faster to prototype and build than to obsessively plan.

The old waterfall thinking was: spend weeks defining requirements, evaluate solutions, make a decision, commit to it, then live with the consequences.

The new thinking is: spend half a day scoping the problem, one to two days prototyping a custom solution, another half a day evaluating whether it works, and iterate from there.

You’ll make wrong decisions sometimes. But the cost of being wrong is low. You can rewrite a week-old system in a few days if you need to. You can’t rewrite a three-year commitment to the wrong SaaS platform without significant pain.

This isn’t a license to build without thinking. It’s a recognition that the cost of exploration has dropped so dramatically that thoughtful iteration beats careful up-front planning.

There’s more to explore here, particularly around how we’re using these internal tooling capabilities to build something that augments our engineering force at a deeper level. That’s future post material, and frankly, it’s where we’re deploying some genuine innovation that I want to keep close to the chest for a bit longer. But the patterns hold: test-driven development, SKILLS.md documentation, multi-model delegation, and hooked execution. Build the foundation right, and the leverage compounds.

A Word of Wisdom

AI is not a replacement for creativity, design, taste, or planning. It’s a tool for amplifying them.

I can build internal systems quickly with AI because I already know how to build systems. I know what good code looks like, what a reasonable schema looks like, what production-grade observability requires, what testing gaps matter and which don’t. When I’m working with an AI, I’m not abdicating those decisions. I’m using the AI to handle the mechanical work while I focus on the judgment calls.

Someone with zero software engineering experience could point an AI at a problem and get output. In fact, I have a number of non-technical family and friends that are shipping code that runs and meets their hobby needs! But they won’t get something that scales, something that’s inherently secure, something maintainable, or something operationally sound. They won’t know the difference between a system that passes tests and a system that’s actually correct. They won’t know what they don’t know. And that’s okay.

This applies across every domain where society is applying AI leverage. Design. Architecture. Strategy. Or for us in these examples - onboarding workflows, engagement modeling. The people getting the most value out of these tools are the ones who already knew how to do the job and are now using AI to multiply their output.

It’s the same story as every tool that came before. CAD didn’t replace architects; it made good architects 10 times more productive. Compilers didn’t replace developers; it made them faster. Cloud infrastructure didn’t replace ops engineers; it lowered the barrier for what one person could build alone. But in each case, the tool rewards mastery. Someone who knows what they’re doing with the tool can do remarkable things. Someone fumbling around with the tool produces mediocre results, sometimes faster.

AI is the same. It’s a force multiplier, not a substitute for thought. If you know your domain, you can wield these tools to move faster than your peers. If you don’t, you can generate plausible-looking garbage more efficiently. The gap between the two isn’t the AI - it’s the expertise.

That’s actually why I’m optimistic about this moment of paradigm shift that kicked off since the release of Opus 4.5 / Gemini 3 Pro in particular. It means the people who will win over the next few years won’t be the ones who can use AI best, but the ones who understand their domain deeply and can apply AI as a tool within that context. The craftspeople, not the prompt engineers.

A Framework for Your Own Decisions

If you’re sitting in a similar position (new CTO, blank slate, overwhelming choices), here’s a practical decision framework:

Build if:

The solution needs tight integration with your specific business logic or domain model
You want intimate familiarity with the code, ensuring the team (and AI) has documented knowledge of exactly how it works, without proprietary “black box” algorithms or support teams trying to explain behavior without technical depth
You have <40% feature overlap with existing solutions (meaning you’d need heavy customization anyway)
The problem is well-defined and testable
You have the capability / know-how to properly harness and guide AI development

Buy if:

The solution is commodity (email, identity, payments, compliance tooling)
The available offering is exactly what your business needs or the customization cost to get there is demonstrably low
Maintenance + build cost of custom > maintenance + customization + risk offloading benefit of off-the-shelf
Regulatory requirements or audit trails demand third-party separation
The problem is genuinely novel to you but not to your industry (dozens of mature solutions exist)
The vendor has a proven track record of quickly implementing feature requests or can implement your custom features prior to acquisition to win your business

The key shift: The “customization cost” calculation used to be where most decisions landed. With AI, that’s increasingly untrue. Customization, when it’s needed, is now often cheaper and faster than buying and then bolting on patches.

Also, to be clear, I am absolutely not saying SaaS is dead. Please for the love of God don’t go trying to vibecode your own EDR to save on Crowdstrike licenses. And just because we don’t need SAP or Salesforce doesn’t mean your organization doesn’t.

For everything else: take a week, build a prototype, run it for a sprint, collect data on whether it works. The cost of knowing is lower than the cost of guessing.

I’m genuinely curious if you’ve seen similar patterns in your organizations. Are you sitting on internal tools that were supposed to be temporary but are now core to operations? Have you found yourself building instead of buying something that conventional wisdom says you should have bought?

Reach out on LinkedIn or X if you’ve had similar experiences or want to compare notes. I’d rather learn from your experience than pretend I’ve figured this all out already.