AI made building your own software cheaper than buying it

You can have a working version of a tool your roofing company actually needs — running on your real jobs — in weeks. Not a mockup, not a slide deck. Something your office uses on Monday.

That sentence would have been untrue a few years ago, which is why most roofing companies run on software bought off the shelf. The barrier was never the idea. It was that building took months of engineering time, so nothing justified the cost below a certain company size.

That barrier is what collapsed, and it changes what is worth building rather than just what is worth buying.

What actually changed

The honest version is narrower than the slogan, and worth stating carefully.

What got dramatically faster is the part of building that is well understood and repetitive. The plumbing. The forms. The reports. The hundredth variation on a workflow somebody has already built a thousand times. That's a large share of what any business tool actually is.

What did not get much faster is the part that requires knowing your business — what a job means at your company, which prices apply to which product line, what happens when a customer changes their mind after the material order goes in, why insurance work is handled differently. That still takes a person sitting with your team and paying attention.

So building didn't become free. It became small. And small changes everything, because the risk of trying drops faster than the cost does. A project you can attempt without betting the year is a fundamentally different proposition from one you can't.

What building one actually looks like now

Worth walking through concretely, because "we can build it faster" means nothing without the mechanics.

Week one is the data model, and it comes from a conversation. Not a requirements document — a session with whoever runs the office, working out what a job is at your company. What stages it moves through, including the one between sold and scheduled that no product ships with. What fields decide pricing. What the exceptions are. That produces a schema: jobs, customers, properties, quotes, line items, stages, and the relationships between them. Everything downstream depends on getting this right, and it is the one part that cannot be hurried.

Then the edges get connected. Whatever already holds your data gets read: measurement providers expose ordering APIs returning structured takeoffs, accounting packages have well-documented APIs, and anything without one usually offers a scheduled export. Where a source is only ever a PDF — a supplier confirmation, a scanned permit — document extraction pulls the fields out, because these documents have consistent layouts and the values are always in the same place.

Your price list becomes a lookup rather than a rewrite. The spreadsheet you already maintain gets ingested and mapped once to line items. You keep maintaining the spreadsheet. The system reads the current version, and flags anything missing rather than guessing.

Your rules get encoded explicitly. Waste factor by pitch. Steep-slope multipliers above a threshold. Minimum charges, access premiums, tear-off by layer count, the different treatment for insurance work. Each is a few lines of logic. Collectively they're what makes the system yours.

Then it runs on real jobs with a person in front of it. Not a pilot in a sandbox — live work, with the output reviewed before it reaches anyone. That's where you find the exceptions nobody mentioned in week one, because there always are some.

The reason this fits in weeks rather than quarters is that only the first and fourth steps genuinely need your business. The rest is well-trodden work that used to be typed by hand and now largely isn't.

The arithmetic quietly flipped

Here's the part worth thinking through slowly, because it's structural rather than a matter of price tags.

A subscription and a build are different shapes. A subscription is a line that runs forever and slopes upward — it renews, it rises on somebody else's schedule, and on most tools in this trade it grows every time you hire. A build is mostly a one-time cost, after which what remains is infrastructure that doesn't care how many people you employ.

Two lines like that cross. They always cross. The only real question is when, and that depends on two things you already know: how many people will be using it in three years, and how much of your current stack it would actually replace.

That's why the comparison people reach for — build cost against monthly fee — is the wrong one. The right comparison is the total of everything a build would retire, over the period you'd actually keep it, against the build plus what it costs to run. Do it over five years rather than one, and include the hires you're planning, because that's where the shapes diverge.

For most companies the answer is no longer obvious, and for a growing one it's usually not close. That's new. Ten years ago it wasn't a calculation worth doing.

What this means for a company your size

The interesting consequence isn't that software got cheaper. It's who it became available to.

Purpose-built systems used to be something enterprises had, because only an enterprise could absorb the build. A fourteen-person roofing company got the same products as everyone else and adapted around them — worked around the missing stage, kept the spreadsheet, hired the admin who holds it together.

That gap is what closed. The tools that were once only worth building for a thousand-seat company are now worth building for a company with one office, because the build no longer has to be amortised across a thousand users to make sense.

It also means starting small is a real option rather than a consolation. One narrow flow, working on live jobs, is a sensible first project now — not a pilot that has to justify a platform behind it. If it doesn't earn the next piece, there is no next piece, and you still own what was built.

The part that deserves scepticism

Software written faster can also be written carelessly, and that bill arrives later — when something needs changing and nobody can safely change it.

This is a real risk, and anyone waving it away is selling. What makes it manageable isn't optimism, it's scope and safeguards. A small system doing one job is a small system to verify and a small system to fix. A human approving anything that reaches a customer means mistakes stay internal. And a system that stops rather than guesses when it breaks turns a potential disaster into a Tuesday-morning annoyance.

The same conditions that make a first project achievable are the ones that make it safe, which is not a coincidence — the discipline is the same discipline. There's a fuller version of that argument in what you can actually have running in 30 days.

What you end up with

The reason any of this matters isn't the cost. It's what you hold at the end.

A subscription buys permission to use something this month. A build, done properly, leaves you with the system itself — the source code, running in your own accounts, maintainable by any competent developer. Nobody can raise the price, discontinue it, or decide your business no longer fits their roadmap.

That distinction is worth more than the arithmetic, and it's argued in full in own your software instead of renting it forever.

Where building is still the wrong call

Cheaper doesn't mean always right, and the cases where buying wins are worth knowing.

When the work is genuinely standard. If your process looks like everyone else's, off-the-shelf products are well made and inexpensive. Building pays where a business is specific — its pricing rules, its job flow, the things competitors don't do.

When a good tool already fits. If a product matches how the team works and nobody is fighting it, replacing it is an expensive way to acquire a migration.

When nobody has the time. A build needs a few hours from someone who genuinely knows how the company runs. In the middle of a season that person doesn't exist. It'll still be worth doing in November.

When reliability matters more than fit. Some jobs should be boring and well-tested rather than tailored. Anything touching payroll or tax filing is usually better bought.

What to do this week

Don't take anyone's word for the arithmetic. Do the two-sided version yourself.

1. Total the buy side over five years.Not this month — five years, including the people you plan to hire, at list prices rather than whatever promotional rate you're on now.
2. Get one real quote for the build side.A scoped estimate for a specific job beats every industry average, all of which are made up by somebody with an interest.
3. Compare only the overlap.What a build would genuinely retire, against the build plus what it costs to run. Not your whole software bill against zero.

That comparison takes an afternoon, and it's the only version worth trusting, because both numbers are yours rather than borrowed from an article.

If it comes out in favour of what you already have, keep what you already have. That's a perfectly good outcome, and it's a much better thing to learn in an afternoon than two years in.