Minute Notary is a notary office in Ottawa. We designed, built and run the platform behind it: booking and payment, secure documents, a workspace for notaries, and seals anyone can verify online.
People come to a notary with one document and a deadline: a flight, an immigration file, a closing. Most have never done it before for that document, and most are on a phone.
One flow, from a risk lane at intake to production confirming the exact release it serves.
How a change reaches production. Intake gives every change a risk lane: tiny, normal or high-risk. A story sets its validation expectations, and high-risk work adds a design note and a decision record. A fail-closed quality gate runs type-checking, unit and UI tests, integration tests on a real database and cache, browser end-to-end tests and a structured-data check, and the first failure stops it. Security scans cover secrets, the code, API contracts, dependencies, the Dockerfile, the built image and the running container. The release is one image carrying its own release ID; its registry digest is read back, and the deploy counts only when production reports that exact release. Then metrics, traces, logs, synthetic checks and alerts watch it, with the prior image digest kept for rollback.
Service pages with a flat price on each, and a blog written for the exact question someone searched late at night.
Online booking with card payment, email confirmations, and a dashboard for each client’s bookings and documents.
For notaries: assigned bookings, availability, a register of notarial acts, one-click signatures with their seal, and earnings.
Every seal has a public page, so the office receiving a document can check it.
An AI assistant that answers from the office’s own pages and FAQ, and a set of evaluations every model change must pass first.
Every change starts with a risk lane (tiny, normal or high-risk), and high-risk work adds a design note and a decision record. A fail-closed quality gate runs type-checks, unit tests, integration tests on a real database and cache, browser tests on desktop and mobile, and a structured-data check. Security scans cover secrets, the code, API contracts, dependencies, the Dockerfile, the image and the running container. One command builds the release image, reads its digest back from the registry and waits until production reports that exact release.
A planned answer for every outside dependency: payment events claimed once and reconciled on a schedule, emails and calendar updates sent from an outbox, the assistant failing over to a second model provider, a booking page that degrades instead of failing, and seals that fail closed without a trusted timestamp.
Admin for bookings, documents and content; two-factor sign-in; documents in private storage; failed jobs kept for review and retry; health alerts per dependency.
Payments, email, the AI model, the cache, the database, documents, seals and releases: what each failure looks like, and what the platform does about it.
The rule: degrade where a visitor can still be served, and fail closed where trust is at stake.
Card payments
When it fails: An event fails, repeats or never finishes
RecoversEach event is claimed once. A failure goes back for redelivery, a reconcile job finishes stalled bookings, and a duplicate charge is refunded.
Email, calendar, Drive
When it fails: A provider is slow, or a send cannot be confirmed
RecoversEach action is queued in the same transaction as the booking and sent under a unique key. An unconfirmed send is retried once, not in a loop.
AI model provider
When it fails: An outage, a rate limit or a billing error
Fails overThe assistant fails over to a second provider before it starts answering. With nothing to cite, it offers the office’s email instead of guessing.
Cache
When it fails: Unreachable
DegradesReads fall back to the database and ordinary limits stay open. Admin step-up checks and the AI spending cap close.
Database
When it fails: The schedule cannot be read
DegradesThe booking page stays up and says slots are unavailable, instead of offering times it cannot check.
Document engine
When it fails: A PDF job hangs, crashes or the queue is full
RecoversThe worker is replaced after a timeout, and a full queue asks the client to retry instead of failing silently.
Seal signing
When it fails: The key vault or a timestamp authority does not answer
Fails closedA second timestamp authority is tried. Without a trusted time, no seal is issued.
A new release
When it fails: A tab was open across the deploy
RecoversThe last build’s files are still served, and the page reloads once onto the new release.
Watching every dependency
Capabilities rather than component names, because this platform is live.
Through intake, a quality gate and a verified release. Each change gets a risk lane, and high-risk work adds a design note and a decision record. The gate runs type-checks, unit, real-database integration and browser tests, and stops at the first failure. The release image carries its own ID, its registry digest is read back, and the deploy counts only when production reports that ID.
Each event is claimed once in the database, so a repeat is ignored and a failure is sent back to the payment provider for redelivery. A reconcile job re-fetches failed events and finishes stalled bookings, a duplicate charge is refunded automatically, and an event that keeps failing is set aside for a person.
It is built not to. The previous build’s files stay served after a release, so a tab opened before the deploy keeps working and reloads once onto the new version, and database migrations must succeed before the new server starts.
Tell us what you run and what is getting in the way. You get a reply within 24 hours.
