DEV Community: Oluchi Okwuosa

Wrapping Up Ekehi: The Code, The Team, and What I Am Taking With Me

Oluchi Okwuosa — Sat, 28 Mar 2026 08:19:12 +0000

Ekehi, meaning "sunrise" or "discovery", is an open-source business resource platform built for women entrepreneurs in Nigeria and across Africa. The problem it solves is real: funding exists, grants exist, credit schemes and training programmes exist, but finding them is genuinely hard, especially if you are not already connected to the right people. Ekehi puts all of that in one place. A searchable, filterable directory of funding opportunities, credit products, and training resources, built mobile-first for the women who need it most.

The platform is live at ekehi.netlify.app and the full codebase is open source. Built by 15 people across four sprints. See it here: Ekehi on GitHub

This is my final sprint entry. Four weeks, three previous articles, and a lot of lessons.

The Product and Why It Exists

Ekehi is a business intelligence platform designed to bridge the gap between women entrepreneurs and limited access to capital, professional networks, and visibility. It serves as a searchable, filterable hub that connects women-led SMEs with active grants, credit schemes, and growth training, all in one place.

The stack the team was assigned to build with is Vanilla HTML, CSS, and JavaScript on the frontend with Node.js and Express.js on the backend and Supabase handling the database and authentication. For many of the women this platform serves, mobile is the primary device and connectivity is not always reliable. Every technical decision on this project sits inside that context.

The choice of purple as a primary colour was intentional. By aligning with the global identity of International Women's Day, the platform signals immediate trust and dignity to the women it is built for.

The Journey So Far

I published articles covering my work in each sprint. Here is the quick version:

Sprint 1 — Built the Mission section on the landing page. The technical challenge was positioning four decorative SVG petal icons around the eyebrow label using absolute positioning rather than flexbox, which kept them from disrupting the layout flow.

Sprint 2 — Built the filter section on the Opportunities page. This was the most layered task I worked on across the whole sprint. ES module imports, a shared component system, CSS scoping, JavaScript wiring, and a filter state object all in one task.

Sprint 3 — Refactored the What We Offer section into a two-column interactive layout with CSS Grid and JavaScript click handlers for item activation.

Each of those sprints has a full write-up. This article covers Sprint 4 and wraps up the full journey.

What I Shipped This Week

My final task was building the guide detail page at client/resources/guides/detail/. This is the reading page that renders a single guide's full content when a user navigates from the resources page.

The HTML Structure

Before writing any CSS or JavaScript, the HTML structure came first. The page has two main areas: a sidebar on the left and an article on the right. The semantic element choices were deliberate:

<main class="container">
  <div class="guide">
    <aside class="guide__sidebar">
      <a href="/resources/" class="guide__back">← Go back</a>
      <nav class="guide__toc" aria-label="Table of contents">
        <div id="toc-root"></div>
      </nav>
    </aside>
    <article class="guide__content">
      <h1 class="guide__title" id="guide-title"></h1>
      <div class="guide__body" id="guide-body"></div>
    </article>
  </div>
</main>

<aside> is the correct semantic tag for secondary content that supports the main content. <nav> inside the sidebar is correct because the table of contents is navigation within the page. <article> is correct for the main content because a guide is a self-contained piece of long-form content that makes sense on its own.

The id="toc-root" and id="guide-body" divs are empty mounting points. JavaScript fills them with content at runtime.

The Layout

The two-column layout uses CSS Grid with 250px 1fr rather than 1fr 1fr:

.guide {
  display: grid;
  grid-template-columns: 250px 1fr;
  gap: var(--space-16);
  padding-block: var(--space-10);
  align-items: start;
}

The sidebar has a predictable fixed width since it just holds a list of links. The content area should take all the remaining space since it holds long-form article text. Equal columns would waste space on the sidebar and squish the content. align-items: start keeps the sidebar from stretching to match the full height of the article.

The sidebar is sticky so it stays visible as the user scrolls through the long content without moving with the page.

The Routing

There is no API endpoint for guides yet so the page uses hardcoded dummy data. The routing reads a guideId from the URL using URLSearchParams:

const params = new URLSearchParams(window.location.search);
const guideId = params.get("guideId");

A URL like /resources/guides/detail/index.html?guideId=1 gives guideId the value "1". The guides object is keyed with string keys to match. If the guideId is missing or does not match anything in the data, the page shows a friendly error state instead of breaking.

The Collapsible Table of Contents

The issue specifically required a collapsible table of contents. Each section heading is a button that toggles its sub-items open and closed using aria-expanded:

headingBtn.addEventListener("click", () => {
  const isExpanded = headingBtn.getAttribute("aria-expanded") === "true";
  headingBtn.setAttribute("aria-expanded", String(!isExpanded));
  itemList.style.display = isExpanded ? "none" : "flex";
});

aria-expanded tells screen readers whether the section is open or closed so keyboard and assistive technology users know the state of the TOC without having to guess.

The TOC items are <button> elements rather than <span> elements. This came up as a PR review comment from GitHub Copilot. Spans are not keyboard focusable by default which means keyboard users could not interact with the TOC. Buttons are focusable natively and behave correctly without any extra work.

The active item gets a tilde prefix through CSS alone with no extra JavaScript needed:

.guide__toc-item--active::before {
  content: "~ ";
}

Responsive Behaviour

On mobile the table of contents is hidden entirely and the layout collapses to a single column. The decision to hide rather than collapse the TOC was deliberate. On a small screen a long list of navigation links before the article content creates friction. The reader just wants to get to the content. The Go back link stays visible since it sits outside the TOC as a sibling element, not inside it.

Full Sprint Retrospective

What went well was the tooling and the structure. GitHub Issues, ClickUp, and the branching strategy kept the project moving even when things got messy. Having clear acceptance criteria on every issue meant you always knew what done looked like. The team leads showing up and keeping momentum going made the difference in weeks where things could have stalled.

What surprised me was how much communication, or the lack of it, can affect a whole team. People not showing up to tasks, going quiet when help is needed, and being unwilling to step outside their assigned role even when the whole team might suffer for it. That was hard to watch and harder to manage. Leadership also surprised me. It is not something you prepare for. You just have to stand up and take the lead even when others are not following, and figure it out as you go.

