DEV Community: Chijioke Uzodinma

Shipping Bloom After: My Week 4 Wrap-Up

Chijioke Uzodinma — Sat, 28 Mar 2026 09:47:20 +0000

By Chijioke Uzodinma | Backend Lead, Bloom After

In my previous articles, I walked through our journey from planning the system in Week 1, to building the backend in Week 2, and stabilizing and connecting everything in Week 3.

Week 4 was the final stretch.

This week was focused on finishing the product, fixing critical issues, and making sure everything works smoothly across all pages.

What I Shipped This Week

As Backend Lead, my focus this week was on refining the system and resolving issues that affected the overall user experience.

Here are the key things I finalized:

Completed the admin dashboard, ensuring all core actions work properly
Fixed multiple frontend integration and UI bugs
Resolved a major routing issue on the frontend
Ensured all features were fully connected and working end-to-end

By the end of the week, the platform moved from “almost ready” to fully functional.

Fixing a Major Routing Issue (Frontend)

One of the biggest problems we faced this week was with routing on the frontend.

Since the project was built using HTML and CSS, our pages were structured as separate .html files. This caused issues where links looked like:
/resource-page.html

instead of cleaner routes like:
/resources

Because of differences in environments and folder structure, navigating between pages would sometimes result in 404 errors, especially after deployment.

In many cases, we had to manually adjust paths depending on how the project was being served.

To fix this, we used Vite’s configuration and restructuring approach to make routing more consistent and predictable across environments.

This issue really showed how something that seems small — like file paths — can affect the entire user experience.

What Bloom After Does

Bloom After is a platform designed to support Nigerian mothers dealing with Postpartum Depression (PPD).

It focuses on making support simple, accessible, and easy to navigate.

The platform includes:

Resources and educational content to guide users
A clinic finder to locate nearby help
Community stories to create a sense of connection
An admin system to manage all content on the platform

The goal is to reduce the stress of searching for help and make support easier to access.

Full Sprint Retrospective

What Went Well

One of the biggest improvements across the sprint was how much backend and frontend synchronization improved.

At the beginning, both sides were not always aligned, but over time communication improved, and the system started working more smoothly.

By Week 4, everything felt more connected.

What I Would Do Differently

If I were to start again, I would spend more time defining the full system before development begins.

That includes:

clearly mapping all pages
defining how features connect
planning how data flows between frontend and backend

This would have reduced confusion and prevented unnecessary rework.

What Surprised Me

One thing that stood out was how difficult debugging can be, even for simple issues.

Problems like routing or small UI bugs can take longer to fix than expected.

This sprint showed me that debugging is just as important as building.

Key Technical Lessons

Some key lessons I took from this sprint:

Data Modeling is critical
A well-structured backend makes **
everything easier
**
Frontend and Backend must align early

- Misalignment leads to rework
**

Small issues can have big impact ** Something like routing can break the entire experience

Looking Ahead

This sprint is complete, but there is still more to learn.

Going forward, I want to:

Improve how I design systems before building
Get better at structuring and architecture
Continue building full-stack applications with better coordination

Team Shoutouts

Appreciation to everyone who contributed to Bloom After:

Grace Olabode (Engineering Lead) – for guiding the project and ensuring consistency.

Nanji Lakan (Product Lead) – for shaping the direction of the platform.

Agugua Genevieve (Design Lead) – for designing a calm and supportive experience.

Prisca Onyemaechi (Lead Maintainer) – for keeping everything organized.

And the entire team for making this project possible.

Final Links

Live Product: https://the-bloom-after.netlify.app/
GitHub Repository: https://github.com/Tabi-Project/Bloom-After.git

Final Reflection

From planning in Week 1 to shipping in Week 4, this project was a full learning experience.

It was not just about building features, but about:

working with a team
solving real problems
handling pressure
and delivering a complete system And in the end, we built something that works — and something that matters.

Stabilizing and Scaling: My Week 3 Progress on Bloom After

