The Case for AI-Native Custom Software

When I want to know what happened last week across our company, or which projects are at risk of overrunning, I ask Claude. For the first, it reads the diary of every active project in our Backoffice and writes a summary. For the second, it compares the hours logged on each project against its budget and the invoices issued so far. Before a first meeting with the CTO of a company that wants a certain kind of system, I ask it for a presentation. It finds our most similar past projects, reads the records of what we actually built for them, and drafts a deck on our template with the technical details a CTO will care about. And when a project reaches a milestone, I tell it, and it drafts the invoice in Holded, our invoicing tool, for our accounting team to review.

Before the Backoffice, answering any of these meant opening several tools and finding the people who knew. The information was spread across a planning spreadsheet, Holded, and a tree of Drive folders, and much of it was never recorded at all. Decisions were buried in email threads and Google Chat, and the context of a project was known only to the people working on it.

What changed is that an agent can now see and act on the whole company, through software we built on top of the tools we already had. This essay is about why most companies should build software like it, and what we learned building ours.

Where AI adoption actually is

Most companies I work with have taken the first step. Employees have Copilot, ChatGPT, or Claude, and many use them every day. They use them interactively, one conversation at a time, and far below what the tools can do, because the agent only knows what someone pastes into it. It cannot see the CRM, the project plan, or the invoices, and it cannot act on any of them.

Software vendors offer their own answer, which is an agent inside each product. The CRM gets an assistant, the ERP another, the document platform a third. Some of them offer useful features, and they tend to fall short in two ways. They cannot be customized to how a particular company works, and they are no help with work that crosses systems, which is much of the work that matters.

Meanwhile, a large share of the real work still happens in Excel, Word, and email. Every company differs from the typical customer its software was designed for, and whatever the software does not accommodate ends up in a spreadsheet someone maintains on the side or a thread only three people have read.

So there are two problems: the agents cannot reach the company, and the company’s software does not fit the company. Both have the same solution, and most companies rule it out by reflex: build software of your own.

Build versus buy, revisited

A rule from when programming was expensive

The default answer in enterprise IT has long been to buy. That default made sense when programming was expensive. When a custom application meant a six-figure budget, nine months, and a team you had to hire and keep, adapting your work to a product was cheaper than building one that adapted to you.

That constraint has mostly gone. In our work, coding agents now write most of the code, and a small team can ship in weeks what used to take a department most of a year. The rule to buy by default has outlived the conditions that justified it.

My own position has moved on this. Until recently I recommended that custom AI applications stay thin layers you could replace in six months, never an internal platform, and that companies lean on their existing vendors wherever they could. What changed my mind is that the models became much more capable, much faster than I expected, and building now wins in many more cases than I thought it would.

The arguments for buying

The first argument is that building is expensive. That used to be true. For most of the software a company needs, it no longer is. The system I describe below was built by two people working part time for two months.

The second is that a vendor spreads its research and development across thousands of customers, which no internal team can match. This remains true for systems of record, the systems that hold the authoritative version of a company’s core data: the CRM for customers and deals, the invoicing system for invoices, the ERP for orders and inventory, the HR system for people. That is exactly why you should keep buying them. It is false for the part of your operations that is specific to you, because no vendor can sell you that part.

That part already exists as custom software, in Excel. The spreadsheet the operations team maintains alongside the ERP, with its own formulas and unwritten rules, is custom software with no versioning, no permissions, and no tests, and agents cannot use it reliably. The choice is between building that software badly, by accident, or building it properly.

The third argument is risk and maintenance. Custom software can fail, and it has to be maintained. Building on top of the systems of record changes both. The layer I am describing may hold new records of its own, such as project diaries, but the records the business depends on stay in the systems you bought. If it failed or disappeared tomorrow, the company would fall back to the way it worked before, with its records intact. That makes custom software far less risky than replacing a system of record. Maintenance has also become cheaper, for the same reason building has: the same small team and the same agents that built the system maintain it, through the same issues, reviews, and tests.

