For hiring managers
Evidence, not adjectives. A site that leads with results and shows how I build products, not only where I have worked.
Case study
Building this site and its student tools
A master's in computer science got me into software development, but I chose product over engineering, and my coding and deployment skills hadn't kept pace with today's tools. In May 2026, I set out to build my first app, a credit card payoff simulator. By October it had grown into a five-page website, four live math tools and a shared design system, built from a résumé, a brand banner and a question from my classroom.
For my students
How can I make math fun and free of anxiety? Tools that explain every step, work on any phone, and need no installs, sign-ups or saved data.
My role: product owner, with an AI engineering partner
I owned the problem, the requirements, the priorities and every acceptance decision. Claude, Anthropic's AI model, was my engineering partner: it wrote the code, ran the tests and audits, and reported what it found. Most changes went to a preview for my review before they shipped, and I decided what to change, what to cut and what was ready to release. For example, I decided to split a single long page into four focused pages, so hiring managers and students each land on what they came for.
How I built it
From question to production
The same habits I bring to regulated platforms, applied to a website and four classroom tools.
Write it down first
Every tool starts as a specification.
Before any code, each tool gets numbered requirements and acceptance checks, so "done" means something anyone can test.
ProofMy first app, the payoff calculator, began with a requirements specification ↗: inputs, interest and validation rules, milestones, edge cases and what was out of scope. The Sieve's has 27 numbered use cases and requirements and 10 acceptance checks.
Test against what we agreed
Math tools have to be right.
Automated tests run on every change, and I test every tool myself, the way a student would, tracing each surprise back to a requirement.
ProofThe calculator was reviewed against its specification ↗ and runs 121 automated tests. My own testing still found issues in two of the apps: in the calculator, an incorrect minimum-payment formula and edge cases that showed wrong information; in the Sieve, a printed worksheet that lost its shading. All were fixed and retested.
Design once, reuse everywhere
One design system for the site and every tool.
I turned the website's look into a design system: color tokens with hex codes, type, and components with rules for their use. Each tool installs a pinned release, so an update is a choice, never a surprise.
ProofMore than 25 components and 22 releases. Before each tool takes a release, a snapshot of every element's style is compared before and after: no unintended visual change has shipped.
Accessible from day one
Audit, fix, then make the fix the default.
Every page and tool is audited against WCAG 2.2 AA and tested with a keyboard. When a gap turns up, the fix goes into the design system, so the next tool starts with it.
ProofAn audit found five gaps across two tools, including results a screen reader never announced and answers marked by color alone. All five were fixed, retested and made standard.
Ship in small, safe steps
Push, preview, release.
Each tool lives in its own GitHub repository and deploys automatically to its own address on Vercel. Release steps are written down, so anyone can repeat them.
ProofFour tools live at their own winsomemundy.com addresses, each with written release steps. The Sieve's are in both its specification and a Word guide.
Review it as the buyer would
The website is a product too.
I built the site from my résumé and brand banner, then reviewed it the way a hiring manager for a technical product role would, and acted on what that review found.
ProofThat review led to the two-roles opening and product principles backed by evidence. It also replaced an "At a glance" summary with proof cards that carry real numbers.
Results
What shipped
4Live student tools, each at its own address
0Accessibility violations (WCAG 2.2 AA) across the site and tools
22Design system releases, pinned so each tool updates by choice
121Automated tests for the payoff calculator
What I learned
- Fixes are cheapest as defaults. Once the accessibility fixes moved into the design system, every new tool inherits them.
- A pinned design system makes change safe. Tools update when I decide, and the snapshots show that nothing moved by accident.
- A clear spec makes AI faster. Numbered requirements and acceptance checks meant fewer surprises and quicker reviews.
- Review as the buyer, not the builder. Reading the site as a hiring manager would reshaped it more than any visual polish.
Contact
Let's build something that matters
Open to senior technical product owner and product leadership opportunities. Based in South Florida.
Integrity in every decision.
Excellence in every delivery.