Skip to main content
Building products with AI

Building products with AI

Build or buy an AI feature: the honest trade-offs

Building AI features in-house gives you control but costs time and money. Buying existing tools is faster but locks you into someone else's design.

· 5 min read · Product strategy · Build versus buy · AI implementation · Cost analysis

The question sounds simple. But it hides a harder one: what do you actually need, and how much is it worth.

Let's start with what's true about both paths.

Building: you own the result

When you build an AI feature yourself, you own it. You control how it works, what data it sees, when it changes, and how much it costs to run. If it becomes central to your business, that matters.

Building also means you can make it fit the exact way your customers work. A dental clinic in Kelowna might need a tool that reads patient notes in a specific format and flags allergies before the hygienist sees them. A distributor in Calgary might need to match orders to inventory in a way no off-the-shelf product does. When the feature is that specific, building can be worth it.

The cost is time and money. A simple feature—something that reads documents, extracts data, and files it somewhere—typically takes 3 to 6 months and costs $40,000 to $150,000. That's with a team that knows what they're doing. If you're learning as you go, add another 2 to 3 months and $20,000 to $50,000. You also need to maintain it. Budget 10 to 20 hours a month for updates, fixes, and keeping it running.

There's a hidden cost too: opportunity. While your team builds this one feature, they're not building the next one. That matters if you're a 12-person software company in Gastown with a roadmap that's already full.

Buying: you move fast

Buying an existing tool is faster. Most tools work in weeks, not months. Setup and training take 5 to 20 hours. Costs are usually $500 to $5,000 a month, depending on volume and the vendor.

The trade-off is that the tool was built for many customers, not yours. It might work 80% of the way you want it to. The other 20% either doesn't matter, or you change your process to fit the tool.

A property manager in Surrey might buy a tool that reads lease documents and extracts key dates. The tool works well for standard leases. But it misses clauses that are specific to their market or their contracts. They either accept that limitation or hire someone to review the tool's work before acting on it. That's fine—it's still faster than building.

The other risk is dependency. If the vendor changes their pricing, raises it 50%, or shuts down, you have to move. You don't own the data pipeline or the logic. You're renting.

The honest trade-off framework

Here's how to decide, without the sales pitch.

Build if: - The feature is core to how you compete. Your customers chose you partly because of this capability. (A plumber in Richmond who builds a tool to quote jobs accurately on-site might use it to win jobs that competitors lose.) - You have an engineering team with 3 to 6 months of capacity. Not "maybe we'll find time." Actually available. - The feature will save you or your customers enough money to justify $40,000 to $150,000 upfront. Do the math. If you're saving 5 hours a week and your time is worth $50 an hour, that's $13,000 a year. The build costs $80,000. It pays for itself in 6 years. That's a weak case. - You need to protect customer data or have strict privacy rules. Building keeps it in-house.

Buy if: - You need it in the next 4 weeks, not 4 months. - You don't have an engineering team, or they're booked. - The tool already fits 70% or more of your workflow. You can live with the other 30%. - You want to test the idea before investing in building.

Do both if: - You buy a tool to prove the idea works and customers want it. - After 2 to 3 months, you know the feature is worth owning. - You build the version that matters most to your business, and keep buying for the parts that don't.

An accounting firm in Burnaby might buy an invoice-reading tool first. After three months, they see it's saving 6 hours a week. But it's missing their specific tax codes, and they're manually fixing it 30% of the time. Now it's worth building. They hire a developer to build a tool that reads invoices and applies their tax codes automatically. The bought tool becomes a backup. The built tool becomes their edge.

The person in the loop

Whatever you choose, keep a person involved in decisions that matter.

If you buy a tool, someone needs to review its output before it affects a customer or a transaction. If the tool misreads an invoice amount or flags the wrong priority, a human catches it.

If you build, someone needs to decide what happens when the tool is unsure. Does it ask for help, or does it guess. That choice affects your customer experience and your liability.

AI tools are good at routine work. They're not good at judgment calls. Don't automate those away.

Where to start

  • Write down what the feature needs to do, in one paragraph. Include the decision it makes or the data it extracts. Then estimate: how many hours a week does it save, and for how many people. Multiply by your hourly rate. If it's less than $20,000 a year in savings, it's probably not worth building.
  • Spend 2 hours finding three existing tools that do something close to what you need. Talk to the vendors. Ask for a trial. See how much of your workflow they cover without you changing anything. If one covers 70% or more, buy it for a month and test.
  • If you decide to build, talk to a developer who has built AI features before. Get a real estimate: time, cost, and maintenance. Don't guess. Then decide again with real numbers, not hopes.

Have an AI product in mind?

We build and ship the whole thing, the same way we build our own products. From first prototype to a live product your customers pay for.