What I would do differently is take up more responsibility earlier. I held back in some areas where I could have stepped in and I think the team would have benefited if I had been more proactive from the start. I would also push harder on communication from week one rather than trying to manage the gaps later.

What I am most proud of is the filter section on the Opportunities page from Sprint 2. It was the most layered task I worked on across the whole sprint. ES module imports, a shared component system, CSS scoping, JavaScript wiring, and a filter state object all in one task. Working through a conflict between what the issue specified and what the codebase actually supported at the time, methodically rather than panicking, was a personal win for me.

Key Technical Lessons

CSS Grid vs Flexbox. I went into this project knowing Flexbox but not really knowing when to reach for Grid. By the end I understood it clearly. Flexbox for one-dimensional layouts, Grid for two-dimensional ones. Every two-column layout I built across the sprint used Grid because both columns needed to be aware of each other vertically.

Working within a design system. Every value traces back to a CSS custom property. No hardcoded colours or values. This discipline took getting used to but I understand now why it matters. Consistency across a codebase with 15 contributors would fall apart without it.

CSS scoping. When a component renders its own HTML at runtime through JavaScript, you cannot add classes to its internal elements directly in your HTML. You scope your styles through a parent BEM class you control. This keeps your overrides contained to your section and leaves the shared component untouched everywhere else.

Semantic HTML is not optional. Choosing the right HTML element matters. <aside> for sidebar content, <nav> for navigation lists, <article> for self-contained content, <button> for anything interactive. These choices affect accessibility, screen reader behaviour, and keyboard navigation.

Reading someone else's code before touching it. Refactoring the What We Offer section in Sprint 3 taught me to slow down before writing anything. Read first, understand the structure, then make changes. Jumping in too quickly causes more problems than it solves.

Git as a collaboration tool. Forking, upstream syncing, pull requests, merge conflicts, ES module imports. I came into this project as a beginner and the git workflow alone taught me more than I expected. One merged PR on a real open source project teaches you more than ten personal projects built alone.

What Is Next

I plan to strengthen my JavaScript fundamentals properly before moving on. After that, TypeScript is the next step. I also want to start learning how to integrate data structures and algorithms into writing better, more efficient code. This sprint showed me that knowing how to write code is one thing. Writing code that is clean, scalable, and makes sense to someone else is entirely another.

Meet The Team

Frontend Track
Marionbraide — marionbraideinfo@gmail.com
Osezele Iboi — ejemeniboi@gmail.com
Esther Orieji — oriejiesther@gmail.com
Iyobosa — omosiyobo@gmail.com
Oluchi Okwuosa — Okwuosaoluchi95@gmail.com
Victor Okoukoni — victorokoukoni@gmail.com
Florence Onwuegbuzie — florenceworkhub@gmail.com
Fatihat — fatihatulkhaer@gmail.com

UI/UX Track
Michael Babjide Boluwatife
Fisayo Rotibi
Osuji Wisdom

Mobile Track
Gabriel Abubakar — Contributing as QA
Jesse Nwaokolo — Contributing to frontend

Backend Track
Olusegun Adeleke
Sodiq Semiu

TEE Foundation | Tabi Project | International Women's Day Initiative | March 2026

Building Ekehi Sprint 3: Code, People, and the Journey So Far

Oluchi Okwuosa — Sat, 28 Mar 2026 08:06:39 +0000

This week my task was refactoring the What We Offer section on the Ekehi landing page. The section existed already but used a static layout. The new design called for a two-column grid with a selectable list on the left and a static contextual image on the right, with the active list item highlighted in lavender.

The Task

This week's task had me refactoring someone else's code from the team and it was a whole new experience for me, having to read and understand the person's logic and idea and also looking at the new design to figure out what needs to change and what needs to remain.

The specific requirements were:

Two-column layout using CSS Grid
Four selectable items: Funding Database, Training Programmes, Business Tools, Mentorship Network
Active item gets a lavender highlight background
JavaScript click handlers so clicking an item activates it
Training Programmes selected by default on page load
Right column image stays static

Technical Decisions

Restructuring the HTML

The first step was getting the HTML structure right before touching any CSS. The existing markup did not follow BEM naming consistently and had unnecessary wrapper divs adding noise without purpose.

The final structure uses semantic HTML throughout. A <ul> with <li> items for the list since they are a collection of related items. Each <li> contains a <div> for the card rather than <article>. Article is for self-contained content that makes sense outside of its context, like a blog post. A feature item in a list does not meet that bar, so a plain div is more accurate.

The BEM naming across the section:

offerings (section)
  offerings__grid (two column wrapper)
    offerings__left (left column)
      offerings__title
      offerings__list (ul)
        offerings__item (li)
          offerings__card (div)
            offerings__card-title
            offerings__card-description
    offerings__right (right column)
      offerings__subtitle
      offerings__image

CSS Grid for the Two Column Layout

The layout decision between Flexbox and CSS Grid came down to what the design needed. Flexbox handles one dimension, either a row or a column. CSS Grid handles two dimensions simultaneously. Since the two columns needed to be aware of each other vertically, Grid was the right choice.

.offerings__grid {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: var(--space-10);
  align-items: stretch;
}

align-items: stretch makes both columns the same height, which is what allowed the image to fill the full height of the right column to match the Figma design.

Inside the left column, Flexbox handles the vertical stacking of the title and list since it is one dimension. This is the most common real world pattern: Grid for the macro layout, Flexbox for the micro layout inside it.

Styling the Active State

.offerings__card--active {
  background-color: var(--color-purple-50);
}

.offerings__card:hover {
  background-color: var(--color-primary-subtle);
  cursor: pointer;
  padding-inline: var(--space-4);
}

No hardcoded colour values. Everything references the design system's CSS custom properties.

JavaScript Click Handlers

The interactivity required was straightforward. Clicking a card removes the active state from all cards and adds it to the clicked one. Training Programmes gets the active class in the HTML by default so it is highlighted on page load without JavaScript needing to do anything extra.

const cards = document.querySelectorAll('.offerings__card');

cards.forEach(card => {
  card.addEventListener('click', () => {
    cards.forEach(c => c.classList.remove('offerings__card--active'));
    card.classList.add('offerings__card--active');
  });
});

The reason .offerings__card is targeted in the JS and not .offerings__item is because offerings__card--active is the class that controls the highlight and it lives on the div, not the li. You target what you need to add and remove the class on.

