Build vs. Buy Just Got a Third Option: Compile It
Comparing build vs. buy for internal tools? Compiling from a spec is a third option — you own the code without hiring an engineer.
Should You Build or Buy Your Next Internal Tool?
Every internal tool decision used to come down to two bad options: pay an engineer to build it, or pay a SaaS vendor to rent something close enough. There’s a third option now. Describe the tool in plain language, and a compiler turns that description into a real, deployed application — backend, database, and auth included — that your team owns outright. That changes the math on almost every internal tool a mid-size team has been putting off.
The build-vs-buy question hasn’t gone away. It’s just gained a third branch, and for a large share of internal tools — approval workflows, trackers, dashboards, intake forms — that third branch often wins on cost, speed, and ownership at once.
TL;DR
- The classic build-vs-buy decision for internal tools now has a third branch: compiling an app from a plain-language spec instead of hiring an engineer or subscribing to SaaS.
- Buying SaaS means paying a recurring per-seat fee for as long as the company exists, for software built for the average customer rather than your actual workflow.
- Building with an engineer gets you a tool that fits, but it costs contractor day rates, takes weeks, and carries ongoing maintenance once that person moves on.
- Compiling an internal tool with Remy typically runs $100–$500 in AI tokens for the whole build, billed at provider rates, on top of a flat $99/month platform fee ($79 annual).
- The output of a compiled build is standard TypeScript in a git repo you own — not a subscription, and not a black box only one person understands.
- A compiled app ships with its plain-language spec as its own documentation, so the next person who inherits it can read what it’s supposed to do instead of reverse-engineering the code.
- Internal tools like vendor approvals, HR trackers, and inventory dashboards are exactly the shape of workload this third option is built for.
- The real decision is matching the tool to how custom the workflow actually is — buy the generic, compile the specific, build only the truly large.
One coffee. One working app.
You bring the idea. Remy manages the project.
Why Does Build vs. Buy Break Down for Internal Tools?
Internal tools are the least-served category in software. They’re too specific for generic SaaS and too small to justify a dedicated engineering sprint. A vendor approval tracker, a fund’s deal log, an HR onboarding checklist — none of these are big enough to get engineering headcount, but all of them are annoying enough as a spreadsheet that someone eventually goes looking for a fix.
Consider the scale of a typical SaaS stack: a 200-person company running a couple dozen line-item subscriptions — CRM, issue tracking, internal trackers, expense reports, forms and surveys — can add up to tens of thousands of dollars a month, and millions over several years. Most of those tools were built for the average customer of the vendor selling them, not for how your team actually works.
That’s the buy side of the old choice. The build side has its own tax: a contractor or in-house engineer can build exactly what you need, but at day-rate cost, over weeks, and the tool becomes an orphan the moment that person moves teams. Neither branch was ever a great fit for a workflow this specific and this small.
What Does “Compile” Actually Mean as a Third Option?
A spec is a planning document for your app, written in plain language — the kind of brief you’d hand a developer, except a compiler builds directly from it instead of a person typing code by hand. You describe what the tool needs to do — who uses it, what data it tracks, what happens when someone approves or rejects a request — and Remy drafts that description into a spec you read and approve before anything gets built.
From there, the compile step turns the approved spec into a deployed application: a real backend, a serverless SQL database, authentication, and a working interface, live at a URL. Change your mind about a field or a workflow step later, and the fix is updating the spec and recompiling — not filing a ticket with a vendor or waiting on an engineer’s calendar.
This is the structural difference that separates a compiler from a chat-based code generator. App builders that chat with you are prompt-driven code generators — you describe what you want, they emit code, and you keep re-prompting to refine it. Remy is spec-driven: the spec is the source of truth, and code is compiled output. That difference holds even as models improve — when a stronger model ships, the same spec recompiles into a better app, and nobody has to re-prompt their way back to where they were. What Is a Product Agent? covers this category distinction in more depth, and Product Agent vs Coding Agent: The Category Is Splitting in Two traces where the line falls.
How Does the Cost Actually Compare?
Here’s what the three branches look like side by side for a typical internal tool — something in the shape of a vendor approval workflow or an HR tracker.
| Buy (SaaS) | Build (engineer/contractor) | Compile (spec-driven) | |
|---|---|---|---|
| Upfront cost | Low (per-seat signup) | High (day rates × weeks) | Low ($100–$500 in tokens for a typical build) |
| Ongoing cost | Recurring monthly, rising with seats | Maintenance falls on whoever built it, or nobody | $99/mo flat platform fee + usage-based tokens |
| Fit to your workflow | Built for the average customer | Built to spec, if the spec was right | Built to spec, revised by editing the spec |
| What you own when it ends | Nothing — the subscription lapses | Code, if someone kept it organized | Standard TypeScript in a git repo, plus the spec |
| Time to first working version | Instant signup, weeks of configuration | Days to weeks | Often minutes to a few hours for a typical build |
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
The buy column never really ends — it’s a recurring stack compounding for as long as the company exists. The build column front-loads cost and back-loads risk: the tool is only as maintained as the person who wrote it is still around. The compile column swaps both of those for a flat platform fee plus metered token cost, and the token spend is visible in real time as the build happens, not billed after the fact.
What Do You Actually Own at the End?
This is where the ownership question — the one that actually matters two years later — gets decided. A SaaS subscription gives you a login. Stop paying, and there’s no asset left, just a gap where the workflow used to live. A contractor build gives you code, assuming someone kept it clean and someone else can read it.
A compiled build gives you both a spec and code: standard TypeScript in a git repo, readable by any engineer, exportable at any time, and not tied to a runtime that only executes on one platform. Remy builds and runs the software your team would otherwise rent. Describe what you need, and it ships as standard TypeScript in a git repo you own.
The spec matters as much as the code here. When the person who requested the tool moves to a different team, the spec is what tells the next person what the tool is supposed to do — not just what six-month-old code happens to do. That’s the same logic that makes a compiled build easier to hand off than a contractor’s undocumented repo.
For a sense of what this looks like across a handful of real workflows, Five Internal Tools You Can Ship with AI in an Afternoon walks through vendor approvals, CRMs, HR trackers, and inventory dashboards with a cost anchor on each one. Try Remy to see how a spec turns into a running app.
When Does Buying Still Win?
Compiling isn’t the right branch for everything, and pretending otherwise would be dishonest. If the workflow is genuinely generic — payroll, applicant tracking at real scale, anything where a mature vendor has already solved every edge case a hundred times over — buying still wins. You’re not paying for custom fit; you’re paying to not reinvent a wheel that’s already round.
The tools worth compiling instead are the ones stuck in the gap: specific enough that no SaaS product fits cleanly, but not big enough to justify a dedicated engineering build. That’s most internal tools. A deal tracker shaped around how a fund actually has long conversations with founders — not a generic sales pipeline — is exactly the kind of workflow that falls into this gap, and it’s the kind Remy is built for.
How Is This Different from a Coding Agent or a No-Code Tool?
Coding agents and product agents are for different jobs. Don’t mix them; pick one based on the workload. A coding agent like Cursor or Claude Code edits code inside a project you already have — useful once the tool exists and needs a fix, not for getting from zero to a deployed app. Remy vs Cursor: When You Need a Product Agent, Not a Coding Agent covers that distinction in depth: different layer, different job.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
AI app builders like Lovable are prompt-driven code generators with a starter frontend — you chat, they generate code, and you keep re-prompting to refine it. Remy vs Lovable: Only One Ships a Native Full Stack breaks down why the backend most of them ship tends to be third-party infrastructure bolted on, rather than a native full stack compiled from one spec. No-code platforms like Retool or Bubble trade code ownership for speed — you move fast, but you don’t own what comes out the other end. Compiling gives you both: real generated code plus the spec as the record of intent, owned outright.
The category behind all of this — an AI system that ships a full application from a spec instead of editing code from a prompt — is what a product agent actually is, and it’s worth reading if the build-vs-buy framing above raised the obvious next question: what is this thing, technically?
FAQ
Is it actually cheaper to build an internal tool with AI than to buy software? For a specific, narrow workflow, often yes — a typical Remy build runs $100–$500 in AI tokens plus a $99/month platform fee ($79 annual), versus a recurring per-seat SaaS subscription that never stops. For a workflow a mature vendor has already solved at scale, buying is usually still cheaper.
What happens to a compiled internal tool if the person who requested it leaves? The app and its spec stay in the company’s repo, not on anyone’s personal account. Someone else can read the spec to understand what the tool is supposed to do and pick up where the previous person left off.
Do I need engineering skills to build an internal tool this way? No. You describe the tool in plain language, review the spec that gets drafted from that description, and approve it. The compile step generates the actual code.
Can I change the tool after it’s built? Yes — update the spec to describe the change and recompile. That’s the same loop used for the original build, not a support ticket to a vendor.
Is the resulting app locked to one platform? No. The output is standard TypeScript in a git repo, exportable and runnable elsewhere at any time. Hit Publish to deploy it to a live URL whenever it’s ready.
How does Remy stay useful as AI models improve? The spec is the source of truth, not the chat log. When a stronger model ships, the same spec recompiles into a better app — nobody has to re-prompt their way back to where they were.
What kinds of internal tools are the best fit for compiling instead of buying or building? Approval workflows, trackers, dashboards, intake forms — anything specific enough that generic SaaS doesn’t fit well, but not so large it needs a dedicated engineering team.
How long does a typical build take? A typical internal tool often takes minutes to a few hours from first description to a deployed application; more complex, multi-module tools may take longer.
The Bottom Line
Build vs. buy was never really a satisfying choice for internal tools — one option never fit, and the other cost more than the problem was worth. Compiling a spec into a deployed app closes that gap: the cost sits closer to a subscription, the fit sits closer to a custom build, and what comes out the other end is something the team owns instead of rents.
Remy builds and runs the software your team would otherwise rent. Describe what you need, and it ships as standard TypeScript in a git repo you own.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
