Development and artificial intelligence
Custom application development for SMBs in Quebec: web, internal and mobile
When no product on the market matches the way you work, you are left with two options: bend your operations to fit the tool, or have the tool built. OKTO Solutions builds web applications, internal business applications and mobile apps that follow your real processes, connect to the systems you already run, and belong to you.
A custom application is software written for one business. It follows that company’s vocabulary, its steps and its rules instead of a vendor’s. In Quebec, an SMB gains the most when a critical process still lives in a spreadsheet, or when purchased software covers only a fraction of the real work.
The starting point
What exactly is a custom application?
It is software written for one business, yours, starting from the way work actually gets done in your shop. The screens use your words. The steps follow your sequence. The rules are yours, including the ones nobody ever wrote down and everybody applies anyway. Most of our projects do not start from a blank page: they are bridges between two systems that refuse to talk, interfaces that replace a spreadsheet nobody can control any more, or the rescue of an in-house program written ten years ago by someone who has since left. A custom application can be a full ERP, a portal for your clients, an internal approval tool or a management dashboard. Which one it turns out to be gets decided after looking at the problem, never before.
- The software follows your process, instead of your teams working around the software
- It plugs into what you already run: accounting, Microsoft 365, ERP, CRM
The real process gets drawn before a single line of code is written.
- You do not pay for modules nobody opens
- Artificial intelligence features live inside the tool, not in one more browser tab
An honest question
When should you build, and when should you buy?
Building is justified when an important process no longer fits the tools in place and working around it burns hours every week. It is not justified when a product on the market already does the job. We always check which of the two applies first, and we say so plainly, even when the answer costs us the contract.
Build when...
- A critical process rides on a spreadsheet three people edit at once and nobody can say which version is the real one
- Two systems do not talk and somebody bridges them by hand every morning
- You pay for software you use a quarter of, and the module you actually need never makes the vendor’s schedule
- Your clients keep asking for a portal so they can see their files without picking up the phone
- Your field crews write on paper and retype it at the office in the evening
- Your edge over competitors is precisely your way of doing things, the one no vendor will ever reproduce
Buy off the shelf when...
- The function is standard and governed by outside rules: accounting, payroll, tax filings
- The need is urgent and a subscription settles it this week
- Your way of working is nothing special and you are willing to line it up with the tool
- The volume is too small to justify building and maintaining anything
- Proven software already exists in your industry and your competitors all live with it
- Nobody on your side can spare the few hours a serious scoping exercise takes
Comparison
Off-the-shelf software or a custom application
The four points where the two approaches genuinely part ways. The rest, most of the time, is detail.
| What we compare | Off-the-shelf software | Custom application |
|---|---|---|
| Upfront cost | Low. You subscribe and start the same day, usually per person per month. | Higher at the start, because scoping and building come before use. After that the cost drops to hosting and improvements. |
| Fit with how you work | You adapt to the tool. The available settings stop where the vendor decided they stop. | The tool adapts to you, including the odd rules that make you efficient. A change in procedure becomes a change in the application. |
| Dependence on the vendor | Your data lives on their side. A change of pricing, policy or ownership is imposed on you. | The code, the database and the hosting are in your name. You can change development teams without changing tools. |
| How it evolves | You vote for a feature in a forum and you wait. The roadmap serves the vendor’s largest account first. | The queue is yours. A request made in January can be in service in February if it fits the agreed scope. |
There is a third road, the homemade spreadsheet: free, instant, honestly good enough for a long time. It breaks the day several people touch it at once, because it has no access control, no history and no structured backup.
Project types
The projects we build most often
Six families cover the large majority of mandates. They overlap: an ERP almost always ends up with a portal, and a portal always ends up with integrations.
Business ERP
The core of operations: quotes, work orders, production, inventory, invoicing, timesheets. We build module by module rather than all at once, starting with the one that hurts the most.
Client portal
Your clients see their files, their documents, their invoices and the status of their requests without calling. The phone stops ringing for questions that already have an answer.
Integration between systems
A bridge between your accounting, your CRM, your online store and Microsoft 365. Information travels once, in the right direction, with no overnight copy and paste.
Clerical work taken off the desk
Invoice entry, filing attachments, reminders, the Monday morning report. Those tasks are the first to go, and nobody misses them.
Internal application
A tool for one team: file tracking, approvals, field inspections, equipment management. Often the direct replacement of a spreadsheet that outgrew itself.
Taking over an existing application
An in-house program that is still useful but that nobody dares touch. We examine it, keep what holds, replace the rest, and document it so the next person can find their way.
The method
How a project runs, step by step
We deliver in usable slices instead of one block at the very end. You see the software early, you correct it while corrections are still cheap. That is the difference between a project that goes off the rails and a project that gets adjusted. Every slice goes out for trial in a test environment, your teams run real data through it, and what they tell us shapes the next slice. Priorities can move as long as they stay inside the scope agreed at the start.
- Scoping. We look at how the work gets done today, with the people who do it. We write down what the application must cover, what it will not cover and what it connects to. You leave with a scope and a schedule before committing to anything.
- Mock-up. We show the screens before writing code. Fixing a screen takes minutes; fixing an application already built takes days. This is also where your teams recognize their own work, or tell us we misunderstood it.
- Build in slices. Each slice is handed to you for trial. You follow progress as it happens instead of waiting for a final demo that arrives too late to change anything.
- Migration and go-live. We bring your existing data over, train the users, then switch. The old method stays available while the new one proves itself.
- Life after launch. Hosting, backups, monitoring, patches and improvements. The application is not delivered and abandoned: it follows your business.
Ownership
What you own at the end of the project
The question to ask any developer before signing: if this relationship ends tomorrow, what do I walk away with? Here is our answer, and it is written into the agreement before the first day of work.
The code
The complete source code, in a repository under your name, with the full history of changes. Not a copy emailed at the end, permanent access.
The data
The database is yours, exportable in a standard format at any time, with no exit fee and no need to justify the request.
The hosting
Hosting and domain name accounts are opened in your name. We administer them, you own them.
The documentation
The data model, the deployment procedures and the user guide. Enough for another team to pick up where we left off.
Why us
We build our own platforms and run them every day
Most IT firms resell somebody else’s tools. We wrote ours: the platform that watches over our clients' equipment, the one that handles service requests, the one that gets documents signed, and the agents that carry out our automations. These are not demos. They are production software, used every day by our own technicians, on real clients, with real consequences when something breaks.
The best test for a developer is asking what they use themselves. We answer by showing our screens.
One of our in-house platforms, in service on the environments we manage.
That changes two things for you. We know from the inside what it costs to maintain software for five years, so we will talk you out of designs that age badly. And when you ask for a change, it does not join the queue of a vendor overseas: it gets done by the team that answers your call.
Where to start
Describe the process that causes you the most friction. We will tell you whether a custom application is the right answer, whether existing software would do, or whether a simple automation would be enough.
Questions and answers
Common questions about custom software development
How much does custom software development cost?
How long before we have something we can actually use?
Is a custom ERP realistic for a small business?
Who owns the code once the application is delivered?
Can you modernize an existing application instead of rebuilding it?
Do you handle hosting and maintenance after launch?
Do you work with businesses outside Trois-Rivières?
Tell us about the process that costs you the most
One scoping meeting is enough to know whether your need calls for an application, an automation, or simply better use of what you already have. We say it plainly, even when the answer does not run through us.