Responsive Styles

@media (max-width: 900px) {
  .offerings__grid {
    grid-template-columns: 1fr;
  }
  .offerings__image {
    aspect-ratio: 16 / 9;
  }
}

@media (max-width: 600px) {
  .offerings__image {
    aspect-ratio: 4 / 3;
    border-radius: var(--radius-2xl);
  }
}

On tablet and below, the two columns stack into a single column. The image switches from a fixed height to an aspect ratio so it scales proportionally on smaller screens.

Bugs Encountered

The image height was the trickiest part. The original CSS had aspect-ratio: 1/1 applied to the wrong element. It was on the right column container which also holds the subtitle text, not just the image. This clipped the subtitle. Moving the aspect ratio and border radius to .offerings__image directly fixed it. The final approach removed the fixed aspect ratio entirely and used a fixed height instead, letting object-fit: cover handle the cropping.

CSS variable math was another small one. At one point the image height was written as:

height: var(--space-10) * 10;

This is invalid CSS. Math outside of calc() does not work. The correct syntax is:

height: calc(var(--space-10) * 10);

Or just a plain pixel value. Small syntax mistake that was pretty easy to miss.

Reflections

This is the first group project I have ever worked on and that alone made
it a different experience from anything I had done before.

Using GitHub Issues made task assignment straightforward. Every task had a
clear description, acceptance criteria, and an assignee. You knew exactly
what you were supposed to build and what done looked like. That structure
made it easy to pick up work and stay focused.

ClickUp was completely new to me. Setting it up, configuring the custom
fields, managing the board day to day, and keeping it updated across a team
of 15 people was a skill I picked up entirely on this project. I did not
expect project management tooling to be something I would learn here but it
turned out to be one of the more valuable things I walked away with.

Working as the People Manager gave me a different kind of insight. Managing
people is genuinely hard, especially when communication breaks down. When
team members do not turn in their tasks or go quiet, it does not just affect
their own work, it creates more workload for everyone waiting on them
downstream. That lesson about communication and accountability is one I will
carry into every team I work with going forward.

On the technical side, coming into this project as a beginner and working
through forking, upstream syncing, pull requests, merge conflicts, and ES
module imports across three sprints was a real growth arc. The git workflow
alone taught me more than I expected. Working within a design system with
defined CSS variables and utility classes was also new. Writing styles that
trace back to a single source of truth rather than hardcoding values
everywhere is a discipline that will transfer to any professional project.

What worked well was the tooling and the cooperation when it was there.
GitHub Issues, ClickUp, and the branching strategy kept the project
structured even when things got messy. The team leads showing up and keeping
things moving made the difference in the sprints where momentum could have
stalled.

If I could do anything differently, honestly nothing. Every part of this
was a learning experience I am grateful for. I got to try things I had never
done before, sharpened my communication, took on responsibility, and shipped
real work on a real project. That is what I came for.

Meet The Team

Frontend Track:

Marionbraide — marionbraideinfo@gmail.com

Osezele Iboi — ejemeniboi@gmail.com

Esther Orieji — oriejiesther@gmail.com

Iyobosa — omosiyobo@gmail.com

Oluchi Okwuosa — Okwuosaoluchi95@gmail.com

Victor Okoukoni — victorokoukoni@gmail.com

Florence Onwuegbuzie — florenceworkhub@gmail.com

Fatihat - @khaerie

UI/UX Track:

Michael Babjide Boluwatife

Fisayo Rotibi

Osuji Wisdom

Mobile Track:

Gabriel Abubakar — Contributing as QA

Jesse Nwaokolo — Contributing to frontend

Backend Track:

Olusegun Adeleke

Sodiq Semiu

TEE Foundation | Tabi Project | International Women's Day Initiative | March 2026

Building Ekehi Sprint 3: Code, People, and the Journey So Far

Oluchi Okwuosa — Fri, 20 Mar 2026 06:55:10 +0000

The Task

The specific requirements were:

Two-column layout using CSS Grid
Four selectable items: Funding Database, Training Programmes, Business Tools, Mentorship Network
Active item gets a lavender highlight background
JavaScript click handlers so clicking an item activates it
Training Programmes selected by default on page load
Right column image stays static

Technical Decisions

Restructuring the HTML

The first step was getting the HTML structure right before touching any CSS. The existing markup did not follow BEM naming consistently and had unnecessary wrapper divs adding noise without purpose.

The BEM naming across the section:

offerings (section)
  offerings__grid (two column wrapper)
    offerings__left (left column)
      offerings__title
      offerings__list (ul)
        offerings__item (li)
          offerings__card (div)
            offerings__card-title
            offerings__card-description
    offerings__right (right column)
      offerings__subtitle
      offerings__image

CSS Grid for the Two Column Layout

.offerings__grid {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: var(--space-10);
  align-items: stretch;
}

align-items: stretch makes both columns the same height, which is what allowed the image to fill the full height of the right column to match the Figma design.

Styling the Active State

.offerings__card--active {
  background-color: var(--color-purple-50);
}

.offerings__card:hover {
  background-color: var(--color-primary-subtle);
  cursor: pointer;
  padding-inline: var(--space-4);
}

No hardcoded colour values. Everything references the design system's CSS custom properties.

JavaScript Click Handlers

const cards = document.querySelectorAll('.offerings__card');

cards.forEach(card => {
  card.addEventListener('click', () => {
    cards.forEach(c => c.classList.remove('offerings__card--active'));
    card.classList.add('offerings__card--active');
  });
});

Responsive Styles

@media (max-width: 900px) {
  .offerings__grid {
    grid-template-columns: 1fr;
  }
  .offerings__image {
    aspect-ratio: 16 / 9;
  }
}

@media (max-width: 600px) {
  .offerings__image {
    aspect-ratio: 4 / 3;
    border-radius: var(--radius-2xl);
  }
}

On tablet and below, the two columns stack into a single column. The image switches from a fixed height to an aspect ratio so it scales proportionally on smaller screens.

Bugs Encountered

CSS variable math was another small one. At one point the image height was written as:

height: var(--space-10) * 10;

This is invalid CSS. Math outside of calc() does not work. The correct syntax is:

height: calc(var(--space-10) * 10);

Or just a plain pixel value. Small syntax mistake that was pretty easy to miss.