The fourth is that you can buy AI from your existing vendors. As described above, each of those agents sees only its own product. None of them can tell you which projects are at risk of overrunning, because that needs the plan, the hours, and the invoices at once. And, as I explain below, buying AI this way usually costs more.

The synthesis is to buy the core systems of record, and build the work that happens around them.

What AI-native means

By AI-native software I mean software designed with agents as its primary users. The software itself is, above all, structure: a data model and the actions the company allows on it, including who can take each one and under which conditions. General-purpose agents such as Claude, Copilot, or ChatGPT reach all of it over MCP or a command-line interface, and that is where the work happens. A web interface can sit on top, for people to see what is happening and check what agents have done. It is optional, and often very useful.

Using the AI you already pay for

This design has an economic advantage that is easy to overlook. Most companies already pay for Copilot, ChatGPT, or Claude licenses, and AI-native software makes those same licenses far more useful. The alternatives usually add cost. Each vendor’s AI features tend to come as another per-seat add-on, one per product, and those add-ons are easy to underuse: the company pays for every seat, while many people open the feature rarely or never. A general-purpose agent is much less likely to sit idle, because people use it across all of their work. A chat assistant built into your own application means paying for model usage directly, with a bill that grows with how much people use it and that is hard to predict in advance. Connecting the agents people already have to the company’s own systems keeps the cost of the intelligence in licenses the company already knows and controls. The investment goes into the layer. What tends to happen next is that people use their agents much more, and some ask for plans with higher usage limits. That is a real cost, and I would argue it is a good problem to have: it means your employees are actually adopting AI.

It also makes the change easier for people: they do not have to learn a new assistant or a new interface. The agent they already use every day simply becomes able to do more.

How we run Napptilus AI

We run our company on software built this way, which we call the Backoffice. It sits on top of the tools we already used: Google Drive for documents, GitHub for code and project management, Holded for invoicing, and SesameHR for people. It replaced our planning spreadsheet and absorbed much of what used to live in email and in people’s memories. Each person uses it with the access their role gives them, and usage keeps growing as we get used to new ways of working and keep improving it. It rests on one precondition and three principles.

The precondition is that every system underneath must be reachable. We chose, and kept, tools with good APIs. A good API lets you do everything the user interface lets you do, and supports scoped tokens or OAuth applications so that access can be granted narrowly. A tool without one is a place agents cannot go, and over time everything that happens there becomes more expensive than everything that happens elsewhere.

A layer that unifies and customizes

The Backoffice owns the connections between records across systems. A client is linked to its contact in Holded, a project to its client, people to projects through their allocations, and hours and invoices to projects. It also gives a unified point of access and a consistent organization to information that used to be scattered, or never written down at all. Every project has a summary of its current state, a diary of what happened and what was decided, a solution record describing what we actually built, a permissions tab, and an invoicing tab with its billing plan. Next to projects sit team planning, including vacations, and the hours everyone logs.

The layer is thin over what already existed and thick where nothing existed. Client records and invoices belong to Holded, and the Backoffice only connects them. The diaries and solution records are new. Some of what they hold is knowledge that nobody had written down before. Much of the rest already existed somewhere, and many diary entries are short notes that link to a document in Drive or an issue in GitHub. The point is to make that information easy for agents to find, without duplicating it.

Screens for seeing, agents for doing

The web interface was already a large improvement on the fragmented view we had before, and it is where we look at the state of things and verify what agents did. The more valuable part is the MCP server, which gives Claude and ChatGPT access to everything the system can do, and that is where the work happens. Because MCP is an open standard, the same layer works with whichever agent a person prefers, and we could change providers without rebuilding anything. The layer is ours, and the intelligence is rented.

Software gives agents structure

If agents can connect to Holded, Drive, and GitHub directly, why build anything in between? Because software gives the work structure, and structure changes what agents do. It does three things at once:

