PlanPerfect is a planning and calendar management tool built for non-profit organizations. It helps teams coordinate meetings, track milestones, and manage recurring events across distributed teams. This was a client project where I worked closely with the organization's leadership to deliver a solution tailored to their workflow.
Role
Lead Developer
Tech Stack
ReactTypeScriptNode.jsPostgreSQLTailwind CSS
Challenges & Approach
01
Recurring Meetings Module
The Challenge
The client needed a robust recurring meetings feature — something I had not built before. Users had to create events that repeat daily, weekly, or monthly, see them on the calendar, and be able to edit or cancel individual occurrences without affecting the rest of the series.
The Approach
Created a virtualized list approach for recurring events. Instead of generating infinite future instances, defined a 3-month rolling instance window: for the next 3 months on the calendar, recurring event instances are materialized as real records in the database. This makes individual edits and cancellations straightforward (just modify the instance row) while keeping storage bounded. A background job extends the window as time progresses, ensuring users always see upcoming occurrences without the system creating unbounded data.
02
Calendar Performance with Large Event Sets
The Challenge
Non-profits with many teams and projects could have hundreds of events visible in a single month view. Rendering all of them at once caused visible lag, especially on older devices the client's volunteers used.
The Approach
Implemented viewport-based rendering so only events visible in the current scroll position are mounted in the DOM. Combined this with memoized event position calculations and a date-range query on the backend that only returns events for the currently viewed period plus a small buffer. The result was smooth scrolling even with 500+ events in a month.
03
Multi-Timezone Team Coordination
The Challenge
The non-profit had volunteers across multiple time zones. Meetings created in one timezone needed to display correctly for everyone, and daylight saving transitions caused edge cases where events would shift by an hour.
The Approach
Stored all event times in UTC in the database and performed timezone conversion exclusively on the client side using the user's local timezone. For recurring events, the recurrence rule stores the original local time and timezone, and each instance is computed in that timezone before converting to UTC — ensuring that a "9 AM every Monday" meeting stays at 9 AM local time even across DST boundaries.
