I've been into software for years; computer science just gave me the tools to finally build the systems I wanted. My background is in B2B sales and business — it didn't push me into engineering, it decided which problems I'd build for. So instead of generic practice projects, I build for problems I already understand firsthand. Two of them are below.
GitHub (opens in a new tab)·LinkedIn (opens in a new tab)·Calgary, Canada — open to software engineering internships in the us and canada
Selected work
A multi-tenant CRM that reads a team's inbox, proposes the next CRM action, and executes only what a person approves.
Inbox to CRM. Nothing executes before the approval gate.
Inbox
Gmail, synced over OAuth
AI analysis
extracts intent from email
SuggestedActions
structured proposals
Human approval
accept, edit, or reject
Linked execution
writes the CRM graph
Keeping a CRM current is manual upkeep, and manual upkeep slips. Records fall behind, and the system of record everything depends on goes stale.
Working today
The AI never writes to the CRM. It produces structured proposals; nothing becomes durable state until a person approves the package. That single boundary is what makes AI safe to point at real customer data.
Why this stack: PostgreSQL keeps every row workspace-scoped; Redis runs inbox sync and AI off the request path; a FastAPI backend and a typed React front end share one contract, so the UI and the data model can't drift.
An AI-assisted takeoff tool that reads construction plans, drafts measurements, and leaves every number for an estimator to check.
Early build. Document-understanding and computer-vision workflows read plans and extract measurements into a reviewable takeoff, with the estimator in control of every figure.
Honors research comparing how quantitative, human, and AI decision frameworks perform when replayed on identical market history.
A framework-agnostic simulation harness is being built to replay decades of history under each framework. Large-scale evaluation runs are designed but not yet run.
I don't build projects just to learn a technology. I build software for a problem I understand, and learn whatever that problem needs. Here's what building that way has taught me.
Tenancy, auth, migrations, and the job queue decide whether the interesting parts can exist safely. The AI in my CRM is maybe a tenth of the code; it only works because the other nine-tenths hold it in.
Businesses run on a few repeated motions, not feature lists. I design from the motion I watched break — which is usually the reason the project exists at all.
A model is probabilistic; software has to be reliable. The engineering is the scaffolding around the model — structured inputs, validated outputs, resolved dependencies, a human approval step — that turns an LLM into one dependable part of a larger system. Anyone can call the API; making it repeatable and trustworthy is the work.
A row that crosses a tenant boundary, a wrong number a customer trusted — you don't get those back. So the failures that can't be undone shape the design from the start, instead of living in a filter you hope everyone remembers.
Software-engineering internships where the interesting problem is the system around the model, not the demo — backend, infrastructure, or AI product. I start from the workflow and the failure cases; my edge is having lived on the other side of the software before I built it.
The fastest way to reach me is email.