Luminary - IWD Project

Introduction

It's the month of March, and the month of International Women's day, and at the Rise Academy frontend track, we've been split across 3 teams to work on impactful projects solving real problems women in society - Nigeria and Africa more specifically - face today.

One of these projects which I was assigned to and would be writing about is Luminary.

Luminary is a community-powered directory and news platform celebrating women who are driving change across all fields — business, science, arts, activism, sport, technology, agriculture, education, and more. It allows anyone to nominate or self-submit, is searchable by name and field, and surfaces daily and weekly news of women making impact globally.

My Team and I would be working over the next few weeks to bring Luminary to life, for this week, we created the Landing page. I would be writing about how it went, my role in the project, and the lessons I learned so far.

Week 1

Project Setup Phase

The setup phase for the project started out with each team member getting a role assigned, we are all primarily frontend developers on the project, but all have a supplementary role to manage one aspect of the project,
available roles were;

• Product Lead: Owns the PRD, scope, and feature prioritisation.
• Engineering Lead: Oversees technical architecture and approves all PRs into the prod branch.
• Design Lead: Owns the Design System, logo, and UI consistency.
• Lead Maintainer: Manages the repository and branching strategy.
• Backend Lead: (Borrowed from other tracks) Manages API integration and database schema.
• People Manager: Manages workflows, team synergy, and escalates issues to the instructor.

Once we had our roles assigned, the Lead maintainer, Isaac Shosanya created the repository to manage the project, I was assigned the role of Product Lead along with Ramnan Ramyil and we worked on the product documentation and feature prioritization. Other team members carried out their respective roles and documentation. A designer from the design track joined the team and helped create a Figma design file for the landing page. Once the foundation for the project was complete, we begun development.

My Contributions as Product Lead and Frontend Engineer

As a Frontend engineer on the project, I worked on the Hero section of the landing page, it consisted of a header text, a cta, image and some metric information for Luminary, using placeholder numbers for now.

As a Product Lead, I also carried out the following;

• Onboarded team members to our project channel on the project management tool being utilized - ClickUp
• I created custom task statuses that would align our project management process closer to our development processes
• I added tasks and assignees for each member to the ClickUp board
• I recorded a walkthrough video for the full task completion pipeline, from issue creation -> feature/task completion, and all that is required of team members in between.

Lessons Learned

So far, I have learnt and picked up improvements to writing commit messages from the standards in the documentation laid down by our Lead maintainer.

Week 2

Specific Features Implemented

This week I developed the UI and API integrations for Nominations of other women via a Nomination form on the application;

• Built the full nomination form UI.
• Integrated backend APIs for frontend consumption during nomination and self-submission form submissions.

Technical Implementation Breakdown

• Form UX logic: Implemented tab switching between nomination and self-submission panels, section collapse/expand accordion behavior to match designs precisely, and dynamic link inputs.
• Image preview: Added file preview rendering in the thumbnail circle using the FileReader API.
• Payload mapping: Transformed UI inputs into the backend payload shape .
• Submission flow: Added async JavaScript fetch integration with status feedback and error handling.

BaaS Tool and Integration

We chose Supabase as our BaaS. I reviewed the nomination service and payload requirements, and matched the frontend submission shape to match the Supabase-backed tables as expected on the backend for nominations, nominee & nominator.

Challenges & Resolutions

• Field mismatches between UI and API: The backend expected first_name/last_name fields, so I added name-splitting logic for to match the required payloads.
• Handling two form modes: I scoped dynamic elements and payload building to the active panel so both nomination and self-submission submit correctly.

What I Learned This Week

This week, from my work on the submissions flow for nominations, I learnt how to integrate API requests for complex form structures and improved my skills with UI DOM and Data manipulation in Frontend development.

Week 3

Specific Features Implemented

This week I worked on the admin-side management interfaces and the user-facing news experience for the application;

• Built the admin nominations management UI with filtering, approval and rejection actions.
• Developed the admin news article interfaces, including the add article page and shared admin sidebar behavior.
• Built the user-facing news listing page and linked it into the existing user navigation.

Technical Implementation Breakdown

• Admin nominations dashboard: Implemented a responsive nominations table and card view, filter controls, action menus, and status badges to support moderation workflows.
• Backend integration for moderation: Reviewed the nomination service and related admin routes, then connected the frontend list, search, approval and rejection actions to the authenticated backend endpoints.
• Reusable admin shell: Refactored the sidebar styles and JavaScript into shared files so the same layout and active state behavior can be reused across admin pages.
• News experience UI: Built the add article page for admins and the public news page for users, using clean mock data and responsive image handling to match the provided designs closely.

BaaS Tool and Integration

We continued using Supabase through the existing backend layer. For this week, I reviewed the nomination admin service, controller and routes, and mapped the frontend moderation UI to the backend responses so nomination records could be fetched, filtered, approved and rejected correctly from the admin interface.

Challenges & Resolutions

• Matching backend data to the UI structure: The nomination data returned from the backend needed normalization before it could fit the table design, so I mapped nested nominee and nominator fields into a frontend-friendly shape.
• Reusable navigation across admin pages: The sidebar active state did not initially work consistently across routed pages, so I updated the matching logic to normalize paths and moved the sidebar code into shared files for reuse.