• It makes the right actions easy: the agent sees “create a draft invoice for this project” instead of every operation Holded offers.
• It makes some actions impossible.
• It standardizes the work, because every person and every agent in the company goes through the same paths.

A raw connection to Holded has none of this. It exposes everything Holded can do, with no notion of our projects, our companies, or the way we invoice, so the agent has to infer all of that from its instructions every time. That makes mistakes easier, and it means two employees, or two runs of the same agent, can do the same task in two different ways. The more structure the software provides, the less the agent has to figure out on its own, and the more correct and consistent the work becomes.

When agents do the work, the step-by-step know-how that used to live in screens and in people’s heads moves into the agent’s skills and playbooks. What stays in the software is what should never depend on the model’s judgment: the data, the actions available, and the conditions on them.

Invoicing shows how this works. Claude prepares a new client’s invoices from the signed contract, but the software decides what it can do:

• Every invoice belongs to a project and names which of our companies issues it. There is no default, because a default would eventually send an invoice from the wrong entity.
• The agent can draft invoices in Holded but cannot send them. Our accounting team reviews and sends each one.
• The agent acts as the person using it, within that person’s role, and every change is logged.

An instruction in a prompt can be ignored by a model on a bad day, and a constraint built into the software cannot.

This is also why I changed my mind about letting agents write. I used to advise starting with read-only integrations. Our agents now write every day, because today’s models are far more capable, and because the structure of our own software keeps a mistake from turning into a disaster.

What it makes possible

The first level of value is saving clicks. Registering a project, logging hours by telling an agent what I worked on this week, and drafting a contract from our template each take a sentence instead of a sequence of forms.

The second level is asking questions that span the whole company, like the ones at the start of this essay. Each of them used to mean opening several tools or finding someone who knew:

• Which clients have invoices past their due date?
• What is our financial position this month?
• Can I approve these vacation dates, or do they conflict with the rest of the team or with our policy?
• A project needs one and a half engineers from next month. Who could we staff on it?

The third level is new work built from the company’s memory, like the CTO presentation. When we write a proposal, the agent reads everything related to comparable projects, from their diaries to their repositories and Drive folders, and flags the problems we ran into, such as how long it took to get access to a client’s systems. When a client asks for a breakdown of each person’s hours in their own Excel format, the agent builds it from the logged hours. And every once in a while we can ask it to read every diary and tell us what we should improve.

Using software that does not work this way now feels like going back to the stone age. When I have to do something in a tool our agents cannot reach, I notice every form and every copied value.

How we built it

So far, the Backoffice has been built by one of our engineers and me, spending about 20 hours a week between us over two months. For a system of this scope, that is very little time.

We built it entirely with Claude Code, working in a very agentic way. We defined goals mostly from the point of view of the people who would use the system, with very few technical ones; the hierarchical permission system was one of the few. We also defined the development workflow the way we wanted it, including how to write GitHub issues, how changes are tested, and how they move through environments and deploys. Every goal and decision lives in a GitHub issue, so the reasoning behind each part can be traced. Claude often ran all night on its own.

We iterated very fast, and we chose to build something quickly and try it, even when it was imperfect, over waiting longer for a better version. That level of risk was acceptable for an internal tool, and a client project needs more care, though the principles are the same. The cost of building has become mostly the cost of deciding what you want.

The same speed applies to smaller tools. We used to transcribe our meetings with Whisper AI. It worked quite well, but it kept annoying us in a few ways: recording live from the browser was buggy, Catalan transcription was weaker, and every meeting meant uploading the recording, waiting for the transcript, downloading it, and uploading it again to the right Drive folder. So we built our own internal transcription app, a native macOS application that records meetings and separates speakers, and had a usable first version in one day. Building a native desktop application for an internal team would once have been absurd. Now none of those problems remain, each transcript goes straight to the right project through the Backoffice API, and we are planning more features.

Overkill that is now cheap

Several parts of the Backoffice would have looked like overkill for an internal tool with fewer than 20 users. Before, we would have simplified or skipped them. When they are cheap to build, there is little reason to.

