Build, Buy, Boilerplate or Ask the Agent?

Coding agents add a new option to an old software decision.

Roman Grigoriev, Founder, Udria13 September 20265 min read

Software teams have always made versions of the same decision.

Should we build this ourselves?

Should we buy a product?

Should we use an open-source library?

Should we start from a boilerplate?

Coding agents add another increasingly credible answer:

Ask the agent to build it.

That changes the economics of implementation, but it does not eliminate the trade-offs.

The useful question is no longer simply build versus buy.

It is:

Which parts of this capability should we own, which should we outsource, and which knowledge should we reuse?

Option 1: Buy the finished service

Sometimes the right answer is to buy.

Stripe is a good example.

Most SaaS companies should not create their own card network, acquiring infrastructure and payment-processing stack.

Buying is attractive when:

the capability is highly specialised;
operating it is expensive;
regulation or risk is substantial;
the provider's scale creates a genuine advantage;
custom implementation would not differentiate the product.

The trade-off is dependency.

You accept another vendor's:

API;
pricing;
availability;
constraints;
product decisions.

Often that is exactly the right trade.

Option 2: Build it yourself

Building remains appropriate when the capability is core to differentiation.

If your product exists because of a particular workflow, model or experience, delegating that entire capability to a generic third party may destroy the thing that makes the product valuable.

Building also gives:

control;
flexibility;
ownership;
deeper integration.

But "build it ourselves" used to imply a relatively large implementation cost.

Coding agents are reducing that cost.

That makes building rational for more things than before.

It also creates a new problem: inexpensive implementation can make reinvention look inexpensive even when the hidden decisions are not.

Option 3: Use a library

Libraries are ideal when the reusable boundary is clear.

They solve a defined technical problem through an API.

Examples include:

validation;
cryptography;
date handling;
UI components;
database clients.

A good library says:

Call this interface and I will reliably perform this function.

That is different from a complete product capability.

"Role-based permissions" or "subscription billing" usually spans database state, user experience, backend rules, external services and tests.

There may be libraries inside the solution, but no single library is the whole answer.

Option 4: Start from a boilerplate

Boilerplates are powerful when you are starting a product and are comfortable adopting someone else's structure.

A good SaaS boilerplate can provide:

authentication;
billing;
common UI;
database conventions;
deployment configuration.

The main limitation appears later:

What if the product already exists?

Replacing your repository with somebody else's repository is rarely sensible.

You can copy selected patterns, but then you are back to adapting a solution into your architecture.

Coding agents make that adaptation far easier.

Option 5: Ask the coding agent

This is now a serious option.

For many features, an agent can:

inspect the repository;
find relevant components;
research APIs;
create migrations;
write backend logic;
modify UI;
add tests.

The cost can be dramatically lower than traditional implementation.

But the agent still needs to decide what "done" means.

A prompt such as:

Add role-based access control

contains very little product specification.

Does a user have one role or many?
Are roles organisation-specific?
Can admins create custom roles?
Do permissions inherit?
What happens when membership is removed?
Can a user belong to multiple organisations?

The agent can choose.

The question is whether you wanted it to choose.

Option 6: Give the agent a reusable capability

This is the model we are exploring at Udria.

Instead of giving the agent a fixed application, give it a reusable package of implementation knowledge:

architecture;
domain behaviour;
edge cases;
constraints;
sequence;
tests.

Then let the agent adapt that capability to the existing repository.

It sits somewhere between:

"build it from scratch"

and:

"install this finished product"

The code becomes local and adapted. The recurring decisions do not need to begin from zero.

A practical decision framework

Ask five questions.

1. Is this capability a source of differentiation?

If yes, building custom behaviour probably makes sense.

2. Is there a mature managed service that removes operational complexity?

If yes, buy the underlying infrastructure where sensible.

3. Does the capability have a clean library boundary?

If yes, use the library.

4. Are we starting from scratch?

If yes, a boilerplate may save substantial time.

5. Is this a recurring capability inside an existing product?

This is where agent-adapted capabilities become particularly interesting.

You may want:

ownership of the resulting code;
fit with the existing architecture;
no new runtime dependency;
less rediscovery of known problems.

The future is probably a mixture

Coding agents do not mean every SaaS company should build every layer itself.

They make the boundaries more flexible.

A future application may simultaneously:

buy Stripe for payment infrastructure;
use an open-source database;
ask an agent to create product-specific workflows;
install reusable capability knowledge for billing and permissions;
use managed email;
build the core differentiated experience from scratch.

The winning architecture is unlikely to be ideologically pure.

It will use the best abstraction at each layer.

The new question is not simply:

Build or buy?