Live controlled intake
RMC Device Repairs
Making a technically capable repair service feel clear before a customer posts anything.
Product strategy · Service and interaction design · Front-end implementation · Serverless workflow engineering · Release verification
The challenge
Mail-in repair asks for trust before the technician has seen the device. The website needed to explain specialist board-level capability, real prices and service limits while making it impossible to mistake an enquiry for a booking or permission to post a device.
Built around the real constraint.
I designed the public journey as a precise repair ledger: clear scope and prices first, then a deliberately bounded request form. The Astro front end keeps the language direct and the mail-in rules visible. Behind it, a signed Netlify webhook validates the submission again, derives an opaque reference and sends separate owner and customer messages through an idempotent delivery path.
Role
One connected product responsibility.
I held the thread from product direction and interaction design through delivery and evidence.
- Product strategy
- Service and interaction design
- Front-end implementation
- Serverless workflow engineering
- Release verification
What was built
- Seven focused public routes covering repairs, prices, process, parts, warranty and the service boundary
- A repair-request journey that asks for useful fault detail while warning against passwords, serial numbers and private files
- Client and server validation, unsafe-battery stops, honeypot handling and a fail-closed intake switch
- Signed webhook verification, opaque request references and separate owner and customer email delivery
- Responsive image delivery, strict security headers and a deliberately separate boundary from RepairOS
Verification
- Custom-domain, TLS, route, header and production-function checks on the live service
- A controlled production request proving capture, owner alert, customer acknowledgement, reference consistency and reply routing
- 136 Vitest checks, a production build and CSP verification at the delivery checkpoint
- 118 Playwright journeys across desktop, tablet and mobile at the delivery checkpoint
- Search indexing remains deliberately held while the remaining operational launch gates are closed
Product screens
Built for real decisions.
Lessons carried forward
What the work taught me.
- Trust grows when a service says what has not happened yet as clearly as what happens next.
- A simple form can still carry a serious security and delivery contract behind the interface.
- Release gates are part of product quality when the website opens a real operational path.