Planket
A shared calendar that shows when everyone is free and sends a plan in three taps.
Open the web app (opens in a new tab)
- Role
- Sole developer: product, design, Next.js app, Capacitor iOS and Android builds, Supabase backend, store listing
- Dates
- Oct 2026 – present
- Status
- Web app live · stores next
- Stack
- Next.js, Capacitor, Supabase · 50 tests
Technical decisions
| Decision | What I chose | Instead of |
|---|---|---|
| Shared availability without disclosing personal schedule details | Mask calendar titles and aggregate individual schedules into group free-time gingham blocks | Showing full event titles or requiring members to post screenshots of their personal calendars |
Results
- taps to send a plan
- 3
- tests in the 21 Oct run
- 50
- authored database migrations
- 11
Development and source inventory checked 26 October 2026; the 50-test result remains dated 21 October. No public store release is claimed.
Full engineering notes
Summary
Planket is a shared calendar for friends and groups. It puts each person’s day side by side, weaves the stretches when everyone is free into the grid as gingham, and lets you send a plan in three taps: pick a time, tap an idea chip, send. Replies are In, Maybe or Can’t, or a suggested time, and the host can move the plan. Friends see busy blocks rather than titles unless you share them. I designed and built the whole product: a Next.js app packaged for iOS and Android with Capacitor, a Supabase backend with row-level security, push notifications and Google Calendar write-back. The web app and backend are live; the iOS and Android builds are prepared but not yet in a store. Development through 26 October adds better first-run setup and account reconnection, crew creation, revised calendar and time controls, and Google Calendar mirroring that follows a plan’s reply state.
The problem
Planning with friends fails at the first step: nobody can see when everyone is free, so the plan lives in a chat thread and dies there.
- Calendars show one person’s week at a time, so finding a shared gap means comparing screenshots in a group chat.
- A plan needs an answer from each person, not a pile of replies to scroll back through.
- Friends should see that you are busy without seeing what you are doing, unless you choose to share it.
- The composer should not make decisions for you: nothing is pre-selected, and three taps are enough to send.
My role
What I owned
- The product and its identity: one column per person, shared free time woven in as gingham, idea chips that fit the free time, drag or tap to plan.
- The Next.js 16 app, exported statically and packaged for iOS and Android with Capacitor 8.
- The Supabase backend: Google and Apple sign-in, row-level security, account and crew data, eleven authored migrations, and push and Google-token functions.
- APNs and FCM push integration, Sign in with Apple, and Google Calendar mirroring: tentative invitations, confirmed plans after acceptance, and removal after decline or cancellation.
- The App Store listing: screenshots, review notes and the store document.
What I did not own
- Next.js, React, Capacitor, Supabase and the other open-source and platform services it is built on.
- No design collaborator, QA team or outside code review.
- Push has been verified on the backend through to an FCM authentication failure; delivery to a real device has not been confirmed.
Why I made each decision
Shared availability without disclosing personal schedule details
- Because
Friends want to find overlapping free time quickly without exposing what each personal event is. The engine intersects availability into collective free blocks, rendering member columns with busy blocks rather than event titles unless an event is explicitly marked public to the group.
- Trade-off
The host cannot see why someone is busy, only that they are unavailable, so planning relies on the three response states (In, Maybe, Can't) or suggesting an alternate time.
Testing
The 21 October verification record reports 50 Vitest tests passing in 4 files and backend checks through to FCM. The 26 October source adds calendar mirroring and onboarding fixes; no fresh combined pass count is claimed for this update.
- Vitest tests passing
- 50
- Authored database migrations
- 11
Results in detail
A public web app, with continuing development
The shared calendar and planning flow are available on the web. Development continues across the Supabase backend and Capacitor builds for iOS and Android; the mobile apps are not in the stores yet.
Calendar sync that follows the reply
The latest implementation mirrors unanswered invitations as tentative events, confirms accepted or hosted plans, and removes declined or cancelled plans. It also improves account reconnection and preserves onboarding choices through the sign-in flow. Google Calendar OAuth verification is still pending.
Refined planning and store preparation
Recent builds revise the calendar and time editor, plan popup, crew creation, Friends and You screens. iOS and Android builds and store materials are prepared; neither is a public store release.
Stack and release record
Platforms
Web (live), iOS (Capacitor): development builds and App Store listing prepared; no public store release, Android (Capacitor): release bundle built, not yet on Google Play
Built with
TypeScript, Next.js 16 (static export), React 19, Tailwind CSS 4, Capacitor 8, Supabase (Postgres with row-level security, auth, edge functions), APNs and FCM push, Sign in with Apple, Google Calendar API, Vitest, Firebase Hosting
Status in full
The web app is live, with iOS and Android builds in preparation. Development through build 11 on 26 October improves onboarding, account reconnection, crew creation and Google Calendar mirroring. Google Calendar access still awaits OAuth verification, and push notifications await complete real-device testing. Neither mobile app is publicly released.