Digital Domi

the product

mail, made digital

domi turns a user's physical mailbox into something they can manage from an app: mail gets scanned, and from there it's readable, searchable, and actionable instead of sitting in a stack of paper. i joined in nov 2025 as founding qa engineer, brought on to own product quality as the team built it out.

that's not a low-stakes surface to get wrong. domi handles someone's actual mail and paid postage, so a document that renders incorrectly or an upload that silently fails is more than a cosmetic bug. it's someone's mail. "it worked when i tried it" was never going to be enough.

a bug that ships is a rewrite waiting to happen. a bug caught before ship is a comment on a pull request.

before qa

what releases looked like before i joined

there was no dedicated qa function before this role. requirements got reviewed by whoever wrote them, testing was whatever the engineer who built a feature had time for, and releases went out on developer confidence rather than a defined check.

that's a normal way for a small team to move fast early on. it's also how a real bug, a rare device, a slow network, an edge case in a document upload, reaches a user instead of a test pass.

surface area

four surfaces, one qa function

domi isn't just a mobile app. by the time i joined it also had a consumer web client, internal dashboards, and admin tools: four surfaces, mostly built by different corners of a small team. i own qa across all four from initial development through production, instead of each surface only getting whatever testing its own engineer had time for.

that means knowing what "normal" looks like on four different surfaces well enough that a regression doesn't have to wait for a user, or a teammate, to report it. a bug in the admin tool doesn't feel as urgent as a crash on mobile, but it's still blocking someone on the team from doing their job, so it gets the same attention.

process

test cases before test anxiety

i plan and run test cases and regression cycles against the app's swagger-documented api surface, validating endpoints directly instead of only testing through the ui. that catches a class of bug (a response shape that changed, a status code nobody updated the client for) before it reaches a screen.

bugs get tracked and routed to whichever team owns the fix, with repro steps specific enough that nobody has to ask "can you check this again?" i review requirements with product and engineering before code gets written too, looking for the edge case that reads fine in a ticket but breaks the moment a real user hits it.

release

the last check before production, and the first after

release readiness sits with me: release notes, changelogs, and final sign-off before a build goes out, not a rubber stamp after the fact. once something ships, sentry is where i watch for what testing didn't catch, and google search console keeps the web app's actual search visibility honest instead of assumed.

that's the difference between qa as a checklist and qa as something that actually holds. a bug that slips through still gets caught, just by monitoring instead of a user complaint.

scaling

building the function, not just running it

as the product and team scaled, i helped put qa workflows and documentation in place that the team still uses for releases today. that part doesn't show up in a bug count, but it's the difference between one person catching everything and a process that keeps working after i've moved on to the next thing.