Project
Trades Service Platform
A multi-tenant subscription and field-service platform for construction and trades workflows, built around requests, visits, accounts, and communication.
Year
2026
Status
active
Type
SaaS and field app
Role
Full-stack product engineer
Highlights
- Shaped the customer dashboard around active requests, upcoming visits, service address, subscription state, and recent maintenance activity.
- Connected auth, organization context, Convex backend state, Stripe-oriented billing concepts, and email delivery boundaries.
- Kept the customer experience focused on service operations rather than raw database entities.
Lessons learned
What the project made clearer.
Customers need service language, not schema language
The dashboard became stronger when it described active requests, upcoming visits, service address, subscription state, and maintenance activity instead of exposing internal tables or unfinished operations.
Multi-tenant state has to be explicit
Organization context, auth, billing, and communications all need clean boundaries because a small ambiguity in account state quickly becomes a product trust problem.
Durable workflows belong behind the interface
Background tasks, email rendering, and billing events should support the customer experience without making the customer aware of the machinery.
Context
This trades service platform is a service-operations product, which means the core challenge is not just CRUD. The software needs to help customers understand what is happening, help the business coordinate field work, and make account state feel clear and trustworthy.
Product Work
The customer-facing dashboard direction centered on real service concepts: active requests, upcoming visits, recent maintenance activity, subscription state, organization context, and the service address. That framing matters because customers should not need to understand the internal schema to understand their account.
Engineering Notes
The architecture connects Next.js App Router, Convex backend functions, Clerk authentication and organizations, billing events, durable background work, and branded email rendering. The useful boundary is clear: route handlers handle ingress, Convex handles durable execution and product state, and shared templates handle customer communication.