Forem: Grace Olabode

Wrapping Up Bloom After: Week 4 Polish & Full Sprint Retro

Grace Olabode — Fri, 27 Mar 2026 20:53:55 +0000

We finally made it to Week 4! This last week of the sprint was all about crossing the t's, dotting the i's and making sure the app actually feels good to use.

Before I get into the bugs I squashed this week, let's zoom out and talk about what my team and I spent the last month building.

What is Bloom After?

Dealing with postpartum depression (PPD) can feel incredibly lonely. While there is plenty of medical advice online, finding a single and calming place with helpful resources, verified specialists and a community of moms who actually get it is really hard. That’s why we built Bloom After. It’s a safe digital space for mothers facing maternal mental health challenges, featuring an educational hub, a clinic finder, and a story library where moms can read and share their journeys. We designed the entire platform to be calming, supportive and super easy to use for someone who might already be feeling overwhelmed.

What I Shipped This Week

The heavy lifting for the Stories feature and the Admin dashboard was finished last week by my team. So, my main goal for Week 4 was to polish the app, test it, and make sure everything flowed perfectly. Here is what I did:

Revamped the Lifestyle & Crisis Pages: I completely refined the UI and functionality for the Lifestyle and Crisis landing pages. For the Crisis page, I made sure the 24/7 helplines were pinned to the very top and swapped out a clunky separate page for a fast and instant-loading modal so moms can get help immediately.
End-to-End Testing: I put on my QA hat (which almost didn't fit) and clicked through the entire app from start to finish, acting like a real user to see what would break.
Bug Squashing & UI Polish: I spent hours fixing alignment issues, spacing and mobile glitches (like a stubborn bug on 360px mobile screens!). I went through several pages, including the Admin dashboard, to fix bugs and make sure the design looked premium and consistent everywhere.

Key Technical Lessons from the Sprint

CSS Mobile Quirks are Real: I learned that mobile browsers handle screen heights weirdly. Using dvh (dynamic viewport height) instead of standard vh is a lifesaver so your modals don't get hidden behind the mobile address bar.
The Devil is in the Details: Polishing UI takes just as much time as building the feature in the first place. A tiny 1px gap or a misaligned button can ruin the whole vibe of a page.
E2E Testing is Eye-Opening: You think your code works perfectly until you actually try to use it. Testing the full flow caught so many tiny bugs and bad user experiences that I would have completely missed if I only looked at the code.

Full-Sprint Retrospective

Looking back at the whole month of building Bloom After:

What went well: We stuck to our vision. We wanted to build a platform that felt deeply empathetic and safe, and we never compromised on that UX, even when it meant doing tedious CSS work.
What I would do differently: I’d set up a better modular folder structure from Day 1. Moving from a messy flat folder system to a clean and organized one late in the project meant rewriting a ton of file paths.
What surprised me: How much complex code goes into making things look "simple." Creating a clean and calming interface actually requires a lot of behind-the-scenes work.

What’s Next for Me?

Now that this sprint is over, I’m shifting my focus to leveling up my core engineering skills. I really want to master the fundamentals, so I'm going to dive deep into advanced JavaScript and TypeScript. I also plan to tackle Data Structures and Algorithms (DSA) to sharpen my problem-solving abilities. Instead of just getting stuck in "tutorial hell," my main goal is to build out a few solid projects from scratch using JS and TS to put all of these concepts into actual practice.

Team Shoutouts

Building this isn't a one-person job. A massive thank you to the amazing people building this with me:

Chijioke Uzodinma (Backend Lead):Read his Week 4 article here.
Nanji Lakan (Product Lead): Read her Week 4 article here.
Agugua Genevieve (Design Lead): Read her Week 4 article here.
Prisca Onyemaechi (Lead Maintainer): Read her Week 4 article here.
Adejola Esther (Frontend Engineer): Read her Week 4 article here.

Visit our live site.
Check out our Github Repo.

Building with Care (Week 3): Hardware Hiccups, The NGO Directory, and Keeping Code DRY

Grace Olabode — Fri, 20 Mar 2026 20:50:29 +0000

By Grace Olabode | Engineering Lead, Bloom After

It is hard to believe we are already in Week 3 of our sprint with the Tabi Project and TEE Foundation. We are building Bloom After to make sure Nigerian mothers have a safe and supportive app to face postpartum depression.

Last week, I focused heavily on maps, math, and building the foundation of the Resource Hub. This week, the goal was to build the NGO Directory, refactor our code so it is clean and reusable, and handle some content updates. It was also a week of unexpected hardware issues and learning how to navigate team dynamics.

What I Built This Week

I spent most of my time making the layouts actually work with real data and cleaning up the code so it runs smoothly.

1. The NGO Directory: I built the main page where users can scroll through a list of vetted non-profit organizations and support groups.

2. Resource Hub Updates: Since the heavy lifting for the hub was done last week, my task this week was just updating the categories. I replaced the "audio summary" and "podcast" tags with a single, unified "media" tag to make sorting easier for the users.

3. Minor UI Fixes and DRY Code: I spent a lot of time cleaning up the app. I focused heavily on implementing DRY (Don't Repeat Yourself) principles so we are reusing code instead of writing the same things twice. I also fixed small spacing issues, corrected text sizes, and made sure the mobile menus stacked perfectly on smaller screens.

Why I Did What I Did

Splitting Up the JavaScript: Instead of writing one giant wall of code, I broke our JavaScript into smaller and separate files. This makes the code much easier to read and fix.
Faking the Backend: I worked closely with our Backend Lead, Chijioke Uzodinma, to agree on how our data should be structured. Because we were still finalizing things, I built a fake API using JavaScript Promises to keep the frontend moving. Switching to the live backend later will just take changing one line of code.
CSS Grid over Media Queries: To make the NGO cards adjust to any screen size automatically, I used CSS Grid. This saved me from writing dozens of extra lines of code just for mobile screens.

Bugs, Fixes and Fan Failures

The Silent Crash
While splitting up our JavaScript files, I ran into an annoying bug where the Resource Detail page would only show the "Back" button. The rest of the page was completely blank. After opening the console, I saw a null error. The JavaScript was looking for specific HTML tags that did not exist in the new layout. I quickly updated the HTML to match and the content instantly popped back onto the screen.

The Messy Grid
When I first loaded the NGO data into the grid layout, the different text lengths caused the cards to stretch to completely different heights. I fixed this by using Flexbox to force the cards to match heights. I also added a CSS trick called line-clamp to automatically hide extra text and add three dots at the end.

The Hardware Hurdle
My biggest challenge this week was not actually code. My laptop fan completely died. To make things worse, the Eid ul Fitr holiday meant all the repair shops were closed. It took days to get it fixed. Because of this, we are currently way behind our schedule, but we are absolutely determined to make things work and catch up.

Sprint Reflections

Working in a team is incredibly fun but it can also be frustrating when schedules misalign or things break. Communication is everything. Working so closely with the backend lead this week really highlighted how much faster you can solve problems when you share the load.

If I could do this sprint differently, I would try to tackle minor visual fixes as I build the features, rather than saving them all for a clean up phase.

What I Am Most Proud Of

I am super proud of how cohesive the whole app looks right now. Seeing the Resource Hub and the new NGO Directory sitting side by side looking like a real and professional product is an amazing feeling. I am proud that despite laptop failures and being behind schedule, we are still building something that will genuinely help people.

Team Shoutouts

Building this isn't a one-person job. A huge thank you to the amazing people building this with me:

Chijioke Uzodinma (Backend Lead):Read his Week 2 article here.
Nanji Lakan (Product Lead): Read her Week 3 article here.
Agugua Genevieve (Design Lead): Read her Week 3 article here.
Prisca Onyemaechi (Lead Maintainer): Read her Week 3 article here.
Adejola Esther (Frontend Engineer): Read her Week 3 article here.
Christine Myangi (People Manager): Read her Week 3 article here.

Visit our live site.
Check out our Github Repo.

Building the Search: My Week 2 Progress on Bloom After

Grace Olabode — Fri, 13 Mar 2026 19:07:24 +0000

By Grace Olabode | Engineering Lead, Bloom After

In my first article, I talked about setting the foundation for our project. This week, we actually started building the tools for mothers to find support. It was a busy week of maps and filters and making the Resource Hub look exactly like the safe space the designers planned.

What I Built This Week

1. The Clinic & Hospital Finder
This was the most technical part of my week. I built the search directory so mothers can find a clinic easily without scrolling forever while strictly following our MVP requirements.

The Interactive Map & Directions I used Leaflet.js to make a map with clinic pins. I also added a "Use My Location" button that uses browser geolocation and the Haversine formula to calculate exactly how many kilometers away each clinic is, automatically sorting the closest ones to the top. I also wired up a "Directions" button that routes users directly via Google Maps.
Advanced Filters: I made a filtering system so users can sort by cost like Free/Subsidised vs Private. They can also filter by the type of provider (clinic, therapist, psychiatrist) or if they want to see someone online or in person.
Dynamic Slide-out Details: When you click a provider, a panel slides out. I programmed the logic to dynamically render different information depending on the provider type which includes displaying specialist credentials, languages spoken, areas of expertise, opening hours, fee ranges, and an "Accepting New Patients" status pill.
Private Feedback System: To keep the directory a safe space, our MVP doesn't include public reviews. Instead, I built a secure "Private Feedback" form inside the details panel so mothers can confidentially share their experiences directly with our team for quality control.

2. Building the Resource Hub
A huge part of my week was spent getting the content library ready. I didn't just style things but I actually built the main pages from scratch.

The Main Library: I built the Articles and Resources pages from the ground up. I had to make sure the logic was set up so that we can easily add more content later without the code breaking.
Technical Layouts: I updated the code in renderers.js to handle the specific data structures for our resources. This included building the logic to display infographics properly and setting up the side-by-side comparison view for the "Myth vs. Fact" section.

Technical Tools & Setup

We needed a way to host images and keep the site live without managing our own servers.

Cloudinary, MongoDB, and Render:
I worked with our Backend Lead, Chijioke Uzodinma, to set up Cloudinary for our images. This keeps the site fast because heavy images won't slow us down. We also integrated MongoDB to store the clinic and resources data and moved everything over to Render so our backend logic stays stable.

Challenges I Faced

The biggest headache was a map bug where it would just show a blank grey box. I figured out it was trying to load before the page was fully ready so I added a fix in the JS to force the map to check its size again right after the page loads.

Another hurdle was getting the "Directions" button to actually route users properly. I initially thought I could just pass the raw latitude and longitude into a basic link, but it wasn't working. I had to dig in and figure out the exact URL format Google Maps requires so that when a mother clicks the button, it seamlessly opens up accurate driving or walking directions on her device.

I also had a problem with the "Load More" button not hiding when the list was finished. I fixed this by adding a global rule in our CSS to make sure the "hidden" command always wins over other styles.

Finally, we had a weird issue with Render. For some reason I don't really understand yet, it isn't deploying automatically when we push our code. Because of this, we have to go in and manually trigger the deployments every single time we make a change. It's a bit annoying, but we are working around it for now!

What I Learned

Maps and Math: I learned how to use the Haversine formula to calculate the distance between two points on a map.
Cleaner Code: I reminded myself to keep styling out of the JavaScript. Moving those styles into a CSS file made everything way easier to read and fix.
Working Together: Setting up the cloud tools and MongoDB with the backend lead showed me how much faster we move when the frontend and backend are in sync.

Team Shoutouts

Building this isn't a one-person job. A massive thank you to the amazing people building this with me:

Chijioke Uzodinma (Backend Lead):Read his Week 2 article here.
Nanji Lakan (Product Lead): Read her Week 2 article here.
Agugua Genevieve (Design Lead): Read her Week 2 article here.
Prisca Onyemaechi (Lead Maintainer): Read her Week 2 article here.
Adejola Esther (Frontend Engineer): Read her Week 2 article here.
Christine Myangi (People Manager): Read her Week 2 article here.

Week 2 is done! The map is working and the resources look good. We’re getting closer to helping moms bloom.

Visit our live site.
Check out our Github Repo.

Building with Care: My Week 1 Setup for Bloom After

Grace Olabode — Fri, 06 Mar 2026 14:43:18 +0000

By Grace Olabode | Engineering Lead, Bloom After

Writing code is usually about solving business problems. But sometimes, you get to build something that feels like a warm hug for someone going through a tough time.

For the International Women’s Day (IWD) Sprint with the Tabi Project and TEE Foundation, our team is building Bloom After. It’s a website designed to safely support Nigerian mothers dealing with Postpartum Depression (PPD).

As the Engineering Lead for this project, my job for Week 1 (our setup week) was to build a strong foundation. I needed to make sure our coding workspace was set up so that the final website would be fast, safe, and incredibly easy to use. Here is a look at how we started.

Keeping it Fast and Simple

When a mother is tired, stressed, or overwhelmed, the last thing she needs is a slow, frustrating website. We had a strict rule from the start: the site must load in under 3 seconds on a mobile phone.

To make this happen, we kept our tools very simple. Instead of using heavy, complicated coding frameworks, we went back to the basics and built the site using plain HTML, CSS, and JavaScript.

We also made strict rules for how our team writes and shares code on GitHub. We set up a system where nobody is allowed to push code directly to the live website. Everything must be checked and approved first, which stops the site from accidentally breaking.

My Work This Week

As the Engineering Lead, I had to make sure my team could code smoothly without stepping on each other's toes. Here is what I focused on:

I wrote the Technical Requirements Document (TRD). This is basically our rulebook. It tells the team exactly how to organize our files and how to set up our database to safely hold things like clinic locations and community stories.
I set up our JavaScript so we could build things like the top navigation bar just once, and reuse it on every page. This saves the team a massive amount of time.
I carefully checked the code my teammates wrote for our Landing Page to make sure it looked great and worked perfectly on mobile phones.

What I Learned This Week

Having a great plan doesn't matter if the team isn't talking. Constantly chatting and answering questions in Slack saved us from a lot of mistakes.
Building the website with plain HTML, CSS, and JavaScript reminded me that you don't always need the newest and fanciest tools to make something beautiful and functional.
Sprints move very fast. Knowing when to step back, take a breath, and just be a "cute potato" for a little while is super important so the team doesn't burn out!

Team Shoutouts

A strong foundation is only as good as the team building on top of it. A massive thank you to the amazing people building this with me:

Chijioke Uzodinma (Backend Lead): For helping me plan the database perfectly. Read his Week 1 article here.
Nanji Lakan (Product Lead): For making sure we are building exactly what these mothers need. Read her Week 1 article here.
Agugua Genevieve (Design Lead): For designing a website that feels safe, warm, and welcoming. Read her Week 1 article here.
Prisca Onyemaechi (Lead Maintainer): For keeping our GitHub files perfectly organized. Read her Week 1 article here.
Christine Mwangi (People Manager): For keeping everyone happy, focused, and moving forward. Read her Week 1 article here.
Adejola Esther: For working on the landing page (contributions and partners section). Read her Week 1 article here.

Week 1 is officially done and our first pages are live! Next week, we dive into building the actual resource library and the clinic finder map. Let’s build something that matters.

Visit our live site.
Check out our Github Repo..

Building DateSpark: A Date Planning App for Couples

Grace Olabode — Fri, 20 Feb 2026 19:35:49 +0000

Live Demo: DateSpark
GitHub Repository: DateSpark Repo

The Problem Statement

We’ve all experienced that moment: staring blankly at each other at 7 PM, trapped in the cycle of "I don't know, what do you want to do?" By the time you come up with something, everything is closed.

This is the problem DateSpark addresses. DateSpark is a date planning web app designed to reduce the stress of decision-making. You answer three simple questions: your budget, your vibe (activity preference), and how much time you have. The app then gives you a curated date idea. No more endless scrolling.

DateSpark targets couples looking for meaningful experiences without the hassle. It’s essentially a relationship saver in a simple interface.

The Architecture: Keeping It Vanilla

While it might be tempting to use a large framework for every project, we built DateSpark with vanilla JavaScript, semantic HTML, and a highly customized CSS setup.

For our data, we avoided a heavy backend and used a local JSON file (dateIdeas.json) as a read-only database. We relied on the browser's localStorage to save user-specific data. Here’s how it works behind the scenes.

1. The Generate Flow: The "No Dead Ends" Algorithm
The Generate page is the core of the app. When a user submits their three preferences, our JavaScript gets to work.

Data Mapping: It takes the form inputs and maps them to our JSON data aliases (for example, it maps a "low" budget to "Free" and "₦").
The Fallback Protocol: What happens if someone requests a 5 hour, free, luxury spa experience? Instead of showing an annoying "No results found" message, we created a "relaxation" fallback. The logic ignores filters one by one (first duration, then activity, then budget) until it finds suitable ideas. You always receive a date suggestion.
Saving State: See an idea you like? Clicking "Save to My Plans" packages the current idea with a timestamp and sends it right to localStorage.

2. My Plans: A LocalStorage Dashboard
This page serves as the user’s personal dashboard for saved dates.

State Management: On loading, the JavaScript reads from the datespark.savedPlans.v1 array in local storage and separates the UI into "Upcoming" and "Completed" views based on a simple true/false condition.
Instant UI Updates: We added a dynamic search bar that filters the grid in real-time by checking the input against titles, tags, and descriptions. Clicking "Mark Completed" updates the object, overwrites local storage, and refreshes the display instantly. It’s quick and has no network delays.

3. Browse Flow: Deep Linking for Sharing
Sometimes you just want to casually look for date ideas. The Browse page displays our entire JSON library in a clean grid.

Smart Filtering: Category buttons filter the array immediately without needing to reload the page.
Deep Linking: We didn’t just create modals; we made shareable ones. When you click on an idea, the JavaScript updates the URL parameter (?idea=ID). This means if you discover the perfect "Starlit Rooftop Picnic," you can copy the link and text it to your partner, and it will open directly to that specific modal.

4. Home Page: Drag-to-Scroll and Simulated Delays
First impressions count, so the Home page needed to feel engaging.

The Carousel: Instead of a basic CSS slider, we built a custom JavaScript carousel for the "Curated Experiences" section that supports drag-to-scroll, button clicks, and arrow key navigation for better usability.
Form Validation: The newsletter form checks submissions, runs a strict Regex check on the email, and simulates a processing delay before switching the success/error DOM states.

The Design System: Using CSS Custom Properties

To maintain consistent styling across five different pages, the entire design system relies on CSS variables.

- Emotional Design

:root {
  /* --- Brand Colors --- */
  --color-brand-50:  #FFF1F2;
  --color-brand-100: #FFE4E6;
  --color-brand-500: #F43F5E;
  --color-brand-600: #E11D48; /* Primary Brand Color */
  --color-brand-700: #BE123C;
  --color-brand-900: #881337;

  /* --- Neutral Colors --- */
  --color-bg-cream:  #FDF2F0; /* Global Background */
  --color-bg-white:  #FFFFFF;
  --color-text-main: #1F2937;
  --color-text-muted:#4B5563;
  --color-border:    #E5E7EB;

  /* --- Extended Colors --- */
  --color-burgundy-900: #7E0C2A;
  --color-rose-25: #FFF7F7;
  --color-rose-30: #FFF5F3;
  --color-rose-50: #FFF5F5;
}

We steered clear of cliché "Valentine's Day Hot Pink." Instead, we chose a mature color scheme that ranges from rose to deep burgundy, complemented by a warm cream background (#FDF2F0).

The Spacing & Shadow System Nothing is hardcoded. Every gap and padding uses an 8-point scale (for example, --space-4 for 16px). Shadows are named according to their component instead of their technical values:

--shadow-primary-btn for our call-to-action buttons.
--shadow-feature-card for key elements.

CSS Grid to the Rescue We relied heavily on CSS Grid to handle common layout challenges. For example, centering a navbar with different widths for the logo and the auth buttons can be tricky with Flexbox. Using CSS Grid with 1fr auto 1fr solves this perfectly:

.navbar {
  display: grid;
  grid-template-columns: 1fr auto 1fr;
  grid-template-areas: "logo  links  auth";
  align-items: center;
}

The two 1fr columns share the space equally, keeping the links centered relative to the viewport, no matter what happens on the sides.

Typography

/* --- Typography --- */
--font-serif: 'Playfair Display', serif;
--font-sans:  'Inter', sans-serif;

--text-size-h1: 3rem;    /* 48px */
--text-size-h2: 2rem;    /* 32px */
--text-size-h3: 1.25rem; /* 20px */
--text-size-p:  1rem;    /* 16px */

/* Additional fluid sizes */
--text-size-xs:  0.75rem;
--text-size-sm:  0.95rem;
--text-size-2xs: 0.7rem;

Playfair Display handles all headings and the logo. It has an elegant and editorial quality. Inter handles body text, navigation, and UI labels because it is clean and very readable at small sizes on screens.

Semantic HTML & Accessibility

Semantic HTML was a priority. Every saved plan is wrapped in an tag because it is a self-contained piece of content. We linked headings to their parent containers using aria-labelledby so screen readers properly announce card titles. Here is a plan card from the My Plans page:

<article aria-labelledby="plan-1-title" class="plan-card card">
  <figure class="plan-media card-media">
    <img
      src="https://images.unsplash.com/photo-1604942030135-73e2f02503b3?q=80&w=751"
      alt="Starlit rooftop picnic setting"
      width="600"
      height="360"
    />
  </figure>

  <h2 id="plan-1-title" class="plan-title">Starlit Rooftop Picnic</h2>

  <p aria-label="Plan tags" class="plan-tags tag-list">
    <span>Romantic</span>
    <span>NN</span>
    <span>3 hrs</span>
  </p>

  <p>
    A curated evening with artisanal snacks, plush blankets, and a
    telescope for star-gazing.
  </p>

  <div aria-label="Plan actions" class="plan-actions">
    <a href="/plans/starlit-rooftop-picnic" class="plan-link">View Details</a>
    <button type="button" class="plan-done">Completed</button>
  </div>
</article>

Each card is an because it is a self contained piece of content. The heading is linked to the article using aria-labelledby so screen readers announce the card title when a user navigates to it.

Other accessibility decisions across the project:

Skip Links: A hidden <a class="skip-link" href="#main-content"> lets keyboard users jump straight past the navigation.
Semantic Outlines: Strict heading hierarchy (one <h1> per page, down to <h3> for cards) for both SEO and screen readers.
Screen-Reader Only Text: We used a .sr-only utility class for labels that are meaningful to assistive tech but shouldn't clutter the visual UI.

.sr-only {
  position: absolute;
  width: 1px; height: 1px;
  padding: 0; margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}

The Most Challenging Component: CSS Only Hamburger Menu
The mobile navigation works with absolutely zero JavaScript. We used the "hidden checkbox hack." A hidden <input type="checkbox"> acts as the state, and a styled acts as the button.

<!-- input and label MUST come before the nav groups -->
<input type="checkbox" id="nav-check" class="nav-check" aria-hidden="true">
<label for="nav-check" class="nav-toggle" aria-label="Toggle navigation">
  <span></span>
  <span></span>
  <span></span>
</label>

<div class="nav-links">...</div>
<div class="nav-auth-group">...</div>

Using the CSS sibling selector (~), checking the box reveals the menu and animates the three hamburger bars into an "X":

.nav-check:checked ~ .nav-links {
  display: flex;
  flex-direction: column;
  align-items: flex-start;
  gap: var(--space-4);
  padding: var(--space-4) 0 var(--space-2);
  border-top: var(--border-1) solid var(--color-border);
  margin-top: var(--space-3);
}

.nav-check:checked ~ .nav-toggle span:nth-child(1) {
  transform: translateY(7px) rotate(45deg);
}
.nav-check:checked ~ .nav-toggle span:nth-child(2) {
  opacity: 0;
}
.nav-check:checked ~ .nav-toggle span:nth-child(3) {
  transform: translateY(-7px) rotate(-45deg);
}

Reflection: Lessons and Version 2

What was hardest: Keeping CSS class names consistent across multiple HTML files before the styles began to break. We quickly learned to treat class names as unchangeable contracts before applying any styling.

What surprised me technically: position: sticky completely gives up if a parent container has position: relative. It creates a scroll boundary that breaks the sticky behavior. It isn't obvious until you spend an hour battling it.

What I would do differently in version two: While localStorage and a static JSON file are very fast, they are tied to the user’s current device. The next step for DateSpark is to replace our local storage setup with a real database. This way, users can create accounts, log in from anywhere, and keep their date plans in sync permanently.

Contributors

This project was a wonderful team effort! A big thanks to my amazing coding partner, Chijioke.

Check out their GitHub here: Chijex5
Read about their side of the DateSpark journey here.