Reflections

This is the first group project I have ever worked on and that alone made
it a different experience from anything I had done before.

ClickUp was completely new to me. Setting it up, configuring the custom
fields, managing the board day to day, and keeping it updated across a team of 15 people was a skill I picked up entirely on this project. I did not expect project management tooling to be something I would learn here but it turned out to be one of the more valuable things I walked away with.

Working as the People Manager gave me a different kind of insight. Managing people is genuinely hard, especially when communication breaks down. When team members do not turn in their tasks or go quiet, it does not just affect their own work, it creates more workload for everyone waiting on them downstream. That lesson about communication and accountability is one I will carry into every team I work with going forward.

On the technical side, coming into this project as a beginner and working
through forking, upstream syncing, pull requests, merge conflicts, and ES
module imports across three sprints was a real growth arc. The git workflow alone taught me more than I expected. Working within a design system with defined CSS variables and utility classes was also new. Writing styles that trace back to a single source of truth rather than hardcoding values everywhere is a discipline that will transfer to any professional project.

What I am most proud of shipping is the filter section on the Opportunities page from Sprint 2. It was the most layered task I worked on. ES module imports, a shared component system, CSS scoping, JavaScript wiring, and a filter state object all in one task. I also had to navigate a conflict between what the issue specified and what the codebase actually supported at the time, and working through that methodically rather than panicking was a personal win for me.

If I could do anything differently, honestly nothing. Every part of this
was a learning experience I am grateful for. I got to try things I had never done before, sharpened my communication, took on responsibility, and shipped real work on a real project. That is what I came for.

Built by 15 people across three sprints. See it here: Ekehi on GitHub

Meet The Team

Frontend Track:

Marionbraide — marionbraideinfo@gmail.com

Osezele Iboi — ejemeniboi@gmail.com

Esther Orieji — oriejiesther@gmail.com

Iyobosa — omosiyobo@gmail.com

Oluchi Okwuosa — Okwuosaoluchi95@gmail.com

Victor Okoukoni — victorokoukoni@gmail.com

Florence Onwuegbuzie — florenceworkhub@gmail.com

Fatihat - fatihatulkhaer@gmail.com

UI/UX Track:

Michael Babjide Boluwatife

Fisayo Rotibi

Osuji Wisdom

Mobile Track:

Gabriel Abubakar — Contributing as QA

Jesse Nwaokolo — Contributing to frontend

Backend Track:

Olusegun Adeleke

Sodiq Semiu

TEE Foundation | Tabi Project | International Women's Day Initiative | March 2026

Building Ekehi: A Contributor's Journal From Code to Coordination

Oluchi Okwuosa — Sat, 07 Mar 2026 09:41:02 +0000

Ekehi is a business resource platform for women entrepreneurs in Nigeria and across Africa. The problem it solves is real: funding exists, grants exist, credit schemes and training programmes exist, but finding them is genuinely hard, especially if you are not already connected to the right people. Ekehi puts all of that in one place. A searchable, filterable directory of funding opportunities, credit products, and training resources, built mobile-first.

We are a team of 15 people. We have a Product Lead, Engineering Lead, Design Lead, Lead Maintainer, and a Backend Lead. My role on this project is People Manager, handling workflows, team synergy, and making sure nothing falls through the cracks.

The Stack

Ekehi is built on Vanilla HTML, CSS, and JavaScript on the frontend, with
Node.js and Express.js on the backend and Supabase handling the database
and authentication. Supabase's built-in full-text search is particularly
relevant for a funding directory where users need to search and filter across
dozens of opportunities quickly. The design system uses DM Serif Text for
headings and Urbanist for body text. This was the stack we were assigned to build with.
For many of the women this platform serves, mobile is the primary device
and connectivity is not always reliable. Every technical decision on this
project sits inside that context.

For contributors, the project uses a tiered branching strategy:

main for stable production code
development as the integration branch where features come together before going live
feature/ branches for isolated work

Every contributor works on a feature branch, opens a pull request into
development, and waits for review before anything merges. Understanding
this flow early saved me from several mistakes.

Design

Before any frontend work began, the design team produced high fidelity screens on Figma covering all the key pages and components. Frontend development was tied directly to those designs, which meant every section had a reference to build from.
Spacing, typography, colour, and layout decisions were all specified in the Figma file and the design system. As a frontend contributor, my job was to match what was designed as closely as possible, not to make

visual decisions independently.

Sprint 1

Sprint 1 is the foundation sprint. The team was running two things in parallel: the infrastructure work that the entire product depends on, and shipping a responsive landing page as the visible deliverable for this sprint. So while the DB schema, Supabase setup, authentication, and sector taxonomy were being handled in the background, there was already something users could land on by the end of the sprint.

My frontend task was the Mission section of the landing page. The section required a centred layout with a small eyebrow label, decorative SVG petal icons positioned around the text, and a large headline, all matching a Figma design.

The technical challenge was the petal positioning. My first instinct was to put the SVG images inside a flex container alongside the text, but that made them sit too close to the text and resize awkwardly at different screen sizes. The fix was absolute positioning. By setting the eyebrow container to position: relative and positioning each petal with position: absolute, the petals float independently around the text without disrupting the layout flow. Each petal got its own class following BEM naming with top, bottom, left, and right values tuned to match the Figma design.

The project uses a utility class system similar to Tailwind for common styling, with component-specific CSS files handling anything the utilities do not cover. Styling the mission section meant using utility classes in the HTML for layout and typography, then writing targeted CSS using the project's design tokens for anything specific to the component. No hardcoded pixel values or colour codes, everything traces back to CSS custom properties defined in the design system.

Sprint 2

My task this sprint was building the filter section of the Opportunities page. This included the page header, a search bar, and five filter dropdowns which are Sector, Status, Business stage, Region, and Type, wired up so that every interaction logs the current filter state to the console. No API re-fetching yet as that is a separate issue. The goal was to establish the filter state object as a foundation for the upcoming API wiring.

The implementation used two shared components, SearchBar.create() and Dropdown.create(), that the team had already built. Each dropdown receives a label, an options array with exact API enum strings as values, and an onChange callback that updates a central filters object and logs it. The filters object lives at module scope so it will be accessible when the API wiring issue comes next.

