AI writes the code, not the project. Price is one factor of six: a one-minute fit check for internal tools says buy, build, or mixed.
AI can make the coding faster. The rest of the project runs at the speed of your people and your partners: understanding the problem, piloting, testing, integrations, partner waits and training, and they decide whether the team uses the tool. Buy SaaS when the workflow is common. Build it yourself with AI for a prototype. Have it built for production when it becomes how your operations run. With a firm that runs its own AI code factory, building runs continuously and the engineers spend their time on the problem with your team.
A good firm uses AI too, so its coding is fast as well. What you pay it for is the part AI doesn’t do: understanding the problem, piloting, acceptance, integrations, change management and running it in production, carried by people who have done it before (how we build with AI). Use the fit check below: six questions, under a minute. We are an engineering firm that builds operations software, so this guide also says when to buy, and when your prototype is enough.
Where project time goes now
Coding used to be the big block of a software project. With AI tools such as Claude, ChatGPT, Lovable, Replit or Cursor, someone on your team can get working code from a prompt. The rest of the project is the same size it always was.
Coding was always the smaller share of the work. IDC found that developers spent 16% of their time developing applications in 2024; the rest went to work such as writing requirements and test cases, security and deploying code (IDC, via InfoWorld, 24 February 2025).
Studies of AI and coding speed disagree. In a 2023 experiment, developers with GitHub Copilot wrote a small HTTP server in JavaScript 55.8% faster (Peng et al.). A 2024 Google trial with 96 engineers estimated about 21% faster on one enterprise task, with a large margin of error (Google study, 2024). In METR’s 2025 trial, 16 experienced open-source developers took 19% longer with AI tools while believing they were faster (METR, July 2025); METR now marks those results out of date. Its follow-up finds that AI likely sped those developers up by late 2025, and calls its own data “only very weak evidence” of how much, because of who chose to take part (METR, February 2026). All of them measure development tasks, not whole projects. Even a large speed-up shrinks one block.
The six blocks below run at the speed of your people, your partners and the calendar.
Understanding the problem
Before anyone builds or buys, someone maps how the work runs today: who does what, with which data, and where it breaks. Skip it and the tool automates the wrong thing, fast.
Piloting the project
Someone decides the priorities, keeps the scope, and says no. With AI that job gets harder, since every idea now looks quick to add.
Requirements and feedback
Each round of “is this right?” needs the time of the people who will use the tool. AI produces the next version in minutes; your team still needs the afternoon to try it.
Testing and acceptance
The team checks the tool against real cases before it goes live: last month’s odd order, the client with two addresses, the refund. Nobody else knows those cases.
Integrations and partner waits
Connecting to your accounting software or CRM means asking for API access, opening a ticket with a vendor, waiting for your accountant to sign off on a mapping. That is calendar time, and a vendor’s queue moves at its own pace.
Change management and champions
People need training, a champion in each team who answers the first questions, and a date when the old spreadsheet is switched off. Whatever tool you pick, this part is yours.
The short answer: three options, each wins somewhere
Buy SaaS
Wins when The workflow looks like everyone else’s, or the seat bill is small.
- Coding
- The vendor
- Setup
- You
- Testing and acceptance
- You
- Change management
- You
- Running it
- The vendor
Build it yourself with AI
Wins when A prototype or a small tool: a few users, no sensitive data, down for a day is fine.
- Coding
- You, with AI
- Setup
- You
- Testing and acceptance
- You
- Change management
- You
- Running it
- You
Have it built for production
Wins when The tool becomes how your operations run, and must outlast its builder.
The firm runs its own AI code factory, so building runs continuously and its engineers spend their time on the problem with your team.
- Coding
- The firm
- Setup
- The firm, with you
- Testing and acceptance
- You, with the firm
- Change management
- You
- Running it
- The firm, then you
Buy SaaS when the workflow looks like everyone else’s
Accounting, payroll, email, chat and the basics of a CRM work the same way in most companies. The vendor carries the code, the maintenance, the security and the uptime. You still carry the setup, the integrations and the training.
Build it yourself with AI when it’s a prototype or a small tool
A handful of users, no sensitive data, nothing written into your other systems, and nobody hurt if it is down for a day. The code is fast; the discovery, the testing and the training are yours, on top of your day job. It is often the right first step, and a working prototype is a good specification for whatever comes next.
Have it built for production when it becomes how your operations run
More users, permissions, real data, integrations, uptime, and a tool that has to keep working when the person who built it moves on. That is the case for custom business software. With a firm that runs its own AI code factory, building runs continuously and the engineers spend their time on the problem with your team. A good firm runs the whole project: discovery, piloting, acceptance and handover, as well as the code. Your people still give feedback, test it and champion it, and you should own the code, the accounts and the data.
Usually both: buy the commodity, build the one workflow and the connections
Daily operations app
Built- Approvals
- Client portal
- Sync between tools
Keep the accounting, payroll, email and chat you already pay for. Build the daily operations app and the sync between your tools: the parts where your firm differs from the next one. When that layer grows into the system your back office runs on, it becomes an operations back office built around your processes, and our guide on custom vs packaged ERP takes it from there.
Price is the small part: six things that decide build vs buy
A cheaper tool that doesn’t fit, or that you can’t leave, costs more than its price. Six things decide the choice, and price is only one of them.
Fit: does the tool adapt to your team and your way of working?
A tool your team has to work around costs time, and a spreadsheet grows beside it. Leans buy: a standard tool already matches how you work, with a few settings. Leans build: your team works its own way, and bending it into the tool would lose that.
Roadmap risk: waiting for vendor features that may never arrive
A vendor builds what most of its customers ask for. If the feature you need is not on its list, you wait, or you work around it. Leans buy: today’s features are enough. Leans build: the work depends on something the vendor may never ship.
Data: where it’s stored, who can access it, can you export it
Some businesses can keep their data in any reputable vendor’s cloud; others must decide where it lives and who sees it. Check how you would get it out, in what shape, before you sign. Leans buy: a reputable cloud and a clean export are enough. Leans build: the data must stay where you decide, under your control.
Dependency: lock-in, price hikes, a vendor that shuts down or gets acquired
A vendor can raise its prices, change its plans, be bought or close. The question is how much that would hurt. Leans buy: you could switch to another tool easily. Leans build: losing this tool would stop the business.
Edge: is this process how you win?
If clients choose you for the way this work is done, a tool built around everyone else’s way gives that edge away. Leans buy: the process looks like everyone else’s. Leans build: it is how you win.
Cost: compare 3 years, one factor among six
Compare 3 years of the subscription, at the price you will pay after each renewal, with the build quote and its upkeep. The quote covers the project around the code too, not only the coding. Leans buy: buying costs less over 3 years. Leans build: building costs less over 3 years.
The build vs buy fit check
Six questions, under a minute: the five above, and the cost if you open “Compare costs” and put in your numbers. Nothing is answered for you; a question you skip counts as neutral. Your answers stay in your browser and in the page’s address, so you can copy the link and send it to a colleague.
Answer a few more questions.
The balance
- Fitnot answered
- Roadmap risknot answered
- Datanot answered
- Dependencynot answered
- Edgenot answered
- Costnot answered
Who trains the team, who fixes it when it breaks, and who owns it after launch still matter. When a DIY AI prototype is enough
How the verdict works
- Each answer leans buy (−1), stays neutral (0) or leans build (+1); all six count the same.
- Two or more toward build: Build. Two or more toward buy: Buy. Anything closer: Mixed, start with the audit.
- Fewer than three answers: no verdict yet. Cost counts once both the yearly cost and a quote are in.
How to read the result
- The verdict is one line. Each answer leans buy, stays neutral or leans build, and all six count the same: two or more toward one side gives Buy or Build.
- What tipped it names the factors on the winning side, so you can check the reasons, not only the answer.
- The balance shows every factor at once: where each one leans, and which ones you left unanswered.
- Mixed is an honest answer. When the factors pull both ways, the audit turns it into a costed plan: a written plan and a fixed price for the first system.
What AI made faster, and what it didn’t
The project around the code
- Understanding the problem
- Testing and acceptance
- Training and champions
- Integrations and partner waits
Running it
- Access and permissions
- Backups
- The data model
- Monitoring and uptime
- Upgrades
- A named owner
Faster now: the first version, the screens, the demo
A working first version of a form, a dashboard or a small app is quick to make with an AI tool, and it shows people what they are asking for better than any written specification. Use it that way.
Still costly: the project around the code, then running it
The project blocks above come first. Then a tool in daily use needs the following, every month, whoever built it:
- Maintenance. Updates, fixes, the small changes people ask for. A widely cited heuristic puts operations, maintenance and enhancement at 60–80% of a system’s lifecycle cost (Klotz, 2026, citing Lientz and Swanson, 1980, and later work).
- Security and access. Everyone signs in with their own account and sees only what they should, and someone removes access when a person leaves.
- Data quality and the data model. The tool holds one version of each record, in a shape the next report can read.
- Integrations. Syncs with your other tools retry when they fail, and someone is told when they do.
- Uptime. Backups exist, a restore has been tested, and someone notices when the tool is down.
- Ownership when the builder leaves. The code, the accounts and the decisions are written down where the next person finds them.
When a DIY AI prototype is enough
Answer these for your tool. The numbers are examples, to adjust to your case:
- Do fewer than about ten people use it?
- Does it hold no personal, customer or financial data?
- Does it only read from your other systems, and never write into them?
- Would a day of downtime hurt nobody?
- Is the person who built it staying?
- If it broke, would you rather rebuild it than fix it?
- Can people use it without training?
- Does it need no access granted by a partner or a vendor?
All yes: keep the prototype, and keep the money. Each no is a reason to price the production build.
How Sabai builds with AI
AI is how we build. The code is written with AI, and AI runs through the delivery too: meetings transcribed, decisions written in the codebase, documentation kept up to date, feedback gathered from every channel. We run our own AI code factory, so building runs continuously and our engineers spend their time on the problem with your team: understanding it, piloting, feedback, acceptance, and bringing the champions along.
We work inside your tools and your data, side by side with the people who run the operations. The scope comes from your meetings, each round goes to real users, and what they say decides the next one.
What we build is meant to keep running: everyone signs in with their own access, backups are tested, the tool is monitored, and every change goes out the same way, with a way back. It lives in your own accounts from day one, with the decisions written next to the code. Once it is live, you run it, or we keep it running. Maintenance is optional, and the code, the accounts and the data stay yours.
To start small, take the paid audit: it ends in a written plan and a fixed price for the first system. When the need is already clear, we go straight to the build.
Signs your prototype needs to go to production
- More people rely on it every day.
- It writes into your accounting software or your CRM.
- It holds customer or staff data.
- Someone asks who can see what.
- It broke, and only one person could fix it.
- It has become a second copy of data that lives somewhere else.
- A team won’t use it until someone trains them.
When you see these, the work ahead is the project around the code. We take tools that teams built themselves to production as part of our custom business software work.
Who answers when it breaks
Run the named-owner test before you decide: write down the name of the person or firm who answers when the tool breaks on a Monday morning, and what their time costs. If you cannot write a name down, buy.
There are three ways to fill it:
- The builder keeps it. On top of their day job. Plan the handover for the day they move on.
- A developer you employ. Their hours on the tool, at their cost, and a second person who can cover for them.
- A firm on a maintenance plan. Its fee is the upkeep you add in the fit check’s cost part. Ours is optional: you can keep us on it, hand the tool to your own people with training, or move to another firm.
If you have it built, keep the exit cheap
Three things keep the cost of leaving small, and each is easy to check before you sign:
- Your accounts from day one. The hosting, the database and the code are opened in your company’s name, and the builder works in them as a guest.
- Updates anyone can repeat. A change goes out through the same automated steps every time, and the previous version is one step away.
- Decisions written next to the code. Why the data has this shape, why a sync runs at night: written where the next engineer, or your own AI assistant, will read it.
With all three, you can leave and it keeps working.
Where an AI assistant or agent fits
Whether you buy or build, an assistant or an agent is a decision of its own. An AI assistant answers when someone asks: connect an assistant such as Claude or ChatGPT to the tools you already have, and the team asks about orders or clients in plain words. An agent takes on a task and does it, on a schedule or when the data changes, within the permissions you set. Both work on bought tools and built ones, as long as the tool lets other software read its data through an .
Term API An application programming interface: the way software talks to a system, to ask it for data or tell it to do something.
We set these up as their own services: AI integration for an assistant on your data, and AI agents for tasks that run by themselves.
Frequently asked questions
If AI writes the code, why does a software project still take months?
Because coding is one block of the project. Understanding the problem, rounds of feedback, testing and acceptance, partner waits and training the team run at the speed of your people and your partners, and some of it is calendar time that faster coding leaves as it is.
How much of a software project is actually coding?
Less than most people think. IDC found that developers spent 16% of their working time developing applications in 2024. Studies of AI measure development tasks, and they disagree on the speed-up.
Is it cheaper to build or buy internal tools now that we have AI?
Price is one factor. Compare 3 years of the subscription with the build quote, then weigh fit, roadmap risk, data, dependency and edge; the fit check in this guide does all six in under a minute.
What matters more than price in build vs buy?
Five things: whether the tool fits the way your team works, whether you would be waiting on a vendor’s roadmap, where your data lives and who controls it, how much it would hurt to lose the vendor, and whether the process is how you win.
Why pay a firm if AI writes code?
Because the code was never the whole project. We run our own AI code factory, so building runs continuously and our engineers spend their time where projects succeed or fail: on the problem with your team, piloting, feedback, acceptance and getting people to use it. Once it’s live, you run it, or we keep it running; maintenance is optional.
Talk it through with us
Bring your fit check link, or the prototype you built. By the end you’ll know whether to buy, keep your prototype, or take it to production, and if we can’t help, we won’t follow up.
Book a free 30-minute call. No commitment. You pick the time.