• Designed and built SendTax's public Trust Center: plain-language security commitments, an honest compliance roadmap, a live sub-processor list, and a full policy library, for a product that holds W-2s, IDs, and K-1s
• Turned a failed first cohort into the project's direction. Nobody signed up, because the security we had built was invisible, so I made it legible
• Wrote a home-grown, SOC 2-style program into a public, readable surface, getting as close to the formal bar as a new company can before paying for an audit

---

My contributions

---

Summary of work

Tax documents are some of the most sensitive data a person owns: W-2s, government IDs, K-1s, the whole financial picture. SendTax asks people to put those documents in one place so a tax pro and their client can work from the same source. That ask only works if people believe their data is safe.

I co-founded Howell & Gibbs, the studio building SendTax, with engineer Liam Howell. On the Trust Center I owned positioning, content, and design, and built the front-end, working alongside Liam, who automated the compliance program on the backend.

The throughline of this work is trust. You cannot ask someone to hand over their most sensitive documents and treat security as fine print, so I designed trust as a product surface in its own right: something a prospective filer or pro can read, understand, and verify before they upload a single file.

---

Process

When nobody signed up

Our first friends-and-family cohort launched, and nobody signed up. Not one person. That silence was its own kind of signal, so we went back to a handful of friends and asked them directly. The miss was glaring: We had taken security seriously from the first commit, but we were the only people who knew it. We were asking people to hand over their most sensitive documents and giving them no reason to believe it was safe.

Two decisions came out of that: First, as a brand-new company we couldn't yet justify the cost of a formal SOC 2 audit, so we chose to build the equivalent ourselves, writing every policy, control, and process a SOC 2 requires and getting as close to that bar as we could before paying for the formal audit. The second was that all of that work needed a front door, because people can't trust what they can't see. The Trust Center is where those two threads meet. It's the public face of a real, if young, security program.

Trust as a designed surface, not fine print

Most products bury their security documentation in a link no one clicks. For a product that holds tax documents, that's backwards; the security story is part of the pitch. So I designed a public Trust Center as a first-class destination, written in plain language and structured so a nervous first-time filer and a diligence-minded tax pro can both find what they need.

The page opens with the short version, in human terms: we don't read your documents. No one at SendTax can open an uploaded file without two things, the filer's explicit permission and a documented reason. Every access is logged, attributed to a named person, and auditable. The default state is private, and that doesn't change without the user.

Honest about where we are

SendTax is a new company, and the easy thing for a new company to do is plaster a page with compliance logos. I made the opposite call. The compliance section is a roadmap rather than a trophy case. Each framework carries an honest status (Live, In progress, Planned, Aligned, N/A) with target dates: SOC 2 Type II in progress with a first-report target, an annual third-party penetration test scheduled, a WISP aligned to IRS Pub. 4557 and the FTC Safeguards Rule, CCPA/CPRA rights documented, and GDPR marked N/A because we operate only in the U.S.

The copy says it directly: "Rather than wave compliance badges we haven't earned, here is exactly where each framework stands today." Being upfront about what isn't done yet turned out to be one of the strongest trust signals a young company can send, and it set the specific, plain voice for everything else on the site.

The roadmap is not a one-time post. Behind it sits a maintenance schedule and an internal admin view that track when each policy was last reviewed and what's due next. Liam automated much of the compliance plumbing on the backend: the logging, the scheduled reviews, the reporting, and the analyses a thorough security program has to keep producing. My part is making sure we're communicating the work we're doing and keeping it legible, so the public page always reflects where we actually are.

Letting users verify, not just trust

A claim you can check is worth more than a claim you have to take on faith. I designed an "At a glance" panel that states the actual defaults: U.S.-only data residency, TLS 1.3 in transit, AES-256-GCM at rest, MFA-protected identity, row-level access control enforced in the database, and audit logging kept for at least a year. Alongside it sits a full policy library with downloadable PDFs: privacy, data retention and deletion, acceptable use split into separate user- and employee-facing versions, and more.

The sub-processor list is public, showing every third party that processes customer data, and anyone can subscribe to be notified when it changes. That notification is part of our compliance process for disclosing sub-processors, and surfacing it in plain sight, rather than hiding it in a policy, is the point.

---

Outcomes & impact

The Trust Center is live on the marketing site: plain-language security commitments, an honest compliance roadmap, a live sub-processor list with change notifications, an at-a-glance defaults panel, a downloadable policy library, and a security contact. Behind it is a real program, maintained on a schedule rather than posted once and forgotten.

It does work most products defer until an enterprise customer demands it. It lets a prospective user verify how their data is handled before they commit, which for a tax product is the difference between a sign-up and a bounce. It exists because the first cohort showed us, in the clearest way possible, that invisible security is the same as no security.

---

Learnings

For a sensitive-data product, the security story is the product story. It was tempting to treat the Trust Center as a compliance chore to get to later. Designing it early, in plain language, changed the product itself. It forced clarity on what we actually do with data, surfaced decisions (default-private, named-and-logged access, U.S.-only) that became real engineering constraints, and gave the onboarding story its spine. Trust designed from the beginning is less costly and more honest than trust that's just bolted on.

Being upfront beats looking finished. The instinct for a young company is to seem more established than it is. Publishing a compliance roadmap that openly includes what we haven't done yet felt risky, and it turned out to be the most credible thing on the page. Being specific about where we actually are reads as more trustworthy than a wall of badges.