Approach
Start with the work. Choose the technology second.
The order matters. We learn the operation first, find the expensive work, and only then decide whether plain software, an integration, or AI is the answer.
01
Understand the business
The first meeting is about the operation, not a tool demo. We want to know how orders, invoices, approvals, and reports actually move through the company, and where time, money, and risk are going.
02
Find the expensive work
We look for repetitive processes, handoffs between systems, and software the company is afraid to change. One concrete problem is enough to start.
03
Decide whether AI belongs
If a conventional integration or a simpler workflow will do the job at lower cost and risk, that is the recommendation. AI is for the cases where it changes the economics. The conversation on this site runs that check before the call. A person still decides what happens next.
04
Build it into what you already run
The useful system is the one connected to your existing tools and trusted by the people who have to use it. We would rather extend a system than replace it without a reason.
05
Keep it running
After launch we stay available for support, adjustments, and the next improvement when it is worth doing. A relationship can continue. It does not have to.
How an engagement starts
It starts with a conversation on this site or a free introductory call. If the problem is clear, we move to a scoped proposal.
If it is not clear, we can offer a short paid assessment: a focused look at the process, the systems it touches, and what would have to be true for software or AI to help, written up so you can act on it with or without us. It is optional. We do not publish package prices, and we do not require every client to buy an assessment first.
What we will not pretend
We will not dress up prompt experiments as a consulting product, and we will not recommend replacing systems that are doing their job. The work is production software, with a person accountable for it.
We will also not claim a team that does not exist. Rob Runka is the engineer on the engagement. For work that needs more hands, that is said up front, and the people brought in are named.
How we decide whether AI belongs
Most of the requests that reach CollectDev, from Alberta and from the United States, now mention AI. Some of them should. Reading and classifying documents, drafting replies that a person then approves, summarizing a long thread so the right person can act on it, pulling the figures out of a scanned statement: these are places where a model does work that used to need a person, and where a wrong answer can be caught before it costs anything.
Others should not. Moving an order from one system to another, applying a transaction limit, calculating a payout, reconciling a payment against a ledger: these are rules. Rules belong in code, where they run the same way every time and can be tested. Our PomPay Financial case study is a system with no model in the loop for exactly this reason, and the Stoke case study shows agents working inside hard gates next to a rules engine that does the accounting.
When AI does belong, the design is the same every time. The model drafts. A person approves anything that leaves. The approval is enforced where it cannot be talked around, in the database, not in a prompt. Every output is forced through a schema and validated before it is stored. Autonomy is extended one step at a time, on measured results, and pulled back when the numbers say so. We run our own company this way, and the Bridge case study publishes the numbers.
What an assessment covers
The assessment is a short, paid, written piece of work for companies where the problem is real but the shape of the solution is not yet clear. It follows the process end to end: who touches it, which systems it passes through, where it waits, and what it costs when it goes wrong.
It ends with a recommendation you can act on with or without us: what to automate, what to integrate, what to leave alone, whether AI belongs anywhere in it, and roughly what the build involves. If the honest answer is that nothing should be built yet, the assessment says that.
How a build is delivered
Builds are scoped around one operational outcome and delivered into the systems you already run. Custom software, systems integration and modernization work all follow the same rules: production from the first release, tests on the paths that carry money or decisions, and no rewrite of a system that is doing its job. The services page describes each kind of work with the case study that proves it.
After launch, Rob stays accountable for what was built. Support, adjustments and the next improvement are available when they are worth doing, from Calgary, Edmonton or remotely across Canada and the United States.