You Can Ask Claude to Build It. The Question Is Why You Should Have To.

A few years ago, adding a serious new capability to a SaaS product usually meant assigning a developer, writing a specification, researching APIs, implementing the feature, testing it, finding the inevitable edge cases, fixing them, deploying it, and then discovering another edge case in production.

Coding agents have changed this dramatically.

Today you can open Claude Code or Codex and say:

Add Stripe subscriptions to this application.

Or:

Build me a basic CRM.

Or:

Add roles and permissions.

And, remarkably often, something useful appears.

That is a huge change in software development.

But it creates a strange new inefficiency.

Thousands of people are now asking coding agents to rediscover exactly the same software problems, independently, over and over again.

The code may be inexpensive to generate.

The thinking around the code is not.

That is the problem we are trying to solve with Udria.

The wrong comparison is tokens

When people talk about AI-assisted software development, they often focus on token cost.

How many tokens did Claude use?

How much did the API bill cost?

Could I run an open-source model instead?

Those are useful questions, but increasingly they are not the important ones.

Tokens are becoming cheap.

Some developers have flat-rate subscriptions. Others use open-source models. Model costs will continue falling. Caching will improve. Hardware will become cheaper.

The scarce resource is still human attention.

Imagine a competent founder decides to implement production subscription billing themselves using a coding agent.

The first version might appear in an afternoon.

Checkout works.

The webhook fires.

The database says the customer is subscribed.

It feels almost finished.

Then come the questions.

What happens when Stripe sends the same webhook twice?

What if the server records the webhook and crashes before finishing the business logic?

What if two identical events arrive simultaneously?

What happens when a card requires 3D Secure authentication?

What happens when an upgrade requires payment but that payment fails?

Should a downgrade happen immediately or at the end of the period?

What happens to product access while a subscription is past_due?

What if somebody cancels and then changes their mind?

What happens if Stripe and the local database drift apart?

What happens if an old event arrives after a newer event?

How should refunds behave?

What happens during a chargeback?

Which actions belong in the Stripe Customer Portal and which belong in the application?

And that is before you start thinking about tenant isolation, migrations, test environments, reconciliation, security, deployment, API version changes or rollback.

The implementation was cheap.

The journey from plausible implementation to trusted production capability was not.

There are several levels of "built"

This distinction matters enormously in the coding-agent era.

Suppose someone says:

"Claude built our Stripe integration in two hours."

That may be completely true.

But "built" can mean very different things.

At the first level, the feature exists. A button creates a Stripe Checkout session.

At the next level, the main customer journey works. A customer can subscribe and the SaaS recognises the subscription.

Then comes production behaviour: upgrades, downgrades, failed payments, trials, cancellation, webhooks, duplicate events, authentication-required payments and recovery.

Then reliability: race conditions, retries, transaction boundaries, partial failure, drift reconciliation and idempotency.

Then security: tenant isolation, server-side authorisation, secret handling and protection against tampered Stripe identifiers.

Then verification: acceptance tests proving the important behaviours rather than merely proving that the code compiles.

And finally portability: can the same solution be applied to a different real application without rebuilding the whole thing?

Those are very different products.

A lot of AI-generated software today reaches somewhere around the second or third level.

That is already useful.

Udria is interested in packaging the knowledge required to get much further.

Why should every founder discover the same Stripe edge cases?

Stripe is simply our first example.

The underlying pattern is much larger.

Almost every SaaS application eventually needs some combination of:

Capability	What initially sounds simple	What eventually appears
Billing	"Add subscriptions"	Webhooks, retries, entitlements, failed payments, upgrades, cancellation, SCA
Permissions	"Add Admin and Member roles"	Tenant scope, custom permissions, invitations, revocation, ownership invariants
Scheduling	"Add a booking calendar"	Availability, time zones, concurrency, buffers, recurrence, rescheduling
CRM	"Add deals and contacts"	Pipelines, lifecycle states, ownership, activities, permissions, imports
E-signatures	"Let users sign a document"	Identity, document versions, audit trails, callbacks, completion states
Notifications	"Send emails and alerts"	Preferences, retries, templates, rate limits, deduplication
Audit logs	"Record what users do"	Actor context, immutability, retention, tenancy, sensitive data
Team invitations	"Invite somebody by email"	Expiry, replay, role assignment, duplicate membership, security
File workflows	"Upload a file"	Permissions, processing state, retries, scanning, versioning
Analytics	"Track product usage"	Event taxonomy, identity, deduplication, consent, attribution