Chijioke Uzodinma — Sat, 21 Mar 2026 08:32:56 +0000

By Chijioke Uzodinma | Backend Lead, Bloom After

In my Week 2 article, I talked about how we moved from planning into actual development — building our backend structure, creating APIs, and wiring the system to the frontend.

Week 3 felt different.

This was the week where things became more intense.

Instead of just building features, my focus shifted to completing, stabilizing, and connecting everything together so the platform could start behaving like a real product.

What I Built This Week

1. Community Stories System (Full Implementation)

One of the biggest features I worked on this week was completing the community stories system.

This included:

Building the backend for stories
Creating admin moderation functionality
Connecting the frontend story page to the backend
Implementing a rich text editor for proper content formatting

The rich text editor was especially important because stories are not just plain text — they need structure, formatting, and readability.

Instead of storing raw text, the system now supports properly formatted content, making it easier to display meaningful stories on the platform.

2. NGO and Suggestion System

Another major part of my work this week was completing the NGO system and suggestion drawer.

This involved:

Creating backend logic for NGOs
Building the suggestion submission system
Connecting both features to the frontend
Implementing admin moderation for these submissions

Now, the platform can accept and manage:

NGO-related data
Suggestions from users

And admins can review and manage these directly from the dashboard.

3. Admin System Expansion

I also expanded the admin system, making it more functional and closer to a real management dashboard.

This included:

Creating the settings page for admins
Building backend routes for inviting new admins
Connecting the settings page to the backend
Handling admin-related actions from the dashboard

This brings the admin dashboard to about 80% completion.

4. Email System Integration

One of the more interesting parts of this week was setting up email communication for the platform.

I created email templates and integrated Resend API to handle sending emails for:

Community stories
NGO submissions
Suggestions
Admin invites

This makes the platform more interactive and responsive, allowing users and admins to receive updates and notifications.

Feature Progress This Week

By the end of Week 3, several major parts of the platform reached near completion:

Admin dashboard – ~80% complete
Resources system – fully functional
Community stories – completed
NGO system & suggestion drawer – completed

This was the first week where the platform started feeling like a connected system, not just separate features.

Challenges I Faced

The biggest challenge this week wasn’t just technical — it was time and coordination.

Because of how the work was structured, I delayed starting my main tasks until later in the week so the frontend team could finish their parts first.

This meant that most of my workload was compressed into Thursday and Friday, making those days extremely intense.

Another challenge was misalignment between frontend and backend expectations.

For example:

Some frontend components were built without considering how the data would be structured
Certain features didn’t account for admin actions like editing or deleting content
In some cases, I had to adjust or rebuild parts to ensure they worked properly with the backend

This wasn’t anyone’s fault — it’s a normal part of working in a team — but it showed me how important early communication is when building connected systems.

What I Learned

This week taught me something important about leadership:

Being a Backend Lead is not just about writing code — it’s about adapting to people, timelines, and imperfect systems.

Not every task will come to you in a perfect state.

Not every implementation will align immediately.

Sometimes you have to:

Adjust quickly
Fill in missing pieces
Work under pressure
Still deliver something stable

It also reinforced how important it is to think beyond just your own part and consider how everything connects together.

From Week 2 to Week 3

The shift from Week 2 to Week 3 was clear:

Week 2: Build the backend foundation
Week 3: Complete, stabilize, and connect the system This week was less about starting new things and more about making sure everything actually works together.

Team Shoutouts

Appreciation to the team building Bloom After:

Grace Olabode (Engineering Lead) – for continuing to guide the overall development and reviewing key changes.

Nanji Lakan (Product Lead) – for keeping the platform aligned with user needs.

Agugua Genevieve (Design Lead) – for maintaining a clean and supportive design direction.

Prisca Onyemaechi (Lead Maintainer) – for keeping everything organized on GitHub.

And to everyone contributing across tracks — this week really showed how much teamwork matters when systems start connecting.

Looking Ahead