What I Learned This Week

This week, from building both the admin tools and the public news experience, I learnt more about integrating authenticated frontend flows with backend endpoints, structuring reusable UI logic across multiple pages, and translating design mockups into responsive interfaces that are easier to extend as Luminary grows.

Week 4 - Final Retrospective

4 Weeks of back-to-back collaboration and development and we're finally at the finish line, for now at least. It has been a great sprint and I can say we've been able to achieve a great product at the end of it, let's dive in to the details for this week's coverage while looking back at the project as a whole in retrospect, after you...

Specific Features Implemented

This week I focused on integrating a headless CMS into the application and shipping final polish across the frontend;

• Built a custom Sanity CMS client layer and article service module to power dynamic news content across the application.
• Refactored the entire frontend codebase folder structure for JavaScript, CSS, and HTML pages to improve maintainability.
• Fixed responsiveness issues on the article page, featured sections, and nomination forms.
• Added landing page animations and a loading state for the articles feed.
• Resolved lingering bugs including hero image rendering, nomination payload formatting, and broken navigation links.

Technical Implementation Breakdown

• Sanity CMS client: Built a lightweight, SDK-free integration layer (sanity.js) that exposes GROQ querying, document mutations, and image uploads against Sanity's HTTP API, keeping the frontend dependency-free.
• Article service module: Created articles.js on top of the client layer with functions to fetch published articles, retrieve a single article by slug, and render article cards into the DOM dynamically.
• CMS integration across pages: Connected the CMS service to the news listing page, individual article page, featured stories section on the landing page, and the admin add-article flow so content is now managed from Sanity rather than hardcoded.
• Codebase restructuring: Reorganized the JavaScript, CSS, and HTML files into cleaner folder hierarchies, updating all import paths and script references across the application to match.
• Bug fixes and polish: Fixed the nomination form to correctly pass profile images in the payload, added remove buttons for dynamic link inputs, corrected hero image paths and optimized the hero asset to a lighter format.

Challenges & Resolutions

• Keeping the CMS integration lightweight: Rather than pulling in the full Sanity SDK, I wrote a minimal client using native fetch and URL construction, which kept the bundle lean and gave full control over how queries and mutations are handled.
• Coordinating the folder restructure with active development: Restructuring the file hierarchy while other team members had open branches required careful communication and path updates to avoid merge conflicts across pages, styles, and scripts.

What I Learned This Week

This week, from building the CMS integration and wrapping up the sprint, I learnt how to integrate a headless CMS into a vanilla JavaScript application without relying on framework-specific SDKs, and improved my understanding of GROQ as a query language for content APIs.

Sprint Retrospective

A milestone worth celebrating

Over four weeks, we took Luminary from a blank repository to a fully functional community platform, a searchable directory of women driving change, a moderated nomination pipeline, and a CMS-powered news experience — all built by a team of frontend developers learning to collaborate across product, engineering, and design roles.

What went well

• Clear role ownership from day one meant each team member knew what they were responsible for, which kept decisions moving and reduced bottlenecks throughout the sprint.
• Incremental integration over big-bang merges :shipping features in focused pull requests made code reviews manageable and kept the main branch stable.
• The move to Sanity as a CMS gave us a clean content management layer without adding backend complexity, and the lightweight client approach kept the frontend simple.

What I would do differently

• Set up a shared environment configuration earlier. Hardcoded API URLs and tokens caused unnecessary friction when switching between local and deployed environments; a centralized config from week one would have saved time.
• Invest more in responsive testing early on. Several responsiveness fixes landed in the final week that could have been caught sooner with a mobile-first review step during each PR.

What surprised me

The amount of coordination required to restructure a codebase mid-sprint without disrupting teammates was more involved than I expected. It reinforced how important clear communication and small, well-scoped commits are when working on shared code.

Key technical lessons from the sprint

• Integrating backend APIs with complex frontend form structures requires careful attention to payload shape alignment between what the UI collects and what the API expects.
• A headless CMS can be integrated with just native browser APIs when the requirements are straightforward.
• Reusable UI patterns like the admin sidebar and shared navigation should be extracted into shared modules early to avoid duplicated effort across pages.
• Writing clean, conventional commit messages and maintaining a consistent branching strategy makes the codebase significantly easier to navigate as the project grows.

Shout-outs

A big thank you to the entire Luminary team for a strong sprint. To Isaac for keeping the repository and backend running smoothly, Daniel for thorough code reviews and architectural guidance, Ramnan for co-leading product decisions, Michael for the design system and UI consistency, Emmanuel for keeping us coordinated, and Ariyo for volunteering design support, and finally special thanks to Sophia Ahuoyiza, The Tabi and Rise Academy Team for facilitating all of this, It was a great experience building this together.

Contributors

-Product Lead 1: Ramnan Ramyil
-Product Lead 2: Awoyemi Abiola
-People Manager: Emmanuel Dania
-Lead Maintainer: Isaac Shosanya
-Design Lead: Michael Omonedo
-Engineering Lead: Daniel Chisom
-Backend Lead: Isaac Shosanya
-Volunteer (UI/UX): Ariyo Taiwo

Github Repository

Luminary

I'm not crying, you are