The issue specified ES module imports rather than global script tags. This meant replacing multiple <script> tags in the HTML with a single <script type="module" src="opportunities.js"> and importing all dependencies at the top of the JS file. The shared components needed export default added to them before this worked, a small change with a meaningful impact on how the codebase scales.

Styling the filter section introduced another challenge. The Dropdown component renders its own HTML at runtime through JavaScript, which means you cannot add classes to its internal elements directly in your HTML. The fix was CSS scoping, targeting the component's internal class names through a parent BEM class I controlled:

.opportunities__dropdowns .dropdown-wrapper {
  flex: 1;
  display: flex;
}

.opportunities__dropdowns .dropdown__trigger {
  width: 100%;
  font-weight: var(--font-regular);
}

This overrides the component's default styles only within the filter section, leaving every other dropdown on the platform untouched.

My Role as People Manager

Outside of contributing code, I handled the coordination and tooling setup for the team.

I set up our ClickUp workspace. That meant building out the Ekehi Space, creating folders for each sprint, and configuring all the custom fields: priority levels, effort sizing, MoSCoW categories, status dropdowns, owner fields, due dates. I set up the views the team actually uses day to day. Board view for a quick status snapshot, Workload view to check capacity across the team, and filtered List view to pull up blocked items fast.

I sat in on meetings across the different tracks, frontend, backend, and
design, to stay across what each team was working on and where things stood. Beyond the meetings, I was also doing direct check-ins with individuals to follow up on assigned tasks.

Our ClickUp workspace is shared across multiple teams in the organisation so everything I configured had to be scoped specifically to our Space. That required ensuring I get it right without affecting anyone else's setup.

Beyond the initial setup, the day to day management of ClickUp was also on me. That means making sure tasks are actually being updated, statuses reflect what is really happening, and owners are assigned to everything that needs one. A ClickUp board that nobody updates is useless so part of my job was consistently following up with the team to keep it current.

I was also filtering by blocked tasks regularly. Anything sitting on blocked for too long gets a follow up from me. Either something needs to be escalated, a decision needs to be made, or someone needs help and has not said so yet. That filter became one of the most useful things in the whole setup because it tells you exactly where the friction is without having to go through every single task manually.

Working with my project lead throughout the sprint meant a lot of back and forth on task progress, making sure what was logged in ClickUp matched what was actually happening and flagging anything that looked like it was falling behind before it became a real problem.

Lessons Learnt

Merge conflicts are not a crisis. They are just two sets of changes that need a decision. Understanding what each side of the conflict contains makes resolving them straightforward. The harder lesson was learning to check in with the team lead before touching shared files because a one-line addition to a shared component has implications across the whole codebase.

CSS scoping matters more than it seems when working in a shared component system. Writing styles that are too broad breaks things in places you are not looking. Writing styles scoped to your own classes keeps your work contained and reviewable.

Working with a team of 15 people across different functions taught me fast that collaboration only works when everyone is actually showing up for their part. When people do not turn in their tasks as at when due, it does not just affect their own work, it affects whoever is waiting on them downstream.

Be specific when you need something from someone. A vague request sits in someone's inbox for days. A message that says exactly what to open, what to click, and that it will take two minutes gets done the same day.

And last one: the people manager role has real work in it even during a sprint where there is nothing to demo. Keeping the team unblocked, tracking what is at risk, making sure decisions happen when they need to. That is what makes the sprints after Sprint 1 possible.

Big respect to everyone on the Ekehi team, all 15 of us. Especially our Product Lead, Engineering Lead, Design Lead, Lead Maintainer, and Backend Lead for keeping things moving. It has been a solid sprint and we are just getting started.

TEE Foundation | Tabi Project | International Women's Day Initiative | March 2026

Building LovedIn: A Case Study

Oluchi Okwuosa — Sat, 21 Feb 2026 08:37:57 +0000

The Problem

Creating a platform for personalized proposals sounds straightforward until you realize what's actually at stake. It's not just a website. It's a moment. Someone's asking the most vulnerable question they can ask another person. They deserve more than a generic form. They deserve something that feels like it understands the weight of what they're doing.

The project needed multiple pieces working together seamlessly. A landing page that explains what LovedIn is and gets people excited about it. A stories page where people can share their proposals and celebrate with others. And then the proposal page itself, where the magic happens.

Who's going to use this? People aged 18 to 35 who want their proposals to be memorable. They're on their phones, they're probably nervous, and they want something that works smoothly without any hiccups.

The goal was simple but ambitious: create a complete platform that feels personal, that celebrates what's actually happening. Not generic or boring. Something that makes you feel the weight of the moment while also making it feel safe enough to be playful about it. A platform where someone could create a customized proposal experience and then share it with the person they love.

How I Approached It

I worked on three main parts of this project: the proposal page, the login page, and the signup page. Each one had its own challenge, but they all had to feel like they came from the same place, the same design language.

For the proposal page, I designed it to have two distinct states visually. First, there's the question state where you see the personalized proposal. Then there's the success state that celebrates the "yes" moment. Both are built with HTML and CSS, structured so they can be toggled with a class when JavaScript gets added later. The structure made sense because it keeps everything on one page. The visual hierarchy and layout shift from one state to another through CSS class management. It's designed to be clean and cohesive.

I added animated GIFs to break up the formality and set the emotional tone. The proposal state shows a cute animated character peeking out nervously, like someone getting ready to ask the big question. It's the feeling before you ask. The success state shows a baby cheering, celebrating the "yes". These aren't just random images thrown in. They set the tone. They make it feel like the page understands that this is emotional, vulnerable, and deserves celebration.

The GIFs are styled to be prominent but not overwhelming. They're centered, have a border in the accent color, and cast a subtle shadow. They draw your eye but they don't scream for attention.

I also designed the "No" button to do something playful. When you hover over it, it moves away. This is intentional. It's playful. It acknowledges the nervousness of the moment but keeps things light. The button doesn't disappear completely, it just shifts position. On desktop, it moves more dramatically, 80 pixels to the right and 30 pixels up. On mobile, it moves less because the screen is smaller and you don't want the button flying off screen entirely. It's 40 pixels right and 15 pixels up on smaller devices.

This movement is pure CSS using transform and transition. No JavaScript needed. The transform property moves the button without affecting the layout, which keeps everything smooth and performant. The transition makes it feel responsive and snappy.

