Own the code: building internal tools over rented software

Every subscription you pay rents you a workflow you do not control, on terms that can change without your say. For the tools at the center of how you work, owning the code is now cheap enough to be the obvious choice. This post is about when to build instead of rent, how we build internal tools fast without drowning in maintenance, and what owning the code and the data actually gives you.

What you'll learn

• The real cost of a rented tool, beyond the monthly price
• The build-versus-rent line we draw, and where it sits
• How we ship an internal tool in days, not months
• The maintenance trap, and how we avoid building a second job
• What owning your tools and your data makes possible

The old way: rent everything, own nothing

The standard advice for a decade was to never build what you can buy. Rent the dashboard, rent the form, rent the analytics, rent the automation. For a long time this was right, because building was slow and expensive and the rented tools were good enough.

Two things changed. Building got fast, because a person with a model can now produce working software in an afternoon that used to take a developer a week. And renting got more expensive in ways that do not show on the invoice.

The hidden cost of a rented tool is not the monthly fee. It is the three things you give up: the data lives on their servers in their format, the workflow bends to their design instead of yours, and the price and the rules are theirs to change. You are not buying a tool. You are renting a dependency, and dependencies get more expensive exactly when you can least afford to switch.

The build-versus-rent line

We do not build everything. Most software should still be rented, and we rent plenty. The line we draw is about centrality and fit.

We rent when the tool is a solved commodity that everyone uses the same way. Email sending, payments, file storage. There is no advantage in owning these, and the rented versions are excellent.

We build when the tool is central to how we specifically work, and no rented version fits without forcing our process into its shape. Our content tracking, our review dashboards, the small automations that glue our pipeline together. These are ours because the fit is the value, and a generic tool destroys the fit.

The test is one question: if this tool's vendor doubled the price tomorrow, would it hurt. If yes, and the function is specific to us, we should probably own it. If yes, but the function is a commodity, we should keep an exit ready. If no, rent it and never think about it again.

How we ship an internal tool in days

The reason building used to lose was speed. That argument is gone. Here is how we ship.

• **Start from the data, not the screen.** We define what the tool needs to know first, often a single **Airtable** base or a flat file. Get the data shape right and the tool is half built.
• **Build the thin slice that does the one job.** Not a platform. One screen that does the single thing we need. We write it with a model doing the boilerplate and a person doing the logic and the decisions.
• **Run it on ourselves the same week.** An internal tool nobody uses is worse than no tool, so it goes into real use immediately, and the real use tells us what to fix.

We built our own content review dashboard this way. It reads from our content records, shows what shipped and what is pending, and flags the pieces that miss a standard. No vendor sold us that, because no vendor knows our standards. It exists because owning the code meant we could encode our exact rules, not approximate them.

A worked example: the review dashboard we own

Our content review dashboard is the clearest case. We publish content daily across many channels, and we needed to see, at a glance, what shipped, what is pending, and which pieces miss a standard. We looked at rented project tools. Every one of them could track tasks. None of them knew our standards, because our standards are ours: no banned words, no fabricated numbers, each format fits its channel, the open and close are human-written.

So we built it. It reads from our content records in Airtable, renders a simple page that lists every piece with a green or yellow badge, and flags the specific standard a piece misses. A generic tool would have made us approximate this with custom fields and manual checks. Owning the code let us encode the exact rules, run them automatically, and change them the day a standard changes.

The build was days, not months, because we kept it thin. One data source, one screen, one job. The model wrote the boilerplate, the rendering and the table layout; we wrote the rules and the logic, because the rules are the value and a model does not know them. It went into real use the same week, and the real use immediately told us the badge logic was too lenient, which we fixed in an hour.

The honest receipt: no vendor could have sold us this, because no vendor knows what "misses a standard" means for us. That sentence is the entire argument for owning the central, specific tools. The fit is the value, and you cannot rent a fit.

The maintenance trap

The honest counterargument to building is maintenance. Every tool you own is a tool you must keep alive, and a graveyard of half-maintained internal tools is its own kind of expensive. This is real, and ignoring it is how "build it ourselves" becomes a second job nobody signed up for.

We avoid it three ways.

1. **Build small.** A thin tool that does one job has almost nothing to maintain. Complexity is the maintenance, so we refuse the complexity.
2. **Build on boring foundations.** We do not build on the newest framework. We build on the dull, stable, well-documented one, because the goal is a tool that still runs in two years without our attention.
3. **Kill tools that stop earning.** An internal tool that is no longer used gets deleted, not maintained out of guilt. Owning the code includes owning the decision to retire it.

The thing that makes building safe is keeping each tool small enough that retiring it costs nothing. A small owned tool is a free option. A large owned tool is a liability wearing a useful disguise.

What this makes possible

Owning the tools at the center of your work, and the data inside them, changes your position.

Your workflow stops bending to someone else's product decisions. Your data stays in a form you can read, export, and move, so no vendor holds it hostage. Your costs stop drifting upward on renewal terms you did not write. And the specific advantages of how you work, the fit that a generic tool flattens, become things you can encode and keep.

The intellectual property point matters most over time. The tools you build become an asset that compounds, a record of exactly how your business works, owned outright. The tools you rent leave nothing behind when you stop paying. One builds equity. The other builds receipts for access you have to keep buying.

Rent the commodities. Own the things that are central and specific to you. Keep each owned tool small enough to retire without pain. That is the line, and it is the line that lets you own your workflow and your IP instead of renting your own way of working back from someone else.

We build our own tools exactly this way, and the dashboard behind this blog is one of them. The experiments at [temerarii.xyz](https://temerarii.xyz) show the public side of what we build, and the rest of the [blog](/blog/) takes the other systems apart, code and all.

See the live system →

Written by Dominique Davis, Founder, Temerarii Media.