• Cloud-style permissions. Granular roles are granted on a client or a project and inherited downward, like a cloud provider’s access management. For a team our size we would once have settled for administrators and everyone else.
• Infrastructure as code. Everything is defined in Terraform, and production and a separate demo environment with sample data, which we use to show the system to clients, are built from the same configuration.
• An agent red team. A security agent attacks our own application with forged sessions, direct calls to endpoints the interface hides, and known framework vulnerabilities, and files each finding as an issue. A QA agent validates every change in a real browser and checks the database.
• Three languages. The whole interface is available in Catalan, Spanish, and English.

When the rigorous version costs about the same as the quick one, the usual trade-off between speed and quality weakens. That should change what a company expects when it commissions custom software.

What is still open

We have had no major failures so far. Part of the reason is how we release: we roll changes out in phases and test them before relying on them for real work. Every change is in the audit log, and the database has point-in-time recovery, so when we catch a problem we can trace what happened and restore the data to a moment before it.

One thing surprised us. The MCP server exposes about 120 tools, and it works well. I expected that many tools to confuse the model, and so far they have not. We are exploring whether a better-designed MCP server would work better, and we are building a command-line interface over the same tools to compare the two.

Other questions remain. We are constantly reevaluating the best way to organize information and bring it into the system, and search has to keep up as the diaries and solution records grow. We keep testing new models and architectures, and we keep working on cost. And the system has to stay simple and flexible as it grows, so that changing it stays cheap.

For your company

Replace what holds you back

If your company runs systems without good APIs, or systems that hold you back, start replacing them now. Every year you wait widens the gap between what your competitors’ agents can do and what yours can. Migrations used to be slow and dangerous largely because of archaeology: understanding the old system, its customizations, and its undocumented rules. AI is very good at that work. It reads old code, maps data models, and writes the tests that make a change safe. A replacement that looked impossible two years ago is now a project you can plan.

Start small

All of this is easier at a company of our size. A large enterprise has more systems, more governance, stricter data policies, more complex permissions, and more people who need to trust the result, so it needs more care. The way to start is with a smaller domain, such as a tool for the sales department, built by a small internal team or a partner, and to let the custom software grow in scope as the company builds confidence in it.

Imagine that first tool at an industrial manufacturer. Marta, a key account manager, opens Claude with the plugins her role needs, connecting it to a sales layer built on top of SAP, the quoting application, the service system, and her Drive. Her quarterly review for her largest customer pulls sales figures, open service incidents, and her own notes into a deck on the company’s template. When a customer asks for a non-standard configuration, the agent drafts the quote. The quoting application enforces the margin floor and her discount limit, and sends anything beyond that limit to her manager for approval. After a customer call, the action items land in the account’s diary. What disappears from her day is the coordination work and the pulling together of information from different sources, so she can spend her time on her customers.

The same shape fits very different companies: a claims layer for an insurer on top of its policy system, a tool that drafts tender responses from the CRM and past bids, or supplier onboarding on top of SAP. In each case the systems of record stay where they are, and the work around them moves into software that fits the company and that agents can use.

Control and the early-mover advantage

This setup also puts the company in control of how it uses AI. It decides what agents can see and do, because that structure lives in its own software. It decides which agent to use, and can switch when a better one appears. And it decides what to build next, on its own schedule. When a company builds on a vendor’s agent platform, all three of those decisions are shared with the vendor.

At Napptilus AI we build this kind of software for our clients, and we run our own company on it. I believe the companies that adopt it early will have a large advantage over those that do not, because the advantage compounds. Each layer accumulates knowledge in its diaries and records, encodes more of how the company works, and settles into people’s habits. Each new workflow is cheaper to add than the last, because the connections, permissions, and habits already exist. And people learn to work through agents, which takes time and experience that no company can buy on the day it decides to start. The practical conclusion is to begin now, with one domain, the systems of record you already have, and the agents your people already use, and to let the software grow from there.