Week 3 was intense, but it was also one of the most important weeks so far.

With most core systems now in place, the next phase will focus on:

Refining the platform
Fixing edge cases
Improving performance
Finalizing remaining features

We’re no longer just building parts — we’re shaping the full experience.

Turning Plans Into Code: My Week 2 Progress on Bloom After

Chijioke Uzodinma — Sat, 14 Mar 2026 00:28:12 +0000

By Chijioke Uzodinma | Backend Lead, Bloom After

In my Week 1 article, I talked about laying the foundation for Bloom After — planning the database structure, onboarding the backend team, and translating the product requirements into a data model we could build on.

This week was different.

Instead of just planning the system, we actually started building the backend that will power the platform.

By the end of the week, we had built roughly a quarter of the backend, including our database models, core APIs, authentication logic, and the first integrations with the frontend.

What I Built This Week

1. Building the Backend Architecture

One of my main responsibilities this week was setting up the core backend structure that the platform will run on.

We began building the backend using Node.js with MongoDB via Mongoose, which allows us to define structured models for the different types of data Bloom After will manage.

I worked on creating and wiring the main database models for:

Resources – educational materials and support content
Clinics – locations where mothers can find help
Community Stories – shared experiences from mothers
Admin accounts – used to manage platform content

Defining these models early allows the frontend to interact with consistent data structures when retrieving or updating information.

Alongside the models, I also implemented several backend utilities including:

API routes for resources and clinics
Rate limiting to protect the backend from abuse
Basic server structure for handling requests

This forms the backbone of the application that future features will build on.

2. Wiring the Backend to the Frontend

Another major part of my work this week involved connecting the backend APIs to the frontend pages that the team is building.

Working closely with Grace Olabode, who has been developing the Resources and Clinic Finder pages, I wired backend endpoints that allow those pages to retrieve real data from the server.

This included connecting backend routes for:

Resources
Clinics
Admin login
Dashboard data

To make it easier for the frontend to interact with the backend, I also created a small utility API helper file that simplifies how requests are sent to the backend from the frontend code.

3. Admin Login and Dashboard Setup

Another feature I worked on was the admin login page and backend authentication flow.

The goal of this system is to allow authorized administrators to log in and manage content like resources, clinics, and community stories.

For the frontend side of this feature, I built the admin login page and added loading states so users receive clear feedback while requests are being processed.

On the backend, I wired the authentication logic so that login requests communicate properly with the database.

4. Handling Location Data for the Clinic Finder

One of the more challenging technical problems I worked through this week involved location-based search for clinics.

The clinic finder is designed to help mothers locate nearby support centers. However, searching for clinics by location turned out to be more complex than I initially expected.

For example:

A clinic might be located in Ikeja, but if a user searches for Lagos, the system should still return that clinic.

Similarly, searches for places like Ojo or Oshodi-Isolo should still surface relevant nearby hospitals.

To make this work, I had to start working with latitude and longitude data, using geolocation APIs to convert addresses into coordinates.

Once we have those coordinates, we can compare distances between locations and determine which clinics are closest to the user.

This part of the system is still evolving, but this week was the first step toward making the clinic search smarter and more accurate.

Infrastructure and Deployment

Another part of the work this week involved preparing the backend infrastructure so the application can run reliably.

Together with Grace, we set up several services for the project:

MongoDB for storing application data
Cloudinary for hosting images and media assets
Render for deploying and running the backend server

Grace created the initial service accounts, and I worked on configuring the backend to use the environment variables needed to connect everything properly.

By the end of the week, we had the backend successfully deployed, allowing the team to start testing the system in a live environment.

Supporting the Backend Team

As Backend Lead, part of my role is also coordinating with other developers contributing to the backend track.

This week I assigned two early tasks to members of the backend team:

Prospect worked on the login page functionality
Sophia worked on helping set up MongoDB and database configuration Both did great work, and reviewing their implementations was a good learning experience for me as well.

