A conference platform that had to function as more than a brochure site: schedules, accepted papers, submissions, attendee support, and dynamic data all had to live in one coherent product.
Problem
Conference sites often fracture into static pages, forms, and ad hoc updates. This build needed to support real conference operations such as schedules, accepted-paper visibility, and attendee guidance while staying maintainable for organizers.
Timeline
Conference workflow framing
I approached the project as a working conference system, which meant treating schedules, papers, and support requests as core features rather than side pages.
The repository contains dedicated sections for schedules, accepted papers, submissions, and support tooling.
Dynamic data layer
The backend layer was designed to serve dynamic conference information through reusable API routes and a cached connection helper.
The repo includes a Mongo helper with cached client/db state and multiple conference-related API routes.
Conference interfaces
Instead of letting conference data live in scattered documents, I surfaced it through dedicated interfaces that match how authors and attendees actually navigate.
The repository includes dedicated data modules and pages for schedules, accepted papers, and submissions.
Support and organizer signals
I complemented the public-facing pages with support integrations and internal API utilities that better reflect the needs of an active conference platform.
The repo includes Dialogflow integration and API routes for flag-count style reporting.
Key Decisions
Schedules, accepted papers, and submission-related information shift during the lifecycle of a conference and cannot be managed comfortably as hand-edited static content alone.
I treated the conference as an application problem, not just a content problem, and used API routes plus Mongo-backed data handling for the dynamic pieces.
Tradeoff: This added backend responsibility to a site category that many teams would keep mostly static.
Impact: The product could represent real conference operations instead of only the public marketing layer.
Attendees and authors need direct access to schedules, accepted papers, and submission information without digging through generic pages.
I gave schedules, accepted papers, and submissions dedicated paths and supporting data structures.
Tradeoff: More dedicated views means more upkeep for organizers and developers.
Impact: The conference information architecture feels intentional rather than improvised.
A conference product serves both attendees and organizers, so information delivery alone is not enough.
I integrated Dialogflow support and lightweight count-oriented APIs alongside the public conference experience.
Tradeoff: Operational helpers increase scope, but they make the platform more useful during the event lifecycle.
Impact: The app reflects real event operations instead of stopping at presentation.
Architecture
The project is built on Next.js with TypeScript and SCSS, using API routes and a MongoDB-backed data layer for dynamic conference information.
The repository uses a cached Mongo helper so repeated database access does not reconnect blindly on every request.
Conference content such as schedules, accepted papers, and submissions is expressed through dedicated data files and pages, while support flows such as Dialogflow-backed assistance and flag-count APIs cover the operational side.
The project shows a practical full-stack event platform: data-backed conference pages, a reusable Mongo access pattern, API integrations, and interfaces that map to real conference operations rather than generic marketing content.
AdComSys demonstrates product thinking on an operational website category: I designed for real data flows, not only for public presentation.