Recap
A single memory of your engineering work, across every tool it happens in.
- Role
- Designer and engineer
- Context
- Personal product
- Timeline
- 2026
- Platforms
- Web
- Status
Overview
Engineering work is scattered: commits and pull requests in GitHub, comments in Figma, builds and OTA updates in Expo, threads in Slack, tickets in Jira and ClickUp. Remembering what you did yesterday means opening six tabs.
Recap connects to those tools and pulls the activity into one place: a morning brief of what needs attention, a dashboard and history across tools, and monthly and sprint reports generated from the real activity and exported as documents. Teams can work in organisations, and paid plans are billed in naira through Paystack.
My role
I designed and built Recap on my own: the product, the React frontend, the Node.js and Express backend, the MongoDB data model and every integration.
The challenge
Six tools, six APIs, six ideas of what an event is. The hard part is not fetching data but making a commit, a Figma comment and a Jira transition read as one coherent day, while holding other people’s access tokens safely.
- Each provider has its own auth, rate limits and data shape.
- Users hand over access tokens to their work tools.
- Reports are only useful if the timeline is complete.
Architecture
Provider APIs
Third party
Integration layer
Built by me
Activity store
Built by me
Brief, dashboard and reports
Built by me
Engineering challenges
One event shape for six tools
- problem
- Every provider describes activity differently.
- constraint
- The dashboard, history and reports need to treat all of it the same way.
- approach
- Each integration is a service that converts provider data into one internal activity shape before it is stored, with short-lived caching so repeated views do not hit provider rate limits.
- result
- Adding a tool means writing one service; the rest of the product does not change.
Holding other people’s tokens
- problem
- Users connect their own GitHub, Figma, Expo and other tokens.
- constraint
- A leaked token is access to someone’s work. Keys must never be readable at rest or sent back to the browser.
- approach
- Keys are encrypted with AES-256-GCM before they are stored, decrypted only on the server when fetching on the user’s behalf, and never returned to the frontend in plain text.
- result
- Each user’s requests run with their own keys, and a database leak does not expose them.
Payments you can trust
- problem
- Subscriptions are paid in naira through Paystack.
- constraint
- Anyone can send a request to a webhook URL claiming a payment succeeded.
- approach
- Every Paystack webhook is checked against its HMAC-SHA512 signature before anything is processed, and the transaction is verified by reference before a subscription changes.
- result
- Plans only change on genuine, verified payments.
Outcome
6
tool integrations
Live
userecap.rufixduke.ng