For the login and signup pages, the approach was different but connected. I structured them with proper semantic HTML so they were accessible, then styled them to feel warm and inviting using the same design system. The forms had to be straightforward but not sterile. A person coming to log in or sign up is already taking a step toward something, so the interface should meet them with ease, not friction.

Both the proposal page and the auth pages had to work together in the same design language. That's where the design system became crucial.

The Design System

Colors matter more than people think, especially when you're trying to create an emotional experience. I worked with five specific colors from our design system, and each one has a purpose and a name.

Scarlet Blush is #E22B3B, the primary color. It's bold, it's romantic, and it demands attention. You see it in headings and main buttons. It's confident without being aggressive. Wild Strawberry is #ED4779, the secondary color. It's softer than Scarlet Blush, more playful. It shows up in gradients and accents. It's romantic without being too serious. Petal Frost is #FA88BB, the accent color. It's tender and warm. It shows up in borders and highlights, adding softness to hard edges. Pink Carnation is #F0D1D7, the background color. It's this soft pink that makes every page feel intimate and calm. And Blush Rose is #D86A77, the support color. It grounds everything. It works for secondary text and borders, keeping things from floating away.

For fonts, I used Playfair Display for headlines. It's elegant, it's got personality, and when you see your partner's name in this font, it feels formal and important. That's intentional. Inter is what everything else uses because it's clean and readable everywhere, on every device.

The whole design system exists in base.css as CSS variables. This means we're not hardcoding colors. If we ever need to change Scarlet Blush, we change it once and it updates everywhere. That's the power of a good system. My partner built this foundation, and it made everything else possible.

The HTML Structure

I made sure the HTML was semantic and accessible because honestly, if people can't access your page or search engines can't understand it, none of the styling matters.

For the proposal page, the structure is straightforward. There's a main section that holds two states: the proposal state and the success state. Both are built in HTML, ready for JavaScript to toggle between them. The proposal state has the question, the GIFs, and the buttons. The success state has the celebration message.

For the auth pages, the structure had to be clean but also make sense. Each form is wrapped in a fieldset with a legend. The legend tells you what section you're in. The form groups are organized vertically, each with a label and input. It's simple, but it's built correctly.

Each heading gets its proper semantic tag. The main question on the proposal page is an h1, the success message is an h2. This creates a proper document outline so screen readers understand what's happening. The buttons have proper IDs so they can be targeted later with JavaScript.

Here's what the proposal page structure looks like:

<body>
  <main>
    <section class="proposal-page active">
      <button class="back-btn">← Back</button>

      <section class="proposal-container">
        <div class="proposal-state" id="proposalState">
          <img src="..." alt="Cute animated character peeking out nervously" class="proposal-gif" />
          <h1 class="proposal-container__title">Will you be my girlfriend?</h1>
          <p class="proposal-container__text">This is the moment that changes everything...</p>

          <div class="proposal-buttons">
            <button class="proposal-buttons__yes" id="yesBtn">Yes! 💕</button>
            <button class="proposal-buttons__no" id="noBtn">No!</button>
          </div>
        </div>

        <div class="success-state" id="successState">
          <img src="..." alt="Animated baby raising their arms and cheering" class="success-gif" />
          <h2 class="proposal-container__heading">You've Made Me The Happiest</h2>
          <p class="proposal-container__text">Welcome to the next chapter of our story together</p>
          <p class="success-message">This moment, this "yes" - I'll treasure it forever...</p>
          <button class="btn btn-primary">Back Home</button>
        </div>
      </section>
    </section>
  </main>
</body>

And here's what the auth page structure looks like:

<main class="auth-page">
  <section class="auth-page-text">
    <h1 class="auth-text-heading">Welcome Back</h1>
    <p class="auth-text-para">Log in to your LovedIn account</p>
  </section>

  <form class="auth-form">
    <fieldset class="auth-field">
      <legend class="auth-form-heading">Login Details</legend>

      <div class="form-group">
        <label for="email">Email:</label>
        <input type="email" id="email" name="email" required placeholder="you@example.com" />
      </div>

      <div class="form-group">
        <label for="password">Password:</label>
        <input type="password" id="password" name="password" required placeholder="Enter your password" />
      </div>

      <button type="submit" class="submit-btn">Login</button>
    </fieldset>
  </form>

  <div class="auth-footer">
    <p class="auth-footer-text">Don't have an account? <a href="signup.html" class="redirect-link">Sign up</a></p>
  </div>
</main>

I added Open Graph meta tags so when someone shares this on Twitter or Facebook, it shows a nice preview with the right image and description. Meta tags matter for shareability, and proposals are definitely going to be shared.

The alt text on the GIFs is descriptive, not just "gif". That's for accessibility and for anyone who can't load the images for whatever reason.

SEO Optimization

Each page has a unique, descriptive title tag. The proposal page's title is "LovedIn - Your Proposal". That tells search engines exactly what this page is about. The meta description explains the page in 160 characters, which is what shows up in search results.

Open Graph tags are crucial for this project because proposals are shareable moments. When someone posts the proposal link on Facebook or Twitter, the preview shows the right image, title, and description. That's Open Graph doing its job. Without it, you'd just see a generic URL.

The heading hierarchy matters too. I didn't just throw h1, h2, h3 at things randomly. There's one h1 per page, which tells search engines what the main topic is. The h2 is for secondary content. This structure helps Google understand the page better.

The alt text on images does double duty. It helps people using screen readers understand what the images are, and it also helps search engines understand the images. Good alt text is descriptive and relevant. "Celebration GIF" is better than "image123". "Animated baby raising their arms and cheering excitedly to celebrate the positive response" is even better because it describes exactly what's happening.

Here's what the meta tags and Open Graph setup looks like in the HTML head:

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />

  <title>LovedIn - Your Proposal</title>

  <meta name="description" content="A personalized proposal experience created with LovedIn." />

  <!-- Open Graph Tags for Social Sharing -->
  <meta property="og:type" content="website" />
  <meta property="og:title" content="LovedIn - Your Proposal" />
  <meta property="og:description" content="A personalized proposal experience created with LovedIn." />
  <meta property="og:image" content="https://lovedin.vercel.app/assets/images/meta-proposal.png" />
  <meta property="og:url" content="https://lovedin.vercel.app/proposal.html" />

  <!-- Twitter Card Tags for Twitter Sharing -->
  <meta name="twitter:card" content="summary_large_image" />
  <meta name="twitter:title" content="LovedIn - Your Proposal" />
  <meta name="twitter:description" content="A personalized proposal experience created with LovedIn." />
  <meta name="twitter:image" content="https://lovedin.vercel.app/assets/images/meta-proposal.png" />

  <!-- Additional SEO -->
  <meta name="theme-color" content="#ED4779" />
  <link rel="icon" href="assets/images/favicon.ico" />
