Last updated: 30 September 2026

Custom software or off the shelf, for a Quebec SME

A way to choose between a product you can buy and software built for you, with no invented numbers. Written for SMEs in Montreal and Quebec.

Draft. SignalOrange is still reviewing this text. Do not cite it as the company's final position, and do not treat it as professional advice.

A draft of a method, not a study. There is no success rate here, no testimonial, and no “SMEs save X”. The point is a grid you can fill with your own facts.

The wrong question

“Is custom software better than off the shelf?” has no useful answer. A product that already covers the work, with a price you understand and a way out, beats software written for you almost every time. A product that makes you change the business so it fits the screens, or that sends your files somewhere you cannot explain, costs more than it looks.

The useful question is narrower. What in the way you work is common to many firms, and what is the reason clients pick you?

When off the shelf wins

Buy the product when the work is standard and the product already does it.

  • General accounting, ordinary payroll, email, video calls.
  • A process you are willing to adjust so it matches the tool, because it is not what sets you apart.
  • A need you can describe in one sentence the vendor already has on their page, with no “except at our shop”.
  • A team with nobody to keep custom software alive in five years. Off the shelf at least has a publisher whose job it is. You still have to check that they will be there, and at what price.

In those cases, custom software development is often a slow way to repurchase what already exists. The hidden cost is not the licence. It is the project, the training, and the upkeep.

When custom wins

Writing the software is worth it when the process is the service, or when the products on the market leave a hole you fill by hand every week.

  • People copy the same data between three systems, and the mistakes cost hours, not minutes.
  • The trade’s vocabulary (a quote that becomes a job, a rule that belongs to your sector) is in no product, and working around it takes longer than writing it.
  • You have to keep certain information in Quebec, or explain to a client where it goes. The guide to Law 25 and AI APIs covers that. A product that will not answer those questions is not “cheaper”. It is incomplete.
  • You have already paid for brittle integrations, and every vendor update breaks them.

Custom is not “more modern”. It is a commitment to maintain it. Someone has to change it when the work changes. If that person does not exist, at your company or at a named supplier, do not write the software.

The path most firms actually take

Most SMEs in Montreal and Quebec do not have to pick a side for everything.

  1. Buy off the shelf for what is common. Accounting, email, signatures, payment.
  2. For a month, write down the actions the tool does not do. Not wishes. Actions. “Every Monday, Marie copies the quote into the invoice.”
  3. See whether a setting, a connector you can already buy, or a small automation closes the hole.
  4. Write custom software only for the hole that remains, with a clear edge. The homegrown software talks to the product. It does not replace the whole thing.

Revisit the split. A homegrown module that grows until it redoes the accounting is a reason to stop, not a point of pride.

Questions that matter here

The Montreal and Quebec market adds a few questions that generic grids skip.

  • Can the people who do the work use the contract and the interface in French, not only the person who buys?
  • Is the invoice in Canadian dollars, or will you explain the exchange gap every month?
  • Where is the data, and who are the subprocessors? If the software calls an AI API, read the Law 25 guide before you sign.
  • What happens if you leave? Export, format, delay, and does the export contain enough to start again somewhere else?
  • Who answers when it breaks, in which time zone, and is it a person or a form?
  • Is the entry price the price, or is there a step the moment you pass a number of users, files, or calls?

For custom development the questions change target, not kind.

  • Who owns the code and the data?
  • What is delivered in the first increment, in weeks, not in “phase 1”?
  • Who maintains it after it is in production, and how often?
  • How do you check that it works on your real files, not on a demo?

SignalOrange, in Montreal, does architecture and custom software for SMEs, and publishes its own products. This paragraph says so the source is clear. It does not replace the grid.

Compare cost without a magic number

Do not ask “what is the return” if nobody has measured the work as it is. Ask for a list, and put your own amounts on it.

Off the shelf. Licence or subscription, setup, your people’s time to enter data and change habits, integrations, and the cost of leaving later.

Custom. Discovery, building, going to production, then upkeep every year. Add your people’s time to explain the work and to check it. A project with no upkeep line is not priced.

The status quo. Hours spent copying, mistakes, tools you already pay for and do not use. This line is often the only one the team can fill without inventing anything.

Compare over three years, not the first month. A low subscription with a heavy setup, and a custom project with a yearly upkeep, do not show up on the same invoice.

Two weeks, not a tender

If you are stuck, do this before you ask for a quote.

  1. Write the work in ten sentences, from the point of view of the person who does it. Not from the point of view of the software.
  2. Circle the sentences a product already covers. Keep the names of products you have actually tried, or that you pay for.
  3. For the sentences that remain, note how often. Every day, every file, every month.
  4. For each remaining sentence, say whether it touches personal information or a transfer outside Quebec.
  5. Only then, ask a supplier two things. What their product does not do. And what would have to be written.

That is enough for a serious conversation, in Montreal or elsewhere in Quebec, without freezing a forty-page specification.

What this note does not decide

It does not say Elixir, or any other tool, is the right choice. It does not say a smaller firm should avoid large products. It does not give a typical timeline. A one-page quote and a system that carries production do not share a calendar, and inventing an average would be a lie.

If the next question is using an AI API inside that software, the Law 25 and AI APIs guide is the right next read.