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.
Top comments (0)