None of these problems is identical between companies.

But neither is each implementation completely unique.

That middle ground is where we think a new category of software product can exist.

Software has always moved towards reuse

Nobody implementing a SaaS product starts by writing an operating system.

We reuse infrastructure.

We reuse databases.

We reuse frameworks.

We reuse libraries.

We use Stripe instead of building payment rails.

We use managed email instead of running mail servers.

But there is still a large layer above libraries and below complete SaaS products where software teams repeatedly rebuild the same thing.

Traditionally, we had a few ways to address this.

We could buy another SaaS product.

We could install a library.

We could begin with a boilerplate.

We could copy somebody else's source code.

Or we could build the feature ourselves.

Coding agents introduce another possibility.

Reuse the accumulated knowledge behind a capability, then let the agent adapt it to the software that already exists.

That is what Udria is trying to productise.

So what exactly do you buy from Udria?

This is an important point, because it is not simply source code that you copy into your application.

Imagine you buy Udria Production Stripe Billing.

You receive a versioned capability package.

Inside it is the information a coding agent needs to implement the capability properly: architecture, domain states, edge cases, security boundaries, implementation sequence, compatibility guidance, acceptance tests, reference material and troubleshooting.

You add the package to your repository — for example under:

/.udria/production-stripe-billing/

Then you tell Claude Code or Codex something equivalent to:

Read the Udria Production Stripe Billing capability. Inspect this repository. Produce a preflight assessment and implementation plan. Adapt the capability to our existing users, organisations, database and UI conventions. Do not change production systems. Implement in stages and run the Udria acceptance suite when complete.

The agent does not simply dump a generic Stripe project into your repository.

It first inspects your application.

Perhaps your organisation table is called workspaces.

Perhaps you use Supabase Auth.

Perhaps billing permissions are controlled by workspace_admin.

Perhaps your application uses server actions rather than API routes.

Perhaps your settings area has an established component system.

The agent maps the Udria capability onto those existing conventions.

Then it implements the actual code.

The capability is therefore closer to a production engineering playbook plus executable definition of done than a traditional boilerplate.

The final code is still yours

This part matters.

Udria does not need to sit inside your production request path.

Your customers do not make billing requests through an Udria server.

Your application does not stop working if Udria disappears tomorrow.

The coding agent reads the capability and implements it into your application.

Your database.

Your Stripe account.

Your infrastructure.

Your code.

That is one of the things coding agents make newly practical.

Before agents, distributing detailed implementation knowledge without distributing a complete fixed application would leave a large translation job for a developer.

Now that translation is precisely what Claude Code, Codex and similar tools are increasingly good at.

Why not simply give Claude the same task?

You absolutely can.

That is important to say plainly.

Claude can build Stripe Billing without Udria.

Codex can build permissions without Udria.

An experienced developer can build all of these things without Udria.

The relevant question is not:

Can it be built?

It is:

Why pay for everyone to rediscover the same production knowledge independently?

If somebody has unlimited time, enjoys the problem and wants complete control over every design decision, building from scratch can be perfectly rational.

But most SaaS founders have a different constraint.

They have fifty things to build and ten things that actually differentiate the company.

Subscription retry semantics probably aren't one of them.

Webhook concurrency probably isn't one of them.

The rules around the final organisation owner probably aren't one of them.

Daylight-saving edge cases in a booking system probably aren't one of them.

These things need to work.

They rarely make the company valuable.

Saving tokens isn't the product. Saving attention is.

Suppose a developer costs £100 per hour.

If Udria saves that developer only four hours, a $199 capability has already paid for itself.

But for a founder, the calculation is arguably even more extreme.

Imagine losing two working days investigating Stripe lifecycle behaviour.

Those two days could instead have gone towards:

• talking to customers;
• improving onboarding;
• shipping the differentiating part of the product;
• finding distribution;
• closing a sale;
• raising money;
• hiring;
• fixing retention.

