About
Founder-led product review for teams handling health and other sensitive user data.
Independent systems designer. Based in Vernon, BC.
I work with founders and technical owners who need a clear read of the product itself before compliance tooling, legal review, or buyer pressure starts steering the conversation: architecture, defaults, privacy behavior, recovery paths, and operational risk.
Products can fail users before they fail technically
Many products run fine but still fail people at the edges: hidden collection, unclear boundaries, weak recovery paths, or claims that do not hold up under pressure.
I find those weaknesses early, explain them plainly, and turn them into fixes a team can ship.
This is service work first: pre-compliance trust review, correction, and implementation support.
- •Privacy is architecture, not a policy page.
- •Product boundaries need to be explicit, not implied.
- •Critical flows should survive low attention, low bandwidth, and bad conditions.
- •Evidence matters more than sales language.
- •Find the highest-leverage fix first, then ship it.
- •Pre-launch and pre-procurement trust reviews for live or near-launch products.
- •Threat modeling and risk framing that matches real constraints.
- •Architecture review with explicit boundary and minimization decisions.
- •Implementation guidance and fix support when changes need to ship.
- •Sell compliance checklists as proof of product safety.
- •Act as a law firm, auditor, or certification authority.
- •Hide weak decisions behind vague language.
- •Treat a pentest, policy page, or marketing copy as a substitute for product behavior.
- •Take on work where nobody can act on the findings.
Independent practitioner focused on local authority, degraded-mode behavior, and evidence a buyer can inspect.
Founder of CrisisCore Systems. Independent consultant based in Vernon, BC. I review software systems for privacy and product risk, with a bias toward evidence a buyer can inspect without a sales call.
Use these to verify public identity across code and DOI-backed records.
These are the tracked destination links I use in profile surfaces so GitHub, DEV, and Hashnode clicks land on the measured trust-review entry point instead of a generic homepage visit.
Open the case-study route first, then continue into proof materials, source records, and operating claims.
I work best asynchronously and artifact-first. A short written context, a few constraints, and links beat a long call.
If coercion risk, compromised devices, legal exposure, or health-adjacent data are in play, say so early. That changes the review from the start.
If you are deciding between compliance automation, a lawyer, a pentest, or a product trust review, send the product URL and one concern first. I'll point to the right lane.
- •Start with Services for package fit and starting prices.
- •Go to the case-study route first, then Proof for artifacts, outcomes, and technical evidence.
- •Use the 3-point trust risk read when you are ready to send the app, launch stage, and concern.