One of the best parts of working in a collaborative sprint like this is how much you learn from reading other developers’ code and approaches.

Challenges I Faced

The most difficult challenge I faced this week was working with location data.

Handling location searches sounds simple at first, but once you start thinking about how people actually search for places, it becomes more complicated.

A user might search for a state, a city, or even a local government area. Making sure the system still returns relevant clinics requires converting addresses into coordinates and comparing distances accurately.

I spent a good amount of time experimenting with geolocation APIs and figuring out how to structure the data so this system will work reliably.

What I Learned

One interesting thing I learned this week is that cookies can still be used even when the frontend and backend are on different domains.

Before this project, I assumed cookies only worked easily when both systems shared the same origin.

But with proper configuration, cookies can still work across domains — although the security setup is slightly different.

This was something one of the backend volunteers explained to me, and it opened up new options for how authentication can be handled.

Feature Progress This Week

By the end of Week 2, several parts of the platform had started taking shape:

Admin login and dashboard system
Resource content APIs
Clinic finder backend logic
Community stories system (in early development)

Seeing these pieces start to connect made this week feel like the moment the project really began to come alive.

Team Shoutouts

Building Bloom After is a team effort, and I want to recognize the people making it happen.

Grace Olabode (Engineering Lead) – I collaborated with Grace a lot this week while wiring the backend to the resources and clinic pages she built. She also reviewed and merged several of my pull requests.

Nanji Lakan (Product Lead) – for continuing to guide the direction of the platform.

Agugua Genevieve (Design Lead) – for designing an interface that makes the platform feel supportive and easy to use.

Prisca Onyemaechi (Lead Maintainer) – for maintaining a smooth GitHub workflow.

And the backend contributors Prospect and Sophia for their great work this week.

Looking Ahead

Week 2 was where Bloom After moved from planning to actual development.

With the backend architecture now in place and our first APIs running, the next step is expanding the system so the platform can fully support the resources, clinics, and stories that mothers will rely on.

There’s still a lot to build — but now the engine is running.

Laying the Data Foundation: My Week 1 as Backend Lead for Bloom After

Chijioke Uzodinma — Fri, 06 Mar 2026 19:19:05 +0000

By Chijioke Uzodinma | Backend Lead, Bloom After

When people think about building a website, they usually focus on what users see — the layout, the colors, and the pages.

But behind every website is something users rarely think about: the structure of the data that powers it.

For the International Women’s Day Sprint with the Tabi Project and TEE Foundation, our team is building Bloom After — a website designed to support Nigerian mothers dealing with Postpartum Depression (PPD) by providing trusted resources, clinic information, and supportive community stories.

As the Backend Lead, my role during Week 1 (our setup week) was to help plan the data structure that will support these features and to get the backend team aligned before development begins.

Translating the Product Idea into Data

Before writing backend code, we first had to understand what kind of information Bloom After will manage.

From the Product Requirements Document (PRD), the platform will eventually include:

Educational articles and resources
A clinic finder to help mothers locate nearby support
Information about mental health specialists
Community stories where mothers can share experiences
Administrative tools to manage the platform

My main task this week was translating those ideas into a database plan.

That meant identifying the tables we would need and thinking through the columns each one should contain.

Planning this early helps ensure that when development begins, the backend structure already supports the features we want to build.

Preparing the Backend with Supabase

For this project, we decided to use Supabase as our backend platform.

Supabase provides a PostgreSQL database along with helpful tools for authentication and APIs. Since we are working in a fast sprint environment, it allows us to focus on building features instead of managing server infrastructure.

During this first week, the focus wasn’t on building the backend yet, but on preparing the data model and understanding how Supabase will support the system when development starts.

Working with the Backend Track

Another part of my role this week was helping onboard and coordinate with backend students from other learning tracks who will be contributing to the project.

Since this was still our setup phase, most of our work involved:

Reviewing the project requirements
Understanding how the backend will support the platform
Discussing the structure of the data
Preparing for development in the coming weeks