The opportunity cost is not the API bill.

It is what you weren't doing while solving infrastructure somebody else had already solved.

This is why we think the economics of AI software development are slightly counterintuitive.

As code gets cheaper, good use of human attention becomes more valuable.

"But my coding agent can research all of this"

It can.

And it probably will.

It can open Stripe documentation.

It can search for how webhook idempotency works.

It can reason about subscription state.

It can invent tests.

It can inspect your codebase.

That is extraordinary.

But think about the aggregate economics.

One founder asks Claude to investigate Stripe upgrade behaviour.

Another asks Codex the same thing an hour later.

Another asks an open-source model.

Another spends half a day debugging the event ledger.

Another discovers that an event can be recorded but remain unprocessed.

Another discovers a 3DS edge case.

Another finds a race condition.

Millions of model tokens and, more importantly, millions of hours of human supervision are being spent rediscovering software behaviours that are fundamentally recurring.

AI makes reinvention cheap enough that we barely notice we are doing it.

Udria's argument is that some of that knowledge should become a product.

The acceptance tests may be the most valuable part

Documentation alone isn't enough.

A specification can still be wrong.

A coding agent can misunderstand it.

A repository may force an adaptation.

This is why our concept of a capability includes tests.

For production billing, a test suite might ask:

If the same successfully processed webhook arrives twice, does the business effect happen exactly once?

Or:

If processing fails after recording the event, can the retry still complete correctly?

Or:

If an upgrade requires 3D Secure authentication, does the customer avoid receiving upgraded access until authentication succeeds?

Or:

Can a user modify another organisation's billing by tampering with an ID?

Now the agent isn't simply told:

"Build Stripe billing well."

It has executable evidence describing what "well" means.

That changes the workflow.

Instead of:

Prompt → code → looks okay → ship.

You get something closer to:

Capability → inspect repository → implement → attack implementation → run acceptance suite → review exceptions → ship.

And yes, you should still let your own agent review it

Udria should not become another black box asking for blind trust.

If you buy a capability, there is no reason you shouldn't tell your own coding agent:

Review everything Udria is proposing. Look for security issues, outdated API assumptions and architecture conflicts with our repository before implementing it.

In fact, we would encourage that.

Then after installation:

Independently review the diff and rerun the security and acceptance tests.

This is another benefit of the model.

Because the output is your code, your agent can inspect it.

There is no opaque third-party runtime that requires blind trust.

The capability should have been through this journey already

The standard we want for an Udria capability is not:

"Someone wrote a good prompt for it."

The standard is closer to:

It was specified, implemented, tested, deliberately broken, corrected, installed into real reference applications, run through acceptance tests and then packaged so another coding agent could reproduce the result.

That does not mean we can promise that every possible edge case has been discovered.

No serious software product can honestly make that claim.

It means the important known behaviours are explicit, the testing is substantial, and the capability has gone through significantly more scrutiny than an improvised first-pass prompt.

Over time, this becomes more valuable.

Customer finds an edge case.

The capability is updated.

A test is added.

Version 1.1 becomes better than version 1.0.

Another implementation exposes a repository assumption.

Preflight improves.

The next buyer inherits that learning.

That is what software reuse is supposed to do.

This becomes much bigger than Stripe

If the model works, Stripe is simply capability number one.

Imagine opening Udria later and seeing capabilities such as:

RBAC & Permissions
Production multi-tenant roles, permissions, owner invariants, invitations and server-side enforcement.

Scheduling & Availability
Resource availability, time zones, recurrence, exceptions, double-booking prevention and rescheduling.

CRM Deals Pipeline
Contacts, organisations, deals, stages, ownership, activities, permissions and imports.

E-signature Workflow
Document states, recipients, signing order, callbacks, audit history and completion.

Audit Logging
Actors, actions, target objects, metadata, tenant isolation, retention and administration.

Team Invitations
Invite lifecycle, expiry, replay protection, role assignment and membership conflicts.

Notifications
Templates, preferences, retries, deduplication and channel orchestration.

Feature Entitlements
Plans, features, limits, overrides, access enforcement and lifecycle changes.