</head>

Here's what each tag does:

Basic Meta Tags:

<title> - Shows up in browser tab and search results. Keep it under 60 characters
<meta name="description"> - Shows under the title in search results. Around 160 characters
<meta name="viewport"> - Makes the site responsive on mobile devices

Open Graph Tags (for Facebook, LinkedIn, etc.):

og:title - The title shown when someone shares the link
og:description - The description shown when someone shares the link
og:image - The image shown when someone shares the link (this is crucial for proposals because the preview is visual)
og:url - The URL of the page
og:type - What type of content this is (website, article, etc.)

Twitter Card Tags (specifically for Twitter/X):

twitter:card - Type of card. "summary_large_image" shows a big preview with image
twitter:title - Title for Twitter
twitter:description - Description for Twitter
twitter:image - Image for Twitter

The overall structure and content on the page tell a story that search engines can understand. When someone searches for "personalized proposal experience" or "romantic proposal idea", we want these pages to show up. The semantic HTML and clear content structure makes that possible.

When someone shares the proposal link on Facebook, they see the Scarlet Blush color, the proposal image, and a clear description. That's Open Graph working. It makes sharing the proposal feel special, not like a generic link.

The CSS Architecture

My partner built a comprehensive design system in base.css that defines everything we need: colors, spacing, typography scales, border radius values, shadows, and transition durations. Everything is a variable. I had to learn to use that system properly and extend it where the proposal and auth pages needed something different.

Here's why this matters. When I was styling the proposal page or the auth pages, I didn't write pixel values or hex codes. I wrote var(--spacing-lg) or var(--color-primary). This sounds like extra work, but it's actually the opposite. It's faster because you're following an established pattern. And if we need to change something across the entire site, we change it once.

Here's what the design system looks like:

:root {
  /* Colors */
  --color-primary: #e22b3b;        /* Scarlet Blush */
  --color-primary-bg: #f0d1d7;     /* Pink Carnation */
  --color-secondary: #ed4779;      /* Wild Strawberry */
  --color-secondary-bg: #fff6f8;
  --color-accent: #fa88bb;         /* Petal Frost */
  --color-support: #d86a77;        /* Blush Rose */

  /* Typography */
  --font-display: "Playfair Display", serif;
  --font-body: "Inter", sans-serif;
  --heading-h2: 2.25rem;
  --heading-h3: 1.875rem;

  /* Spacing */
  --spacing-lg: 1.5rem;
  --spacing-md: 1rem;
  --spacing-sm: 0.5rem;

  /* Shapes */
  --radius-lg: 12px;
  --radius-2xl: 20px;

  /* Shadows */
  --shadow-xl: 0 20px 25px -5px rgba(0, 0, 0, 0.1);

  /* Transitions */
  --transition-base: 250ms ease-in-out;
}

For the proposal page, the buttons are arranged with flexbox, which is the right choice for this layout. I set display to flex, gap handles the spacing between buttons, justify-content centers them horizontally, and flex-wrap makes sure they stack on smaller screens. This is responsive by default without needing a ton of media queries.

Here's the button styling for the proposal page:

.proposal-buttons {
  display: flex;
  gap: var(--spacing-lg);
  justify-content: center;
  flex-wrap: wrap;
  margin-top: var(--spacing-2xl);
}

.proposal-buttons__yes {
  background: linear-gradient(
    135deg,
    var(--color-primary),
    var(--color-secondary)
  );
  color: var(--color-white);
  padding: var(--spacing-md) var(--spacing-2xl);
  border: none;
  border-radius: var(--radius-md);
  font-weight: var(--font-weight-bold);
  cursor: pointer;
  transition: var(--transition-base);
  box-shadow: 0 4px 12px rgba(226, 43, 59, 0.15);
}

.proposal-buttons__no {
  background: rgba(226, 43, 59, 0.08);
  color: var(--color-primary);
  padding: var(--spacing-md) var(--spacing-2xl);
  border: var(--border-width-medium) solid var(--color-primary);
  border-radius: var(--radius-md);
  cursor: pointer;
}

For the auth pages, the form styling had to feel welcoming while still being functional. Here's the form structure:

.auth-form {
  background: var(--color-white);
  border-radius: var(--radius-lg);
  padding: var(--spacing-4xl) var(--spacing-2xl);
  max-width: 400px;
  width: 100%;
  box-shadow: var(--shadow-lg);
  border: var(--border-width-thin) solid var(--color-primary-bg);
}

.auth-field {
  border: none;
  padding: 0;
  margin: 0;
  display: flex;
  flex-direction: column;
  gap: var(--spacing-lg);
}

.form-group input {
  padding: var(--spacing-md) var(--spacing-md);
  border: var(--border-width-medium) solid var(--color-primary-bg);
  border-radius: var(--radius-md);
  font-family: var(--font-body);
  font-size: var(--font-size-sm);
  transition: var(--transition-base);
  background-color: var(--color-white);
  color: var(--color-gray-900);
}

.form-group input:focus {
  outline: none;
  border-color: var(--color-primary);
  box-shadow: 0 0 0 3px rgba(226, 43, 59, 0.1);
}

I used BEM naming for all the CSS classes. Block, Element, Modifier. This means class names tell you exactly what they're for. .proposal-container is the block. .proposal-container__title is an element inside it. It's clear, it's scalable, and it prevents naming conflicts.

Here's an example of BEM structure in the proposal container:

.proposal-container {
  background: var(--color-white);
  border-radius: var(--radius-2xl);
  padding: var(--spacing-4xl) var(--spacing-2xl);
  max-width: 600px;
  width: 100%;
  box-shadow: var(--shadow-xl);
  text-align: center;
  position: relative;
}

