A patent search before building a product is the cheapest engineering decision you will ever make, because it costs a few hundred dollars and a week of calendar time to find out whether the thing you are about to spend six months and six figures building is already owned by someone else. Most non-technical founders treat patents as a step that comes after the product works. By then the search has stopped being research and started being damage control.
We run a patent search before building a product at the start of nearly every hardware and deep-tech engagement, and regularly on software work where the mechanism is novel. It is not a legal ritual. It is the fastest way to read what an entire industry has already tried, what failed quietly, and where the genuinely open ground sits. This guide covers what the search finds, what it costs, how long it takes, and how to turn the results into a build plan instead of a filing cabinet.
What a patent search before building a product actually tells you
It tells you whether your core mechanism is free to use, who else is working in your space, and what has already been tried and abandoned. A published patent is a technical disclosure written by an engineer who had funding, prototypes, and lawyers checking every claim. For a founder entering a new category, it is the densest technical literature available and almost all of it is free to read.
A useful patent search before building a product answers four separate questions, and confusing them is where teams go wrong:
- Can we build and sell this without being sued? This is freedom to operate. It concerns live, in-force patents in the countries where you plan to sell.
- Can we own this? This is patentability. It concerns everything ever published anywhere, including expired patents and academic papers, because expired art still blocks your application even though it no longer blocks your product.
- Who is already here? Filing activity is a competitive map. A company filing eight applications a year in your niche has an R&D budget and a roadmap.
- What has already been solved? Expired patents are public domain engineering. You can copy them outright, and on hardware projects this routinely saves months of prototyping.
The cost of finding out late
Late discovery forces a redesign of the part of the system everything else depends on. When a blocking patent surfaces after a working prototype exists, the fix is rarely cosmetic. The patent covers the mechanism, so the mechanism changes, and every subsystem built on top of it changes with it. In our experience that lands somewhere between thirty and sixty percent of engineering hours already spent, plus the schedule slip.
There is a timing trap that catches almost everyone. Patent applications stay secret for eighteen months from the priority date in Canada, the United States, and under the international system administered by the World Intellectual Property Organization. A competitor could have filed fourteen months ago on exactly your idea and no database on earth will show it to you today. This is not a reason to skip the search. It is a reason to run it early, then run a short refresh before you commit to tooling or a public launch.
What a patent search before building a product costs by comparison
The numbers below are the ranges we see in Canadian projects as of 2026. They are order-of-magnitude guides, not quotes, and professional fees vary with technical complexity.
| Type of search | Typical cost (CAD) | Typical turnaround | What it is good for |
|---|---|---|---|
| Self-run knockout search | $0, plus 6 to 12 hours of your team’s time | 2 to 5 days | Killing obviously blocked ideas before you spend anything |
| Professional patentability search | $1,500 to $3,500 | 2 to 4 weeks | Deciding whether to file, and drafting around existing art |
| Freedom-to-operate opinion | $8,000 to $20,000 per jurisdiction | 4 to 10 weeks | Pre-launch, pre-manufacturing, and investor due diligence |
| Redesigning a built product around a blocking patent | $60,000 upward, plus 3 to 9 months | Whenever you find out | Nothing. This is the outcome the search exists to prevent. |
How to run a patent search before building a product
You can do the first pass yourself in a week, and you should, because nobody understands your intended product as well as you do. Bring in a registered agent once the first pass turns up something close to your mechanism, or once you are about to spend real money on tooling, moulds, or a manufacturing run.
Step one: describe the function, not the product
Patents are written in functional language, not marketing language. Your “smart inventory tag for contractors” appears in the database as something closer to “wireless asset-tracking device with proximity-based state change.” Write one sentence describing what your product physically does, strip every brand word and every industry buzzword, then list the synonyms an engineer from 1998 would have used. Those synonyms are your search terms.
Step two: search the free databases first
The paid tools are better at ranking, not at coverage. Start a patent search before building a product with the Canadian Patents Database from the Canadian Intellectual Property Office, then widen to Google Patents for full-text search across dozens of national offices, and Espacenet from the European Patent Office when you need the classification codes. Once you find one patent that is genuinely close to your idea, stop keyword searching and follow its citations forward and backward. Citation chains find the relevant art that keywords miss, because examiners have already done the categorising work for you.
Step three: read the claims, not the abstract
The abstract is a summary and has no legal weight. The numbered claims at the end define exactly what is owned, and claim one is the broadest. Read it as a checklist: if your product does not include every single element listed in claim one, you are almost certainly outside that claim. One missing element means no infringement of that claim. This single habit separates founders who panic at every scary-looking patent from founders who can tell a real obstacle from a irrelevant one.
Step four: decide with your engineering team in the room
A patent problem is usually an engineering problem with a legal deadline attached. When your lawyer says a claim requires a magnetic sensor and your engineer says the same measurement is achievable optically, you have a design-around, not a dead end. Those conversations only happen if legal and engineering read the results together. This is the part our clients most often ask us to sit in on, and it is where our product engineering services earn their keep.
What the search does not do
A patent search before building a product is not a guarantee and not a legal opinion. It does not surface applications still inside the eighteen-month secrecy window, it does not cover trade secrets, and a self-run search does not carry the professional liability that a registered agent’s written opinion does. Treat the first pass as a risk filter that removes the obvious problems cheaply, and escalate to a formal opinion when the money at stake justifies it.
Where AI helps, and where it quietly hurts
AI tools genuinely improve the first hour of searching and genuinely mislead you in the last. Semantic search models are good at the hardest part of a patent search before building a product, which is finding documents that describe your idea in vocabulary you never would have guessed. Feed a model your plain-English product description and it will surface conceptual neighbours that keyword search misses entirely.
Where it goes wrong is summarising. A language model asked whether a patent blocks you will produce a confident, readable, sometimes wrong answer, because claim interpretation depends on the prosecution history, the jurisdiction, and case law the model is not reading. Use AI to widen the net, then read the claims yourself. We build this pattern into client systems through our AI integration services: the model handles recall, a human handles the decision that carries consequences.
Turning the results into a build plan
The output should change what your engineers do on Monday. A search that ends in a PDF nobody opens was wasted money. Ours end with a one-page summary that names the two or three patents worth caring about, states which claim elements they hinge on, and lists the specific design constraints the build now carries. That page goes into the technical specification alongside the performance requirements, because a constraint your team does not know about is a constraint they will violate.
The results also change sequencing. If the crowded ground is the hardware mechanism and the open ground is the software layer, build the web and app development side first and prove demand while the mechanism question gets resolved properly. We have had clients reach paying customers on a manual back end while the patentable component was still being redesigned.
A practical sequence to follow
Run it in this order and the whole exercise fits inside two weeks and a modest budget.
- Write the functional description and synonym list before you open a database.
- Spend one working day on free-database searching, following citations rather than keywords once you find a close hit.
- Shortlist anything whose claim one looks close, and read claim one element by element against your product.
- If the shortlist is empty, proceed to build and schedule a refresh search at the six-month mark.
- If the shortlist is not empty, bring in a registered agent before any further engineering spend.
- Record the constraints in the technical specification, not in an email thread.
Every founder who has had to rebuild a core mechanism will tell you the same thing: the research was available the entire time and free to read. A patent search before building a product is not a hurdle placed in front of the interesting work. It is the first part of the interesting work, and it usually makes the design better, because reading what a dozen well-funded teams already tried is a shortcut to knowing what will not work.
Prototype Toronto works with non-technical companies as their technical partner across prototyping and product engineering, AI development and integration, and digitalisation. If you have an idea and want to know whether the ground is clear before you commit a budget to it, book a free consultation and we will walk through the search and the build plan together.
Frequently Asked Questions
What is a patent search before building a product, and why does it come first?
It is a check of existing patents and published applications before you spend money on design or tooling. Running a patent search before building a product tells you whether someone already owns the approach you planned. Finding that out at the sketch stage costs days. Finding it after tooling costs months.
How much does a patent search cost and how long does it take?
A do-it-yourself look through free databases such as the Canadian Patents Database, Google Patents and Espacenet takes a few hours and costs nothing. A professional patentability search by a registered patent agent usually runs about $1,500 to $3,000 and takes one to three weeks. Freedom-to-operate searches, which cover commercial risk, cost several times more.
What do I do if the search turns up a patent that covers my idea?
Check three things: whether the patent is still in force (protection lasts twenty years from filing and lapses early if maintenance fees go unpaid), whether it is registered in Canada or only elsewhere, and what the claims actually cover. Claims are narrower than titles suggest, so a design change often puts you outside them.
Does a clean search mean I am safe to build?
No. Applications stay confidential for eighteen months after filing, so recent filings are invisible to any search. A clean result lowers risk, it does not remove it. Treat it as one input alongside your own commercial judgement, and repeat the search before you commit to tooling or a production run.
Should a patent search change what I build, or just whether I file?
Both. Expired and lapsed patents are free to use, and they are detailed engineering documents, so they show you what has already been tried and what failed. Teams often come out of a search with a better design than they went in with, not only a yes or no answer.
