We build software that’s still running in ten years.
Some of our software has been running for twenty years. Most of it does the same quiet job — making the systems you already paid for talk to each other, so nobody’s retyping data into a second screen at 4pm. We’ve been writing custom applications since 1999, and most of the businesses we built them for are still our clients.
The short version
We build the software you can’t buy.
Custom software development, systems integration and application hosting for organizations in Edmonton, Calgary and across Canada.
Off-the-shelf software is the right answer more often than a development shop will admit, and when it fits, we’ll tell you to buy it.
The rest of the time there’s no product on the market that does what your business does — because your business is unique. That’s the work we take on, and it has been since 1999.
- When the software you need doesn’t exist, we build it.
- When it exists but won’t talk to your other systems, we connect it.
- When somebody built it and walked away, we finish it.
And when a product off the shelf would do the job, we say so — which costs us the project and keeps the client.
Where most projects start
You probably came here saying one of these.
You don’t need to know what to call it. Describe it the way you’d describe it to a colleague and we’ll work out what it actually is.
“We need a database.”
Usually it starts as a spreadsheet that three people edit and nobody fully trusts. What you need is one place the data lives, with rules about who can change what, and a record of who changed it. Reports come out in seconds instead of minutes — under thirty seconds is the target we hold ourselves to, and it has been for a long time.
The industry calls this database design and development.
“We need an app.”
Whether it belongs on a phone, on a tablet in a truck, or in a browser is a decision we make with you rather than for you. What we build runs on the equipment you already own, so nobody has to buy hardware to use the thing you paid us to build.
“We want to integrate AI.”
We won’t add AI to something that doesn’t need it. What we do is connect your systems directly to the models, so they work against your real data and write back into a real workflow rather than a chat window somebody has to copy and paste out of. We’ve built one of these for ourselves already, and broken it, which is the part worth hearing about.
What we learned building ours“These systems need to talk to each other.”
This is most of our work. Two, five, sometimes a dozen platforms that each hold part of the truth. We build the connections so your team enters something once.
“Someone else started this and it’s stuck.”
More common than you’d think, and we’re often the second call. It’s a different conversation than starting fresh, and it starts with reading what’s already there.
How that conversation goesMost of what we do
The systems you already paid for, finally talking to each other.
Most businesses don’t need new software. They need the accounting system, the field app and the payroll platform to exchange data without a person retyping it at the end of the day. Every one of those manual handoffs is a place where numbers drift apart, and eventually five people have five spreadsheets and five different answers to the same question — with no way to tell which one is right.
We connect them properly. Your team enters something once, and every system that needs to know about it knows about it. One of our developers does almost nothing else — making systems talk to each other is his whole job description.
The industry calls this systems integration. We build it with REST APIs against whatever your platforms expose — which, after twenty-seven years, is most things.
Why it’s still running in ten years
When you replace one of those systems, the integration doesn’t die with it. We scope the design around the questions your business needs answered rather than around one vendor’s database, so swapping your accounting package changes how we fetch the data — not what you built on top of it.
Inherited work
Someone else started it, and it’s stuck.
A good number of the applications we look after, we didn’t start. They arrive half-built.
Projects outgrow the person who started them, and it usually happens the same way. A capable web developer takes on a database that turns out to need real data modelling. A one-person shop reaches the point where the application needs proper authentication, three integrations and hosting that survives growth. Nobody did anything wrong — the work got bigger than the brief it started as.
You may also be the person who hired them. That’s the part that makes this call hard to make, and it’s why a lot of stalled projects stay stalled for another six months. It isn’t a judgment we’re interested in making — we’ve been the second call often enough to know that the people who commissioned the work usually made a reasonable decision with the information they had.
What we do first is read it. The code, the database, whatever documentation exists. Reading other people’s undocumented systems is a specific skill, and one of our senior developers is known for it internally. Then you get three numbers.
Sometimes the answer is that the existing work is sound and needs six more weeks rather than a rewrite. We’ll tell you that, even though it’s the smaller invoice.
Money
What custom software development actually costs.
The first conversation and the preliminary meetings are free. After that, development is billed hourly against a written statement of work that sets out the deliverables, the schedule, and what “finished” means for each one.
If you want a ceiling, ask for one.
We’ll quote a fixed price and then bill actual hours inside it. You won’t pay more than the quote — and if the work comes in under, you pay the lower number. That’s the opposite of how fixed price usually works, where the saving stays with the developer.
When something changes mid-project, and something always does, you get an estimate in writing and an amended scope before we do the work rather than an explanation on an invoice afterwards.
And you get ten business days to accept or reject each deliverable, against criteria agreed in advance rather than argued about later. If you reject it, you tell us why and we fix it.
We also run a managed IT practice, which makes us one of very few development shops that knows what it costs to keep an application running for a decade — we do it every day, for our clients’ software and our own. So the monthly hosting number comes with the quote, not after the build.
The agreement also covers licensing and intellectual property. That one is more nuanced than a web page can usefully explain, so we’d rather walk you through it properly before you sign anything than flatten it into something misleading.
The three questions
Secure, hosted properly, and yours to use for good.
Three things every owner asks about, answered before you have to ask.
Is it secure?
Your users sign in through standards-based authentication — the same protocols your bank uses — not a login screen somebody hand-rolled. Permissions are enforced in the database rather than hidden in the interface, so a determined person with a browser can’t see what they shouldn’t.
Where does it live?
Your data sits in Azure SQL. Your application runs on App Service. Backups are automatic and tested. It scales when you grow, and Azure has Canadian regions, so your data can stay in Canada if that matters to your members or your board.
Can our people actually use it?
The people using it are often on a tablet in a truck, or covering a desk they don’t normally sit at. So we design for somebody doing the job at the worst moment of their day rather than for a demo.
If your staff end up inventing a workaround, we got it wrong — and we’d rather learn that in week three than after launch.
How we work
If we build the thing that calculates your numbers, you get to see how.
Anyone can produce a report with a total on it. The question is whether your organization can check that the total is right.
So we explain the logic in terms you can test — which records are included, which are excluded, and what happens at the edges. If we can’t explain how your numbers are calculated in plain language, that’s our failure, not a gap in your knowledge. And if your current developer can’t explain it either, that’s worth knowing.
We’ve been saying this in writing since 1999
Artificial intelligence
Most AI projects fail on the data, not the model.
The models are remarkable, and they are not the hard part. The hard part is what they get pointed at.
Five systems holding five versions of the same member. A spreadsheet three people edit and nobody fully trusts. A field that means one thing to the office and something else to the people in the field. No model repairs any of that — it produces confident answers on top of it, which is worse than no answer at all, because now somebody acts on it.
We’ve been building the data layer since 1999. That’s why our first questions are about your records rather than your ambitions, and why we’ll sometimes tell you the AI project isn’t the project — that what you actually need is the thing underneath it, and that it costs less.
Three things we’re confident about
1
Fluent is not the same as correct
These systems will produce something well-formed, professional and wrong, with no outward sign that anything is amiss. The polish of the writing tells you nothing about whether the content is true, and people reading it will assume otherwise.
2
A boundary has to be built, not requested
You can tell one of these systems what it must not do. That is not the same thing as making it impossible, and the difference matters a great deal when the information involved belongs to your members, your patients or your clients.
3
The work is in the edges, not the demonstration
Almost anything looks impressive for ten minutes. The real effort goes into deciding what it may see, what it may assert, and who checks it before it counts — and that work is invisible in every demo you will be shown, including ours.
Two rules we don’t bend
A person approves anything that reaches a record
Nothing an AI produces goes to a client, an invoice or a database on its own authority. Someone accepts it first, and they can always say no.
It doesn’t go looking on its own
It works from information a person deliberately gave it, not from what it could infer by wandering through your systems. Anything with money or obligations attached cannot rest on a guess.
Where your data goes
Azure has Canadian regions, so your data can stay in Canada. Your information is not used to train anybody’s model. If either of those matters to your board or your membership, we’ll put it in the agreement rather than leave you to take it on trust.
And we’ll tell you when the answer is no. AI is being sold hard at the moment, and a fair share of what it’s being sold for is work a well-built database and an honest report would do better, cheaper, and without the risk of a confident wrong answer.
After launch
We don’t just build software. We run it.
Two of the products we sell, we wrote and we host. Real systems, in production, with people depending on them on a specific morning at a specific hour.
That’s an unusual thing for a development shop to be able to say, and it changes what happens after your project launches. We know what year three looks like — the patching, the certificate renewals, the migration when a platform version goes end of life, the call at 8am when something needs to be up by nine. When it’s our product, it’s our phone that rings. When it’s yours, it’s still our phone.
Election Portal
Managed electronic elections for seventeen workplace organizations and roughly 66,000 voting members. We wrote it, we host it, and it has to be right on the specific morning a local counts its ballots.
See Election PortalLabourConnex
Membership and engagement software for national workplace organizations. Same story — our code, our hosting, our responsibility when it needs to be up.
See LabourConnexWho builds it
The people who’d actually build it.
The team that would take on your project has a technical lead, project managers who own your dates, and developers who’ve worked across the platforms businesses actually run on. Everyone is named on our team page — no subcontractors, no offshore bench, nobody you won’t meet.
The hardest work we do isn’t a language or a framework. It’s structure. Non-destructive testing data arrives in nested layers — readings inside locations inside components inside assets — and the output has to carry that shape onto the page so an inspector can follow how the work was actually performed. We build for healthcare, where being wrong has consequences beyond an awkward meeting. And for organizations sending tens of thousands of statements that all have to be correct and out on time.
That is the work that separates someone who can write software from a team that has done this before. One of ours is the person who reads the systems nobody documented. Another spends most of his time making systems talk to each other. A third turns data into reports people actually read.
They’ll also tell you when you don’t need custom software. That happens more often than you’d expect from a company that sells it.
“How do we know you’ll still be here in five years?”
Twenty-five years ago we were working on a large project for a federal government department, and their biggest concern wasn’t our technical approach. It was that question.
It was a fair question and we didn’t have a good answer. No young company does. We have one now, and it’s the only kind of answer that counts: we are still here, still the same company, and the software we built then outlasted the concern. If you are weighing the same risk today — and you should be — that is the evidence.
We’re still taking on new clients, and most of them arrive because somebody we already work for told them to.
“The first thing I want to know is how the work gets done today — who touches it, where it breaks, what everyone has quietly worked around. The software part is usually the easy half.”
Kris Sabourin
Director of Software Development
Before BKY, Kris led development for seven teams and 120 developers on a major software title, and built two Edmonton engineering studios from the ground up.
The process
How this actually goes.
1
We ask a lot of questions
Mostly about how your business works, not about technology. This is where the cost of the project is really decided.
2
You get a scope, a schedule and a number
In writing, with acceptance criteria for each deliverable agreed in advance, and a project manager who owns the dates.
3
You see working software in weeks
In a sandbox, within the first few weeks — not months of silence followed by a big reveal. Early enough to tell us it’s wrong while it’s still cheap to change.
4
It goes live, and we’re there for it
Not a handoff. A launch we’re standing next to.
5
We look after it
Hosting, updates, changes as your business changes. Most of our development clients have been with us for years, and this step is why.
Scope
Small enough to talk to. Big enough to trust with the whole thing.
Software development has never needed us to be in the room. We build and support applications for organizations across Canada and into the United States, and where your people sit has never been the constraint.
Managed IT used to mean somebody driving to a building, and for plenty of our clients it still does — there are things you cannot do down a wire. But as more of the stack moves to the cloud, we increasingly support organizations we may never visit, including outside Alberta. If you want both the infrastructure and the software from one firm, ask us. The answer is less geographical than it used to be.
A firm our size means the person who scoped your project is still reachable in year four rather than three reorganizations away. It also means we say no to work we can’t staff properly, and we’d rather tell you that in week one than in month five.
Client
Building Trades of Alberta
Two specific problems
Slow reports and software that’s out of support.
We’re called about these two often enough that they have their own pages.
Reports that crawl, and numbers that disagree
If a report takes ten minutes and sometimes doesn’t finish, or two systems give you two answers to the same question, that’s a data problem with a known shape and a known fix — and it usually isn’t a new tool. Our reporting page also covers where Crystal Reports still fits and when it genuinely needs to move.
Reporting and business intelligenceThe system your IT provider won’t touch
Changing IT providers usually leaves the awkward software exactly where it was — the database built by somebody who left, the application nobody will open. Because we have developers on staff, that stops being something you live with.
Switching IT providersQuestions
What people ask before they start.
How much does custom software cost?
It’s billed hourly against a written statement of work, so the honest answer is that it depends on what you need — and we won’t know until we’ve asked you enough questions. What we can tell you is how you’ll find out: the first conversation and the preliminary meetings are free, and you get a scope, a schedule and a number in writing before anything is built. If you want a ceiling, ask and we’ll quote a fixed price, then bill actual hours inside it — so if it comes in under, you pay less.
How long does it take?
You’ll have a written assessment and proposal typically within two weeks of the first conversation, and working software in a sandbox within the first few weeks of the build rather than months of silence. Overall length depends entirely on scope, and we’d rather give you a real date in the statement of work than a reassuring number now.
We already have a system that mostly works. Is it worth doing anything?
Often the honest answer is no, and we’ll say so. When it is worth doing, it’s usually cheaper than you expect — extending something that works costs a fraction of replacing it.
Can you take over software someone else built?
Yes, and a good portion of what we support started somewhere else. We read the code and the database first, then give you three costed options: finish it, rebuild it, or leave it alone for now. Sometimes the existing work is sound and just needs finishing.
Do you build with AI?
We connect applications to AI models through their APIs so they work against your real data and write back into your real workflow. We don’t add AI to a project that doesn’t need it.
Where are you, and does it matter?
We’re in Edmonton, with operations in Calgary as well. Software development doesn’t require anyone in your building — we build and support applications for organizations across Canada and into the United States, and a development project can run from anywhere. Managed IT has historically meant being close enough to send an engineer, and for many clients it still does, but as more infrastructure moves to the cloud that boundary is moving with it. Worth asking rather than assuming.