Some might cost $49.

Some $199.

Some $500.

A substantial subsystem might cost considerably more.

The relevant comparison is not:

How much did the ZIP file cost to produce?

It is:

How much engineering attention would this capability otherwise consume?

This could change what "buying software" means

Traditionally, buying software generally meant buying access to somebody else's running application.

That has disadvantages.

Another database.

Another account.

Another vendor dependency.

Another API.

Another UI.

Another monthly subscription.

With coding agents, an alternative becomes possible.

You could buy the knowledge required to create the capability inside your own product.

The vendor doesn't necessarily need to host the runtime.

The customer doesn't necessarily need to adopt the vendor's architecture.

The agent becomes the integration layer.

That may open a very large category between software libraries and SaaS.

A package manager for solved software problems

The long-term vision for Udria is therefore fairly simple.

You are building a product.

You need billing.

Search Udria.

You need permissions.

Search Udria.

You need scheduling.

Search Udria.

You need approval workflows.

Search Udria.

Before telling your coding agent to invent the entire thing from a blank page, ask:

Has somebody already worked through this properly?

If the answer is yes, start there.

Your coding agent can still change it.

Your developer can still challenge it.

Your security review can still attack it.

You keep the final code.

You simply stop pretending that rediscovering every recurring software problem from first principles is valuable work.

There is a bigger consequence for software teams

For decades, engineering capacity limited what small teams could attempt.

A company might decide against a feature because it would take two engineers three weeks.

Coding agents are destroying that constraint remarkably quickly.

That means much smaller teams will build much more sophisticated software.

But it also means the bottleneck moves.

The question becomes less:

Who is going to type all this code?

And more:

Which problems deserve original thinking?

That is a healthier question.

The unique customer experience deserves your attention.

The business model deserves your attention.

The difficult domain-specific workflow deserves your attention.

The recurring plumbing that ten thousand other SaaS companies already built probably deserves less of it.

We intend to measure this, rather than merely claim it

There is an obvious problem with everything written above.

It sounds good.

We need to prove it.

So while building Production Stripe Billing, we intend to measure the actual work:

• elapsed development time;
• active human time;
• coding-agent sessions;
• model usage where measurable;
• interventions;
• architecture changes;
• tests;
• defects;
• failed approaches.

Then, once the capability is stable, we can run a controlled comparison.

Take the same application.

Same starting commit.

Same coding agent.

Same production requirements.

Same acceptance suite.

First tell the agent:

Build this from scratch.

Then reset the repository and give it the Udria capability.

The interesting result isn't necessarily token count.

It is:

How close did each approach get to the production definition of done, and how much human attention did each require?

Perhaps the from-scratch agent performs brilliantly.

Perhaps Udria barely improves it.

If so, we need to know.

But if the difference is substantial, we won't need exaggerated marketing.

We can simply publish the evidence.

The $199 question

If you can ask Claude to build something, why pay $199?

Because $199 is not being compared to the price of tokens.

It is being compared to your time.

If the capability saves:

• two hours, it may already be rational;
• one day, it is cheap;
• several days of debugging and review, it becomes almost irrelevant.

And there is another factor:

you get to start now.

You do not spend Monday discovering the architecture.

Tuesday finding the edge cases.

Wednesday testing.

Thursday fixing the tests.

Friday realising the first architecture made one of the failure cases impossible to handle cleanly.

Instead, you give your agent a capability whose starting point is the result of somebody else already having gone through that loop.

You can still inspect everything.

You can still change anything.

You simply start further ahead.

Code is becoming abundant

That is the paradox behind Udria.

Software has traditionally been valuable partly because producing code was expensive.

Coding agents are making code abundant.

Once that happens, simply possessing code is not particularly interesting.

What becomes valuable is the accumulated knowledge around it:

• what should exist;
• how it should behave;
• which decisions interact;
• where it fails;
• how it recovers;
• how it should be tested;
• what evidence should make us willing to ship it.

We think that knowledge can itself become reusable software infrastructure.

That is what we're building Udria to find out.

You can rebuild it. Or you can start from done.

Production Stripe Billing is our first experiment.

Not because Stripe is the only recurring software problem.

Precisely because it isn't.