This early alignment helps make sure everyone understands the direction before we begin building.

Contributing to the Resource Preview Section

While the backend planning was ongoing, I also worked on part of the resource preview section on the homepage.

This section showcases examples of the types of materials the platform will eventually provide to support mothers experiencing postpartum depression.

Even though the full resource system isn’t built yet, designing this preview section helps communicate the purpose of the platform and what users can expect.

What I Learned This Week

Week 1 reminded me that backend work begins long before writing actual code.

It starts with:

Understanding product requirements
Designing clear data structures
Communicating with the team
Planning how features will connect

It also showed me how important collaboration is when working across multiple tracks. Even during the setup phase, conversations with the team helped refine ideas and clarify how the system should work.

Team Shoutouts

A huge thank you to the amazing people building Bloom After together:

Grace Olabode (Engineering Lead) – for setting up the technical structure and guiding the development process.

Nanji Lakan (Product Lead) – for keeping the product focused on the real needs of mothers experiencing PPD.

Agugua Genevieve (Design Lead) – for designing a platform that feels calm, welcoming, and supportive.

Prisca Onyemaechi (Lead Maintainer) – for keeping our GitHub workflow organized.

Christine Mwangi (People Manager) – for making sure the team stays connected and supported.

And to everyone across the UIUX and backend tracks contributing to the sprint.

Looking Ahead

Week 1 was all about laying the groundwork.

With the data planning and onboarding complete, the next phase will involve actually building the backend systems that power Bloom After — including the resource library, clinic finder, and community stories.

There’s still a lot to build, but the foundation is in place.

And that’s where every strong system begins.

Live Landing Page:
GitHub Repository: https://github.com/Tabi-Project/Bloom-After.git

Building DateSpark: A Simple Date Planning Website

Chijioke Uzodinma — Sat, 21 Feb 2026 00:30:53 +0000

Intro + Problem + What DateSpark is

Have you ever spent more time arguing about what to do on a date than actually going on the date?

That was the exact problem we wanted to solve with DateSpark.

DateSpark is a simple multi-page website for couples that helps make date planning feel easier and more organized. Instead of endless “what should we do?” messages, the site guides you through a clean flow where you can explore date ideas, view them by category, and keep track of plans.

Because this was built as a beginner project, we kept the tech stack simple: HTML and CSS only (no JavaScript yet). That made the project more about structure, layout, responsiveness, and consistency across pages — and that’s where most of my learning came from.

Who it’s for: young couples (or even friends) who want quick, thoughtful date inspiration without stress.

What We Built (Pages & Flow)

One thing we were intentional about was building DateSpark as a multi-page website, not a single long page.

We structured the site into five main pages:

Home (index.html) – Introduction and landing page

Generate – Where users select preferences and get a date idea

Browse – A collection of date ideas organized visually

My Plans – A page showing saved or planned ideas

Login / Sign Up – Authentication layout pages

Even though we are still working with only HTML and CSS, we wanted the project to feel like a real product with proper navigation and flow.

The user journey looks like this:

Home → Generate → Browse → My Plans → Auth

Each page links properly using anchor tags, which helped us understand how multi-page websites connect together without frameworks.

Working with separate HTML files forced us to stay consistent with:

Navbar structure
Class names
Layout containers
Spacing

If something was slightly different in one file, the design would immediately break.

My Main Focus in the Project

Although we both worked across different parts of the project, I found myself spending most of my time on:

Structuring page layouts

Implementing Grid and Flexbox

Making pages responsive

Debugging CSS issues

Making sure styles remained consistent across files

What surprised me most was how much time layout structuring actually takes.

Designs may look simple, but translating them into properly nested HTML containers requires careful thinking:

Which elements should be wrapped inside a <section>?

When should something be a <div> vs an <article>?

Should this layout use Grid or Flexbox?

How will this behave on mobile?

Those questions shaped most of my contribution.

Building the Generate Page (Prototype Logic with HTML & CSS)