.proposal-container__title {
  font-family: var(--font-display);
  font-size: var(--heading-h2);
  font-weight: var(--font-weight-extrabold);
  color: var(--color-gray-900);
  margin-bottom: var(--spacing-sm);
}

.proposal-container__text {
  font-size: var(--font-size-md);
  color: var(--color-gray-500);
  margin-bottom: var(--spacing-lg);
  font-weight: var(--font-weight-medium);
}

I didn't use element selectors like "h1" or "button" for styling. Everything is class-based. This sounds strict, but it's actually really good practice because it decouples your CSS from your HTML. If the HTML structure changes, your CSS doesn't break. And when you're working on a team, this prevents one person's styling decisions from affecting another person's work.

The DRY Principle and Button Styles

At first, I had button styles in auth.css. Then I had them again in proposal.css. That's duplication, and it's a problem. If we need to update how buttons look, we'd have to change multiple files. That's asking for bugs.

So I centralized all button styles in base.css. Now auth pages use them, proposal pages use them, and any other page that comes along uses them. One source of truth. When we update buttons, it happens everywhere automatically.

This is called the DRY principle: Don't Repeat Yourself. It's one of those fundamentals that sounds obvious until you see how much time it saves you in the long run.

Responsive Design

The proposal page, the login page, and the signup page all need to work on phones, tablets, and desktops. The way I handled this was with media queries that adjust sizes and spacing for smaller screens.

On mobile, the container gets less padding so it fits better. The headings get smaller. Everything is appropriately sized for the device. All of this happens at a breakpoint around 640 pixels wide for the auth pages and 768 pixels for the proposal page, which is where most tablets switch to portrait orientation.

What Was Actually Hard

The biggest challenge wasn't the code. It was maintaining consistency while working with someone else on the same project. My partner was building out base.css, the homepage, and stories page while I was working on the proposal page and auth pages. We both needed to use the same button styles, the same colors, the same spacing scale.

At the beginning, I was using element selectors like "h1" or direct targeting. That works fine until your partner structures their HTML differently, and then suddenly the styling breaks or looks inconsistent. Or you both style buttons and they look slightly different because you made slightly different choices.

The Git workflow was challenging too. I had to learn how to create proper feature branches, write good commit messages, and handle merge conflicts when they happened.

Learning to use Git branches properly was key. We established a pattern where each feature got its own branch. I'd create a branch like "feature/proposal-page-styling", do my work, commit with clear messages like "refactor(css): Remove button styling duplication", push that branch, and then create a pull request for my partner to review. Only after they approved would it get merged to the main branch.

This workflow felt like extra steps at first, but it actually saved us from so many problems. And having code review from my partner meant I caught issues I might have missed.

Another challenge was getting the responsive design right. The proposal page and auth pages need to look good on phones, tablets, and desktops. Getting padding, font sizes, and button spacing to scale properly across all those sizes took careful testing and tweaking. Mobile design is harder than it looks.

The solution was establishing a clear system and sticking to it. We documented how classes should be named. We centralized shared styles in base.css. We used variables for everything. Did this take time upfront? Yeah. Was it worth it? Absolutely. Because after that, we could work independently without worrying about breaking each other's work.

What I'd Do Differently in Version 2.0

First, I'd add animations to the page transitions. Right now the states are designed to swap with classes, but in version 2 I'd add CSS animations so they fade or slide in smoothly when the state changes.

Second, I'd improve the back button styling. Currently it's functional, but I'd make it more integrated into the overall design. Maybe animate it on hover or give it more visual feedback.

Third, more focus on micro-interactions. Things like button hover effects, focus states for keyboard navigation, and smooth transitions everywhere. These small details make a huge difference in how polished something feels.

Fourth, I'd optimize the layout further for tablets. Right now I have desktop and mobile, but tablets are their own thing. Spending more time on that middle breakpoint would help.

Fifth, I'd add more sophisticated typography handling. Maybe different heading sizes for different sections, better line heights, better letter spacing. Typography is understated but incredibly important.

Sixth, I'd consider adding CSS custom properties for even more granular control over things like opacity, blur effects, and other visual effects that might make the page feel more alive.

What I Learned

Building this taught me that design systems aren't just about making things look consistent. They're about enabling teams to work together without friction. When everyone follows the same patterns and uses the same variables, the code becomes easier to understand and easier to maintain. My partner laid that foundation with base.css, and I learned to trust it and build on top of it.

I also learned that constraints are actually helpful. When my partner constantly reinforced that "no element selectors, everything has to be a class", that forced me to think more carefully about naming and structure.

I learned that CSS can do way more than people think. You don't need JavaScript for a lot of things. Flexbox, media queries, CSS variables, hover states, they're all super powerful. Learning to work within CSS constraints made me a better developer.

Finally, I learned that responsive design is an art. Getting something to look good on a 5-inch phone and a 27-inch monitor takes real thought. It's not just about making things smaller or bigger. It's about understanding how people interact with different screen sizes and designing for that.

I also learned something about working with another person on code. It requires vulnerability. You have to be willing to have your code reviewed, to hear that something doesn't work, to try a different approach. It requires patience. Sometimes the person working on the foundations (like base.css) is the unsung hero because their work enables everything else. And it requires trust. Trust that your partner is doing their part, trust that their approach is intentional, trust that they care about the outcome as much as you do.

The Live Experience

You can check out the proposal page here: https://lovedin.vercel.app/

The code is all on GitHub: https://github.com/Yourgotopyromaniac/lovedin

The design system documentation that guided all of this: https://tidy-nape-704.notion.site/LovedIn-Design-Documentation-2fcff83f0c4c80cea70bfefc37e883e0

The broader case study for the whole project: https://docs.google.com/document/d/1BwLFD08gpjclHfZflFJPF8wNfVAWR2nbD_FLrHhudEE/edit

Acknowledgment

This happened because of collaboration. My partner Awoyemi Abiola did the heavy lifting on this project. They built the base.css design system that everything else is built on top of, styled the index.html landing page, and created the stories.html page and its styling. Without that foundation, my work on the proposal page and the auth pages would have been way harder.

We had to sync up, make decisions together, and trust each other's work. That's how you build something actually good. When I was building the proposal page and auth pages, I could rely on the design system Awoyemi created. When they were styling the homepage, they could count on the system being consistent.

Check out Awoyemi's GitHub: https://github.com/Yourgotopyromaniac

And their version of this case study: