BenefitCheck.ca
A calculator that tells people in Ontario which government benefits they are likely to qualify for, and roughly how much. I wrote it, I own it, and I am the one who has to keep it working when a rate table changes in the middle of a tax year.
Building something and running it are different jobs.
Anyone can ship a project. Keeping one alive for real users teaches the parts that actually decide whether a business trusts its software: what happens when a payment fails, when an email hard-bounces, when a scheduled job stops without saying anything, when a government moves a threshold in March.
Every one of those has happened here. The way I handle them is the reason client work comes with a sync log, an alert and a health page rather than a promise that I will keep an eye on it.
- Role
- Sole developer and operator
- What it does
- Eligibility estimates across federal and Ontario programs
- Money
- One small payment by card for the full result
- Behind it
- Transactional email, bounce suppression, scheduled monitors, admin health panel
- Next
- More provinces, each behind a parity test before it goes live
Rules that change every year, written so they can change.
Benefit programs have rate tables, income thresholds and phase-outs that move annually, and sometimes mid-year. So the calculation does not live in code that somebody has to remember to edit. It lives in versioned rule packs, each program isolated, each one testable on its own.
That is the same problem a quoting tool has, and it gets the same answer: the numbers are configuration, the configuration is versioned, and last year's answer stays reproducible.
- Each program isolated and independently testable
- Rates versioned by year rather than overwritten
- A set of reference households run before anything ships, so a change that moves an answer has to be deliberate
It tells me when something breaks.
A heartbeat every fifteen minutes. A monitor every five. A weekly digest of what ran and what didn't. A kill switch. Suppression logic so a hard-bounced address is never emailed again, because a sender reputation takes months to build and one bad week to lose.
None of that is visible to anybody using the site. All of it is why the site still works, and all of it was built after something went wrong once. That is the usual order.
- Scheduled monitors with alerting, not a dashboard I have to remember to open
- Bounce and complaint handling that blocks future sends automatically
- One admin page showing the state of every moving part
Four things I now insist on
- Anything that runs on a schedule must report that it ran, or you find out it stopped from a customer
- Email needs a suppression list from day one, not after the first complaint has already cost you a sender reputation
- Numbers that a government or a supplier can change belong in versioned data, never in code
- There has to be one page that answers "is it healthy right now" without anybody logging into three separate services to find out
This is not a case study and there is no client in it. It is my own product, shown because it is the only software on this site you can go and use yourself right now.
Everything else under Projects is an example build — my own illustration of a kind of tool, not work done for somebody else.
The example builds →Stack
Whatever I build for you, I have to live with too.
Start with a free written audit of how your business runs: what is costing you time, what to fix first, and what the rest would cost.