The Generate page is one of the most important parts of DateSpark because it represents the main idea of the project.

Right now, since we are working with only HTML and CSS, the “generation” feature is a structured prototype. Users can:

Select options from dropdown menus
Click a generate button
View a pre-designed result section

Although the result is static for now, building the layout required careful structuring.

We had to design:

The form layout
The spacing between selects
The result card section
Proper alignment between text and image
Responsive stacking for mobile

Even without JavaScript, we wanted the page to feel real and complete.

Layout Decisions: Grid vs Flexbox
One of the biggest things I practiced in this project was deciding when to use Grid and when to use Flexbox.

For larger sections like:
Page layout containers
Two-column sections
Centering main content We used CSS Grid.

For smaller elements like:

Navigation links
Card buttons
Tags inside cards
Aligning items horizontally

We used Flexbox.

At first, I sometimes used Flexbox for everything. But I started noticing that Grid made certain layouts cleaner and more predictable.

Understanding the difference between the two helped improve the structure of our pages.

Responsiveness and the Hamburger Menu

Responsiveness was one of the more technical parts of our HTML and CSS work.

On smaller screens:

Navigation links could not stay horizontal
Cards needed to stack
Spacing needed adjustment
Font sizes needed slight changes

To solve the navigation issue, we built a hamburger menu using:

A hidden checkbox
A label styled as the toggle button
CSS selectors to show/hide navigation

Before adding this, the navbar would overflow on mobile devices.

After implementing it, the layout became more usable and clean on smaller ooooscreens.

Working on responsiveness helped me understand how much planning mobile design requires.

CSS Debugging — The Real Learning Curve

The part I personally spent the most time on was debugging CSS.

Some common issues I encountered:

A class name mismatch between HTML and CSS
Styles applying on one page but not another
Grid alignment shifting unexpectedly
Flex items stretching differently than expected
Margin and padding conflicts

Unlike JavaScript, CSS doesn’t give error messages.

If something is wrong, it simply doesn’t work.

I learned to rely heavily on:

Inspect Element in the browser
Checking computed styles
Reviewing class names carefully
Removing unnecessary nested containers

This project improved my patience and attention to detail more than anything else

Real Challenges I Faced

Replicating the Generate Select Design from Figma:
One of the hardest parts for me was trying to match the Generate page dropdowns to the Figma design.

Each option block had:

A main label (e.g. Budget)
A smaller subtext (e.g. Price Range)
The dropdown arrow aligned to the far right
Clean spacing and alignment

In theory, it looks simple.

In reality, aligning:

The title
The subtitle
The element
The arrow positioning

was frustrating.

Sometimes the arrow would shift.
Sometimes the spacing looked off.
Sometimes the text alignment didn’t match the design.

Since native elements have default browser styling, it made customization harder than expected.

It took several adjustments with:

Flexbox alignment
Padding tweaks
Width adjustments
Removing default styles

Before it looked close to the design.

That experience taught me that small UI details can take more effort than large layout sections.

What This Project Taught Me

Working on DateSpark helped me understand that:

Layout precision matters more than I thought
Replicating designs exactly is not always easy
CSS debugging requires patience
Small elements can affect large layouts
Consistency across multiple HTML files is important

Before this project, I saw HTML and CSS as basic tools.

After building a multi-page responsive website, I now understand how much structure and planning they require.

What We Would Improve Next

If we continue developing DateSpark, the next steps would include:

Adding JavaScript to make the date generator fully dynamic

Improving the dropdown customization further

Refining spacing and responsiveness

Possibly integrating storage so plans can be saved

For now, as a pure HTML and CSS project, DateSpark represents our understanding of layout, structure, responsiveness, and collaborative development.

Contributors

This project was a team effort built with my fantastic partner.

Check out their GitHub here: https://github.com/devanike
Read their thoughts on building DateSpark in their case study here:https://dev.to/grace_olabode_3be546efe9b/building-datespark-a-date-planning-app-for-couples-2d46