Case study
Room Calendars
An internal application designed to check room availability quickly and find a meeting without browsing Outlook calendars one by one.
Introduction
Room Calendars started after the company stopped using a SaaS tool for meeting room management. Part of the follow-up moved directly back into Outlook.
The information was available, but checking it quickly became tedious as soon as several rooms had to be compared over several days. Even a simple check required moving between calendars and repeating the same steps.
Reception also needed to find a room quickly when a visitor knew a participant's name, but not where the meeting was taking place.
The project therefore had two main needs: make room availability easier to check and make it possible to find a meeting from the information already available.
Understanding the Need
Before starting development, I took time to observe how Outlook was being used and how rooms were managed in the Microsoft environment.
This first analysis confirmed several points:
Comparing several rooms required too many steps.
Users had to move from one calendar to another to get an overview. Loading times were not suited to a quick check, and the more rooms and days were involved, the more painful the navigation became.
Search did not match reception's need.
Finding a meeting from a participant or partial information was still not practical.
The data already existed in Microsoft.
Rooms and their calendars could be retrieved through Microsoft Graph API. There was no need to recreate a second source of data.
Project Goals
Development was organized around four priorities:
Check availability quickly
Display several rooms and several days in the same interface.
Find a meeting
Allow specific profiles to search for a meeting from a participant or other available information.
Keep the interface readable
Show enough information without turning the calendar into a table that is hard to scan.
Limit waiting time
Avoid making each consultation depend directly on Microsoft Graph response times.
Designing With Users
I worked in small iterations with the project manager and future users. The calendar went through several versions before reaching a satisfying organization.
The main difficulty was not displaying meetings, but making the whole view readable in a few seconds. Several rooms, several days, and different meeting details had to fit in the same interface without feeling overloaded.
The main screens were first prepared in Figma. The mockups made it possible to test the organization of information before development and made discussions more concrete.
User feedback then guided several adjustments to spacing, grouping, and visual hierarchy. On a tool used regularly, a few lost seconds or information that is hard to spot can quickly affect daily use.
Organizing Development
The project was split into tasks tracked with GitHub Issues. The most important subjects were then separated into smaller subtasks, each developed on its own branch before being integrated through a Pull Request.
This helped me keep a clear view of progress while working separately on the different topics: Microsoft Graph integration, search, cache, user rights, and front-end interactions.
I also chose to handle early the part I considered the riskiest: retrieving and organizing data from Microsoft Graph.
If that part could not provide reliable data or acceptable response times, a large part of the solution would have needed to be reconsidered. Validating it first avoided building the rest of the project on an uncertain base.
Working With Microsoft Graph
Microsoft Graph API made it possible to retrieve rooms and their meetings, but calling the API directly on every display would have made the application too dependent on an external service.
I therefore added several mechanisms to keep the interface fast:
JSON batch requests
Several requests can be grouped into one call to reduce the number of requests sent to Microsoft Graph.
MySQL storage
The data needed for display is stored locally so the API is not called on every consultation.
Cache for the most used periods
Meetings for the current month and the next month are kept locally to cover most common use cases.
Automatic refresh
A cronjob refreshes data every ten minutes so it is ready before a user opens the calendar.
This approach keeps the interface responsive while limiting calls to Microsoft Graph.
Planning for Failures
The cronjob improves performance, but I did not want the whole application to depend on it always running correctly.
The data therefore also has a validity period. If the cronjob stops running and the cache expires, the application can trigger a new synchronization itself.
In that situation, the first user can wait up to around forty seconds while the data is retrieved. The following consultations then return to normal behavior until the next expiration.
This mechanism lets the application keep working without manual intervention when there is a temporary issue with the scheduled task.
Security and Access Rights
Authentication uses Microsoft SSO. Users sign in with their existing professional account, without adding a second password system to maintain.
Rights vary depending on the need. Room availability remains accessible to the relevant users, while some features, such as advanced meeting search, are limited to authorized profiles.
Exchanges with Microsoft Graph and the browser are encrypted. Automated tasks are also protected so they cannot be triggered freely.
Calendars can contain information about participants, schedules, or the organization of some meetings. Access management was therefore part of the project from the beginning.
Technical Choices
PHP back-end
The back-end was developed in PHP on the internal framework used for the company's applications. Business logic was separated as much as possible from the rest of the application to make future changes and component reuse easier.
TypeScript
TypeScript was used for browser-side interactions. Typing helped keep the code more predictable on an interface with many interactions.
Tailwind CSS
Tailwind CSS made it possible to iterate quickly on the different interface versions while keeping the visual presentation consistent.
MySQL
MySQL stored data retrieved from Microsoft Graph and made common consultations faster.
Following the Existing Environment
Rooms were already managed in the Microsoft environment. I preferred using that existing source instead of maintaining a second list directly in Room Calendars.
When a room was added, updated, or removed on the Microsoft side, the application could retrieve those changes without requiring a second action.
This reduced maintenance and, more importantly, avoided having two systems slowly drift apart.
Result
Before
Comparing several rooms meant moving between Outlook calendars and repeating the same searches. Finding a meeting could also become difficult when a visitor only had partial information.
After
Room Calendars centralizes availability for several rooms in a single interface and lets authorized profiles find a meeting from a participant or available information.
Booking remains managed in Outlook, while Room Calendars simplifies the consultation step before that. User feedback confirmed that this flow was faster and more practical in daily use.
What I Would Do Differently Today
The project was developed fairly quickly. The first priorities were to validate the Microsoft Graph integration, build the main features, and evolve the interface from user feedback.
Functional and unit tests were therefore not integrated from the first versions, and the project did not have a real automated testing base.
With hindsight, I would put that base in place much earlier today. Business logic and the Microsoft Graph integration would be covered by automated tests, executed by CI on every Pull Request.
I would also add more technical monitoring around Microsoft Graph response times, synchronizations, and database performance. That would help detect degradation earlier, before it has a visible impact on users.
What This Project Taught Me
Room Calendars let me work across a full business application project: understanding the need, mockups, user discussions, architecture, external API integration, performance optimization, and production deployment.
The project also confirmed the importance of handling the main technical risks early. A good interface is not enough if the data arrives slowly or unreliably.
Finally, the different calendar iterations reinforced an idea I still keep in mind today: when a tool is used regularly, interface details and response times have a direct impact on everyday work comfort.