The NDA problem in engineering portfolios
Most of my interesting recent work is under NDA. Here is how I think about what to share and why the system shape is usually more useful to describe than the implementation details.
Most of my interesting recent work is under NDA. That is a normal problem for contractors, and I do not think the right answer is to either pretend the projects did not happen or to leak details that are not mine to share.
What I can describe is the system shape.
For the fintech escrow platform: buyers, sellers, support staff, payment-adjacent state, disputes, identity, bank accounts, mobile money paths, and the operational layer on top of all that. The interesting engineering was in the state management, not the UI.
For the entertainment commerce build: release pages, merch, ticketing, checkout, door operations, admin tooling, and a payment-provider abstraction that had to work when a show's tickets went live and traffic spiked.
For the Web3 launch surface: token education, tokenomics, swap-path guidance, and deployment ownership. Smaller scope, but a good reminder that delivery discipline matters on static sites too.
What I do not share
Private schemas, admin routes, provider settings, customer records, internal dashboards, deployment secrets, anything that weakens the client's control of their system. Even when a public site is live, the operational layer is not automatically public.
What the partner-build posts are for
They are not meant to be the complete story of each project. They are meant to show the shape of the work — domain, scale, where the interesting problems were — so that someone reading them can tell whether the engineering judgment is the kind they are looking for.
If you want to go deeper on any of it, I am happy to talk through the architecture and tradeoffs in a conversation.