2025 · Selected work
Musės — Fly Tying Market
A specialist fly-tying marketplace connecting a customer storefront with seller, support and administration workflows.
The product repository is private. A guided walkthrough or focused, sanitised code sample can be shared for a relevant technical review.
- Role
- Full-stack Engineer
- Location
- Remote
- Engagement
- Independent product
- Period
- October 2025 – Present
About the project
Fly fishing is one of my own interests, so I built Musės around the specific needs of fly tiers and specialist buyers. Customer shopping, seller operations, support and internal administration are delivered through dedicated applications with a shared technical foundation.
The platform is an npm-workspaces monorepo spanning five applications and six shared packages. A Node.js/Strapi 5 API and PostgreSQL data model sit behind role-specific Next.js surfaces, while domain types, authentication, forms, internationalisation, themes and back-office patterns evolve through versioned shared packages.
The storefront is live and taking real seller applications, but it's still early: the catalogue and seller base are growing rather than at full scale, so the architecture below is proven in production, not yet under production-scale load.
My contribution
- Marketplace foundation — Architected five applications—a storefront, seller, support and administration workspaces plus a Strapi 5 API—and six packages for shared domain and UI concerns.
- Transactional integrity — Built Stripe and inventory services so a retried payment or a webhook delivered twice can never double-charge a customer or double-count stock, and modelled seller wallets as a running transaction history with payout, statement, reconciliation and dispute workflows.
- Access, quality and operations — Added OTP/2FA and Turnstile-protected, Redis-throttled support forms; covered core domain and cross-role journeys with Vitest and Playwright; deployed all five services behind NGINX and PM2.
Engineering proof
What was hard, what I chose, and how I checked it.
Challenge
A multi-seller marketplace needs its role-specific applications to evolve independently, without ever letting that independence weaken the transactional integrity of payments, stock or seller balances.
Product & engineering decisions
- Applications split by user role; authentication, domain types, forms, localisation and visual foundations stay centralised.
- Payment and fulfilment steps are written so re-running them causes no harm, and seller balances are calculated from the full transaction history rather than stored as a single number that gets overwritten.
- Rate limits, repeat-submission checks and valid-state transitions live inside the applications instead of being left to edge bot detection alone.
Quality & outcome
- Vitest checks that the transaction history stays correct through webhook replays and outages; Playwright exercises the high-value cross-role journeys.
- Worker metrics, automatic stock restoration and contextual failure messages are in place for support and finance users.
The marketplace is live and onboarding its first sellers. Storefront, seller, support and administration users already get workflows shaped to their roles, and the shared contracts and the ledger's built-in checks are built to hold as the catalogue and transaction volume grow — the open question now is real usage at scale, not the architecture.