Inspiration
A student club is ready to send its weekly update. Someone asks AI to draft the email, a second person changes the meeting time, and a third needs to check the attachment. By the time someone types “approved” in chat, it can be hard to tell which version they reviewed. Before the Click gives teams one place to see what will happen, decide whether it should go ahead, and check the result afterward.
What it does
A user signs up with a unique username, creates a workspace, and drafts an action by hand or with AI. The action preview shows what will change and who or what it will affect. Reviewers can approve, reject, or request changes in order. Editing the action creates a new version and clears the previous approvals. Once it clears review and policy checks, an authorized workspace member can explicitly run it and see the verified result in the audit history.
| Before the Click | How the workspace handles it |
|---|---|
| A chat prompt leaves the destination and side effects unclear. | The action preview shows the proposed content, destination, and changes before anyone approves it. |
| Reviewers have to search chat threads to see who needs to respond. | The approval queue shows each reviewer’s decision and who is next. A change request returns the item to its author for revision. |
| The draft changes after someone approves it. | Each approval is tied to a specific version. A revision starts a fresh review. |
| A plausible AI suggestion could still violate a team rule. | The server checks workspace policies and permissions before running the action. |
| Double-clicking or retrying could create another record. | The server claims the approved version before executing it. A repeat request for a published workspace record returns the existing result. |
| A success message leaves the team unsure whether the change landed. | The app reads the result back and records the outcome, approved version, and decisions in an exportable audit history. |
| Team proposals and files may end up visible outside the team. | Workspace membership limits access to records and attachments. Users sign in with distinct usernames and can recover their account using a recovery code. |
How we built it
Next.js, React, and TypeScript power the site and server routes. PostgreSQL on Supabase stores workspace data, and Supabase Storage holds private attachments. The application manages its own username accounts, sessions, and recovery codes. Server-side checks enforce membership, review order, and the approved version. Google Gemini can draft the proposed action, with OpenRouter available as a fallback. Vercel hosts the site.
Challenges and current status
The hardest part was keeping a review valid when someone edited the proposal or retried execution. Production testing covered the workflow with separate users, including review order, revision, stale approvals, record publication, repeat requests, and audit export. The Gmail, Google Calendar, and Google Drive connectors are implemented and tested with simulated provider responses. The production app now starts Google OAuth for each connector. Test-account consent and the live send, event creation, and file move still need verification.
Contribution
I’m Raouf Khalid. I designed the landing page, action preview, and approval workflow, researched how people could use the product in everyday work, and helped manage backend setup and verification. OpenAI Codex wrote the code.
Sources
Built With
- google-gemini
- next.js
- oauth-2.0
- openrouter
- postgresql
- react
- supabase
- typescript
- vercel