Forem: AJ

Building Ekehi — Week 4: Admin Tools, Profile Images, Submissions, and Closing the Loop

AJ — Sat, 28 Mar 2026 09:54:06 +0000

This is part of an ongoing series documenting the build of Ekehi, a platform connecting African entrepreneurs with funding opportunities, training programmes, and business resources. I'm AJ, the Engineering Lead on the project.

Where We Left Off

Sprint 3 gave us a polished opportunities section — redesigned detail page, working save feature, correct saved state on page load, and a contributors page with skeleton loading. Sprint 4 had a different character. Less redesign, more completion. The goal was to close out everything still outstanding: ship profile image support end-to-end, build the submissions page, wire the resources section to the real API, and deliver a functioning admin content management system with approval, rejection, and delete.

Seven issues created on Monday morning. All closed by Thursday. Issue #80 — the long-running tracker for wiring all frontend pages to the real API — finally closed.

What I Personally Shipped

1. Profile Image Upload — Backend (PR #114)

The first task of the week was building profile image upload into the auth and profile flow.

What was built:

Added profile_image_path TEXT NULL to the profiles table via a Supabase migration
Installed multer for multipart/form-data parsing with memory storage (5MB limit, JPEG/PNG/WebP only)
Created a shared upload.middleware.js with the multer config, reusable across routes
Updated POST /auth/signup to accept an optional profileImage file alongside existing form fields
Added GET /profile — returns the authenticated user's full profile
Added PATCH /profile — updates firstName, lastName, and/or profileImage
Built storage.utils.js with shared helpers: uploadProfileImage, getPublicImageUrl, deleteImage
Images stored in the ekehi-assets bucket at profile-images/<userId>/avatar.<ext> with upsert

One deliberate design decision: the database stores the storage path, not the full URL. The full URL is derived at read-time via getPublicUrl(). This decouples the data from the infrastructure — if the bucket or region ever changes, nothing in the database needs updating.

2. Profile Image Upload — Frontend (PR #130)

With the backend in place, the nav avatar now fetches the user's profile on mount, reads profile_image_path, derives the public URL, and renders it. If the image is absent or fails to load, the placeholder icon shows — the user never sees a broken image element.

3. Admin Content Management — Full Lifecycle (PR #136)

This was the most significant backend work of the sprint. Content submitted by users needed to be reviewable, approvable, rejectable, and deletable by admins — all from a single admin interface.

Approval and rejection flow

Built PATCH /admin/{contentType}/{id}/review accepting { decision: "approved" } or { decision: "rejected", feedback: "..." }. On approval, approval_status is updated to "approved" and the item immediately appears on public endpoints. On rejection, feedback is required — enforced on both client and server.

Every review writes an audit record to the content_reviews table: who reviewed it, when, the decision, and any feedback. This gives the admin team a full history of every content decision.

Delete functionality

Built DELETE /admin/{contentType}/{id} protected by adminGuard. Works on any approval status. The review page shows a Danger Zone card with a delete button. Clicking it opens a confirmation dialog before the request fires — permanent deletion cannot be triggered by a stray click.

Queue status filters

Previously the admin queue only showed pending content. Approved and rejected content was unreachable from the admin UI. Added a two-row tab system: status tabs (Pending / Approved / Rejected) above type tabs (All / Funding / Training / Guide / Template). The full content lifecycle is now manageable from one place.

4. RBAC Implementation (Issue #120)

Completed the role-based access control system. Added a CHECK constraint to the profiles table enforcing only valid roles: super-admin, data-manager, content-editor, user. The adminGuard middleware — which protects all /admin/* routes — validates both authentication and role before any admin operation executes.

All destructive operations (approve, reject, delete) sit behind this guard. The separation is clean: public routes, authenticated user routes, and admin routes are three distinct layers with no overlap.

5. Submissions Page, Resources Wiring, and Clean Code (PR #136)

Submissions page (/submissions/)

Built a protected 3-section accordion form for authenticated users to submit funding opportunities. The sections are: About the Opportunity, Programme Details, and About the Organiser — so the form doesn't feel like an overwhelming wall of fields.

Key decisions:

Auth-gated on the client: unauthenticated visits redirect to login with ?redirect=/submissions/
Dropdowns use the existing Dropdown component, not native <select>, keeping the UI consistent
Submitted opportunities land as approval_status: "pending" — straight into the admin review queue
POST /opportunities is open to any authenticated user, not just admins, so the community can contribute

Guides and templates wired to real API

Both sections were rendering hardcoded placeholder data. This PR replaced all of that with real API calls, loading skeletons, and proper error states.

Clean code pass

Extracted parsePagination as a shared utility — removes repeated Math.max/min clamping across controllers
Extracted extractBearerToken in auth.middleware.js — used by both requireAuth and optionalAuth
DRY'd the dropdown mount calls on the submissions form
Fixed a misleading comment on the rate limiter: said 15 min window, actual value was 2 min

What I Coordinated as Engineering Lead

Seven issues created on Monday, all closed by end of week:

Issue	Feature	Assignee
#113	Backend: profile image upload	Me
#115	Frontend: build training detail page	Marion
#116	Frontend: add Guides section to resources page	Victor
#117	Frontend: add Templates section to resources page	Florence
#118	Frontend: build guide detail page	Oluchi
#119	Frontend: build template detail page	Esther
#120	Complete RBAC implementation	Me

The team also shipped two bug fixes beyond their assigned issues — Iyobosa fixed filter wrapping on the training page and added empty-state messaging, and Gabriel shipped loading skeletons for opportunity and training card lists.

Technical Decisions and Why

Store storage path, not full URL

The first implementation stored the full Supabase Storage URL in the database. The problem: that URL is tied to the bucket name, project ID, and region. If any of those change, every stored URL breaks. Storing just the path (profile-images/<userId>/avatar.jpeg) and deriving the URL at read-time via getPublicUrl() means the database is infrastructure-agnostic. getPublicUrl() is synchronous — no extra network call, no performance cost.

Fixed filename avatar.<ext> per user

Generating a unique filename per upload (e.g., timestamped) accumulates stale files in storage every time a user updates their photo. A fixed path with upsert means one file per user, always replaced. No cleanup job needed.

Multer memory storage, not disk

The server runs on Render — no persistent disk. Writing temp files would fail between requests anyway. Memory storage keeps the pipeline direct: file arrives → buffer → forward to Supabase → discard.

Rejection requires feedback, approval does not

Approving content is a binary yes. Rejecting content without explanation leaves the submitter with no way to improve their submission. Feedback is required on rejection, enforced at both the API and UI layer.

Submissions open to all authenticated users

Restricting submissions to admins would make the content team a permanent bottleneck. The approval_status: "pending" flow handles gatekeeping — every submission goes through review before going live. The submission endpoint does not need to be the gatekeeper.

Two-row tab system for admin queue

The first design had only type filters. But pending content was the only reachable state — approved and rejected items had no UI entry point. Status tabs were added as the primary row because status reflects the workflow (pending → decision), with type as secondary filtering. Approved content now has a home in the admin UI.

Bugs I Encountered and Fixed

Admin dashboard showing empty — `data?.items` vs `data`

The admin dashboard stats were showing zero counts and the queue was showing no pending items, even though the database had content.

Root cause: the API returns { success, data: [...] }. The frontend was reading data?.items — which is always undefined because the array is at data, not data.items. One character fix, but it made the entire admin interface appear broken.

Guide TOC scrolling to wrong section

Clicking a guide's table of contents entry scrolled to the wrong section. The TOC was built from one data source, the body rendered from another — they had drifted out of sync.

Fix: Derive the TOC by mapping over the same content array used to render the body. Single source of truth — the two can never diverge.

Multer field name mismatch

Profile image uploads were silently failing. The frontend was sending the file as profileImage (camelCase) but the multer config expected profile_image (snake_case). The field name mismatch meant multer never found the file.

Fix: Aligned field names across frontend and middleware configuration.

Guide cards rendering with no description text

Guide cards were showing a title but no text beneath. The frontend was reading card.summary, the API was returning card.description. A field name mismatch that only surfaces when placeholder data is replaced with real API responses.

Sprint Reflections

What worked well

The team is moving faster than ever. Issues that took two or three days in Sprint 2 are turning around in under 24 hours. The shared patterns — skeleton loading, the Dropdown component, the response envelope, the adminGuard — mean contributors spend less time on decisions and more time building.

Closing issue #80 this sprint felt like a milestone. It had been open since Sprint 2 and tracked a wide surface area of unfinished API wiring. The app is now fully connected end to end.

What I would do differently

PR #136 bundled too much — submissions form, resources wiring, admin work, and a clean code pass all in one. It made review harder and history less readable. Going forward I want each PR to have a single concern, even if that means opening more of them.

I also want to define API contracts — agreed field names, response shapes — before assigning frontend issues. The card.summary vs card.description mismatch and the data?.items bug both happened because frontend and backend were built independently without a shared spec.

What I'm Most Proud Of

The admin content management system. It is not flashy but it is the piece that makes the platform viable. Without it, submitted content just sits in the database with no way for the team to act on it. With it, the full lifecycle works: a user submits an opportunity → it lands in the review queue → an admin approves or rejects it with feedback → approved content goes live → if needed, it can be deleted. Every step is covered, audited, and protected by role-based access control.

That is the infrastructure that makes everything else on the platform trustworthy.

Team

Another strong sprint from the team:

Marion (@MarionBraide) — Training detail page, card rendering bug fix
Victor (@Okoukoni-Victor) — Guides section on resources page
Florence (@Florence-code-hub) — Templates section on resources page
Oluchi (@luchiiii) — Guide detail page
Esther (@first-afk) — Template detail page, hero section title fix
Iyobosa (@Fhave) — Training page filter fix, empty state messaging
Gabriel (@GabrielAbubakar) — Loading skeletons for opportunity and training card lists

GitHub repository: github.com/Tabi-Project/Ekehi

Ekehi Engineering Sprint 3 — Detail Pages, Save States, and Leading a Sprint

AJ — Sat, 21 Mar 2026 09:04:49 +0000

This is part of an ongoing series documenting the build of **Ekehi, a platform connecting African entrepreneurs with funding opportunities, training programmes, and business resources. I'm AJ, the Engineering Lead on the project.

Previously on Ekehi Engineering — What We're Building

Ekehi is a full-stack web app built with vanilla JavaScript on the frontend (Netlify), an Express.js API on Render, and Supabase (PostgreSQL + Auth) as the database and auth layer. The stack is intentionally lean — no frontend framework — which means every UX pattern we reach for has to be hand-rolled.

Sprint 3 was our most feature-dense week yet. Twelve issues, seven contributors, and a full redesign of the core user-facing pages — all landed and merged within the week.

What I Personally Shipped

Note Again: Going through the repository while reading the article will provide more context

1. Fixed the Broken Filter and Search Wiring (PR #83)

Coming out of Sprint 2, the opportunities and resources pages had a filtering UI — dropdowns, search bars, the works — but none of it was actually working. Filter selections were updating local state but never being sent to the API. Users could interact with every control and nothing would happen.

The fix involved:

Building a shared buildQueryString(filters) utility in opportunity.utils.js that serialises filter state into URL query params
Wiring onFilterChange on both pages to call the API with the constructed query string
Extracting a shared formatDate utility to remove a duplicate formatDeadline function that existed in three places

This was the first PR of the week and it unblocked the rest of the sprint. Can't really build on top of a broken foundation.

2. Structural Backend and Client Updates (PR #97)

Before the team could pick up their sprint issues, I needed to lay the groundwork — new pages scaffolded, backend routes wired, shared constants extended, and the admin dashboard built out. This PR covered:

Scaffolding the admin dashboard (/admin) with a content queue and review pages
Wiring backend routes for content management (create, update, approve opportunities)
Setting up the requireRole middleware for role-based access control
Creating the sprint 3 issue backlog on GitHub and assigning every task to the right team member

Though we had to shift the use of the admin to next week, getting this started will make the load easier.

3. Opportunity Detail Page Redesign + Save Feature (PR #111)

This was the biggest lift of the week and touched both the frontend and backend.

Two-column layout with sticky aside

The old detail page was a single-column wall of text. The new design called for a content card on the left and a sticky action sidebar on the right. This was implemented with CSS Grid (Grid is Supreme 👑):

#detail-root {
  display: grid;
  grid-template-columns: 1fr 296px;
  align-items: start;
  gap: var(--space-6);
}

.detail-aside {
  position: sticky;
  top: var(--space-6);
}

The grid only reveals after the API response arrives — before that, a loading text spans the full width using grid-column: 1 / -1. Once data loads, root.classList.add("is-loaded") triggers a CSS rule that unhides both columns.

Eligibility criteria as a bullet list

The eligibility criteria came back from the API as a single long string. Rather than dump it into a <p> tag, it was split on periods and each sentence rendered as a <li>:

function renderEligibilityList(criteria) {
  const items = criteria.split(".").map(s => s.trim()).filter(Boolean);
  return `<ul class="eligibility-list">
    ${items.map(item => `<li>${escapeHtml(item)}</li>`).join("")}
  </ul>`;
}

Correct save state on page load

This was the most technically interesting problem of the week. The save button needed to show "Saved" if the logged-in user had already bookmarked the opportunity — but the detail route (GET /opportunities/:id) was a public, unauthenticated endpoint, so req.user was always undefined.

My solution: add an optionalAuth middleware that reads the JWT if present but never blocks the request if it's missing.

const optionalAuth = async (req, res, next) => {
  const authHeader = req.headers.authorization;
  if (!authHeader || !authHeader.startsWith("Bearer ")) return next();

  const token = authHeader.split(" ")[1];
  const { data } = await supabase.auth.getUser(token);
  if (data?.user) req.user = data.user;

  return next();
};

With req.user now optionally populated, I updated getOpportunityById in the service layer to accept a userId and run a secondary query against saved_opportunities:

const getOpportunityById = async (id, userId = null) => {
  const { data, error } = await supabase
    .from("funding_opportunities")
    .select("*")
    .eq("id", id)
    .eq("approval_status", "approved")
    .single();

  if (error) throw error;
  if (!data) return null;

  let is_saved = false;
  if (userId) {
    const { data: saved } = await supabase
      .from("saved_opportunities")
      .select("opportunity_id")
      .eq("user_id", userId)
      .eq("opportunity_id", id)
      .maybeSingle();
    is_saved = !!saved;
  }

  return { ...data, is_saved };
};

The frontend now reads opp.is_saved directly from the detail response — no second API call, no loading flicker.

Contributor page skeleton loading

The contributors grid was an empty section until JavaScript loaded and fetched data. 14 skeleton cards are pre-rendered in static HTML, so the grid shape is visible immediately:

When real data arrives, container.innerHTML = "" clears the skeletons and real cards are appended.

Technical Decisions and Why

optionalAuth over a separate saved-state endpoint

My first instinct was to add a GET /opportunities/:id/save endpoint that the frontend could call after load. The problem: that's an extra network round-trip on every detail page visit, even for logged-out users who will never save anything. Embedding is_saved in the detail response costs one lightweight DB query only when the user is logged in, and zero overhead otherwise.

style.display instead of the hidden attribute

The tabs element on the opportunities page needed to be hidden for logged-out users. Setting element.hidden = true wasn't working. The reason: a .flex utility class in our stylesheet was setting display: flex with higher specificity than the [hidden] attribute selector. Using element.style.display = "none" overrides both — inline styles always win.

Skeleton cards in static HTML, not JavaScript

Generating skeletons in JS means users see an empty grid until the script runs, parses, and executes. Putting them in the HTML means they're visible on the first paint, before any JavaScript has been fetched. The real cards replace them cleanly; the user never sees a layout shift.

Breadcrumb outside #detail-root

The detail page renders by setting innerHTML on a root container. If the breadcrumb lives inside that container, every re-render wipes and re-creates it. Moving it to static HTML above the root means it's always present and never touched by JavaScript.

Bugs I Encountered and Fixed

Modal appearing in the top-left corner

After building the save auth-gate modal with the native <dialog> element, it was rendering in the top-left corner instead of centred. The native <dialog> centres itself using margin: auto — but our global CSS reset included * { margin: 0 }, which zeroed it out.

Fix: Explicitly position the modal with CSS transforms:

.modal {
  position: fixed;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

Modal closing when clicking inside the content

The backdrop click listener was using e.target === dialog, which fires for both a click on the backdrop and a click on the dialog's own padding. So clicking anywhere near the edge of the modal content was dismissing it.

Fix: Use getBoundingClientRect to check whether the click coordinates are actually outside the dialog box:

this.#dialog.addEventListener("click", (e) => {
  const rect = this.#dialog.getBoundingClientRect();
  const isBackdrop =
    e.clientX < rect.left || e.clientX > rect.right ||
    e.clientY < rect.top  || e.clientY > rect.bottom;
  if (isBackdrop) this.close();
});

`is_saved` always returning `false`

After adding is_saved to the service, the save button on the detail page was still showing "Save" even for saved opportunities. The middleware chain was correct but req.user was always undefined.

Root cause: the route GET /:id had no auth middleware at all — req.user was never set. The fix was adding optionalAuth to the route, which only runs the Supabase token check when an Authorization header is actually present.

Saved tab count always showing zero on page load

When a logged-in user landed on the opportunities page, the "Saved" tab badge showed 0 even if they had saved items. The count was only updated after they switched to the tab and triggered a fetch.

Fix: Fire a prefetch request on page load using ?limit=1 to get the total count from pagination metadata, without fetching all the actual records:

async function prefetchSavedCount() {
  const res = await api.get("/opportunities/saved?limit=1").catch(() => null);
  if (res?.meta?.total !== undefined) updateSavedTabCount(res.meta.total);
}

What I Coordinated as Engineering Lead

Beyond my own code, I created and assigned 12 issues at the start of the week that the full team executed on:

Issue	Feature	Assignee
#84	Navigation update — Submissions link + Post a Job button	Florence
#85	Hero section full redesign	Esther
#86	About section — dark purple full-width banner	Marion
#87	Value proposition — full-width image with colour wash	Victor
#88	What-we-offer — interactive list with contextual image	Oluchi
#89	FAQ section	Iyobosa
#92	Signup step 1 — multi-step identity form	Marion
#93	Signup step 2 — password creation	Marion
#94	Login page redesign	Florence
#90	Opportunity detail page redesign	Me
#91	Save auth-gate modal	Me
#96	Backend bookmark feature	Me

All 12 issues were closed by end of week.

Sprint Reflections

What worked well

Breaking the sprint into small, scoped issues before the week started meant every team member knew exactly what to build and there were no blockers waiting on decisions. The team executed fast — most PRs were open and merged within 24 hours of the issue being created.

The decision to keep the stack simple (no framework, no build tool) paid off this sprint. Everyone could read and understand each other's code. There was no configuration friction when reviewing PRs.

What I would do differently

My own commit messages were too vague. "chore: update opportunities detail page" tells you nothing about why things changed. I was kinda lazy and in a time crunch to fix bugs to be kinda detailed in some commits. Next sprint I want to write commit messages that explain the reasoning, not just the file that changed.

I also want to define API contracts (request/response shape) before frontend work begins. This sprint, the is_saved field was added mid-week because the frontend hit a wall — if that had been in the spec from day one, the detail page would have been complete two days earlier.

What I'm Most Proud Of

The optionalAuth middleware is a small thing but it's the right thing. It solves a real problem — "how do you personalise a response on a public route?" — cleanly, without compromising the security model or adding a separate endpoint. The route stays public, unauthenticated users get a fast response with is_saved: false, and logged-in users get the correct state with one lightweight extra query. No frontend complexity, no extra round-trip. That's the kind of decision that doesn't show up in screenshots but makes the product feel solid.

Team

Big shoutout to the team for executing an ambitious sprint cleanly:

Marion (@MarionBraide) — About section, multi-step signup flow, bug fixes
Esther (@first-afk) — Hero section redesign
Victor (@Okoukoni-Victor) — Value proposition section
Oluchi (@luchiiii) — What-we-offer section
Iyobosa (@Fhave) — FAQ section
Florence (@Florence-code-hub) — Navigation update, login page redesign

GitHub repository: github.com/Tabi-Project/Ekehi

Closing Thought

                                                                                                                      Sprint 3 was kinda a blur with how feature densed it was. It reminded me that engineering leadership is less about writing the most code and more about making sure the right code gets written by the right people at the right time. My most valuable work this week wasn't a feature, it was creating 12 well-scoped issues, so that six teammates could ship confidently without waiting on me.
                                                                                                                        The best sprints feel boring from the outside. No fires, no blockers, no heroics — just a team moving steadily through a well-defined backlog. That's what we're building toward, and this week got us closer.

Ekehi Engineering Sprint 2 — Building the Ekehi Resource Discovery Engine

AJ — Sat, 14 Mar 2026 10:04:12 +0000

How I architected and shipped features of a funding discovery platform for African women entrepreneurs, orchestrating a team of 7 while staying hands-on in the codebase.

Context

As stated last week in my previous article, Ekehi is a resource discovery platform built for women-led businesses across Africa. It surfaces funding opportunities, training programmes, and credit products which are aggregated, vetted, and filterable in one place.

Note: Going through the repository while reading the article will provide more context

As the Engineering Lead, the team's job was to ship the three core features that would make Ekehi real:

Feature 3.1 — Funding Opportunities: a searchable, filterable directory of active funding across VC, grants, accelerators, loans, and more
Feature 3.3 — Training & Capacity Building: a curated listing of business programmes, bootcamps, and accelerators for women entrepreneurs
Feature 3.4 — Sector Classification: a consistent taxonomy enabling precise filtering across all resource types

Seven frontend contributors. A backend to build from scratch. One week.

Designing the Architecture First

Before writing a line of feature code, I had to answer one question: where does the data live, and how does the frontend get it? (this is two grouped into one, but you get the gist).

The stack constraint was already set — Netlify for the frontend, Supabase as the database. We had to introduce an Node.js/Express API layer on Render between them, rather than letting the frontend call Supabase directly.

Client (Netlify) → Node.js/Express API (Render) → Supabase (PostgreSQL + Auth)

This was deliberate. Calling Supabase directly from the frontend would have required exposing an API key in client-side JS — and even with RLS, that creates a surface area I didn't want. The Express server holds the service role key in an environment variable, never exposed to the client. The server became the single security boundary.

The tradeoff is an extra network hop. For this use case, which is mostly read operations on a discovery tool, it was the right call.

The Security Model

Supabase's Row Level Security is enabled on all tables, but the server bypasses it using the service role key. This might seem backwards — why enable RLS if you bypass it? The answer is defence in depth. RLS is a safety net in case something is misconfigured at the server layer. The real gate is the Node.js/Express server, which hardcodes approval_status = 'approved' into every list query. No matter what query params the frontend sends, unapproved records are never reachable.

Layered Architecture

The backend was structured as a strict four-layer system:

Route → Controller → Service → Supabase SDK

A controller never touches the database. A service never touches req or res. This isn't just clean code preference — it makes each layer independently replaceable and testable. When a Supabase query needed changing, I touched only the service file. When a response format needed updating, only the controller.

Keeping the Free-Tier Server Alive

Render's free tier spins down after 15 minutes of inactivity — which would mean a 30-second cold start for the first user every morning. I set up a cron job to ping the meta endpoint every 15 minutes, keeping the instance warm. Small operational detail, significant user experience impact.

Building the Data Layer

The Filter-as-Query-Builder Pattern

Feature 3.1 and 3.3 both required multi-dimensional filtering. Rather than building raw SQL strings or a complex query DSL, I applied each filter conditionally to a Supabase query object:

let query = supabase
  .from('funding_opportunities')
  .select(FIELDS, { count: 'exact' })
  .eq('approval_status', 'approved'); // always applied — not a client param

if (search) query = query.or(`opportunity_title.ilike.%${search}%,...`);
if (sector) query = query.contains('sectors', [sector]);
if (country) query = query.eq('country', country);

{ count: 'exact' } returns the total row count alongside the data in a single query — no second round-trip needed for pagination metadata. Every list endpoint returns a consistent meta object: { page, limit, total, totalPages, hasNextPage, hasPrevPage }.

Feature 3.4 — Sector Taxonomy as a First-Class Design Decision

Sector classification isn't glamorous, but getting it wrong cascades into every filter in the system. I designed the taxonomy as enum slugs — agriculture_food, technology_digital, fashion_textiles — stored as arrays on each record. This meant one opportunity could span multiple sectors (a common real-world case), and filtering used Supabase's contains() operator against the array.

I also built a /meta endpoint that returns all enum values — opportunity types, sectors, stages, cost types, duration ranges — in a single call. Frontend components populate their dropdowns from this rather than having hardcoded option lists scattered across multiple files.

Consistent API Contract

Every endpoint — success or error — returns the same envelope shape:

{ "success": true, "message": "...", "data": [...], "meta": {} }

I documented every endpoint in endpoints.md with request/response examples. This wasn't just good practice — with 7 contributors building frontend integrations, a shared reference prevented mismatched field names and assumptions about response shapes from becoming bugs.

Building the Frontend Foundation for a Team of 7

Before features could be built, the frontend needed an architecture that 7 contributors could work within without constant coordination. I approached this in three layers: a component library, a module system, and a database schema that wouldn't break filtering.

The Component Library

Rather than leaving each contributor to build UI primitives from scratch — and ending up with 7 different button styles — I built a shared component library under client/shared/components/, each component following the same static factory pattern:

const btn = Button.create({ label: 'Apply now', variant: 'primary' });
container.appendChild(btn);

Every component has one public method, create(), that returns a DOM element. Internal rendering logic is hidden behind ES2022 private class fields (#buildClasses(), #buildHTML(), #attachEventListeners()). Contributors couldn't accidentally break internals — the only surface they ever touched was the public API.

The library covered:

Button — 4 variants (primary, secondary, outline, ghost), 3 sizes, icon support, renderable as <a> for link CTAs
Input — form input with validation states
Dropdown — custom styled select with keyboard dismissal, click-outside-to-close, and onChange callback
SearchBar — input + search button, fires onSearch on button click or Enter
Nav — self-mounting; drop <nav id="nav-root"> anywhere and import the script, it renders itself. Handles mobile hamburger menu, active link detection, and authenticated vs unauthenticated CTA states
Footer — same self-mounting pattern

Every component was documented in docs/components/ with a full API reference, usage examples, and instructions for extending it. The goal was that any contributor could pick up a component without asking me how it worked.

Migrating to ES Modules

Last sprint, every HTML page was loading 4–6 <script> tags in a specific order — api.js before auth.service.js before the page script, or things broke silently. With 7 contributors adding pages, this was a maintenance problem waiting to happen.

I migrated the entire client codebase to native ES modules. Every shared utility and component became an explicit import. Every page went from a stack of script tags to a single:

<script type="module" src="page.js"></script>

type="module" is automatically deferred — no load-order issues. ES modules are cached — auth.service.js imported by both nav.js and login.js evaluates only once. Contributors could add a component to their page with a single import line, without touching HTML at all.

A full migration plan was written in docs/setup/es-modules-migration.md before executing it — mapping every file that needed changes, every new import/export statement, and every HTML page that needed its script tags collapsed. The migration was executed as a single PR (#75) to avoid a partial state where some pages used modules and others didn't.

The Database Refactor That Made Filtering Possible

This was the most consequential piece of work in the sprint, and the least visible.

When wiring the filter queries, I discovered the database schema would break filtering by design. Categorical fields like sector and stage_eligibility were stored as free-text varchar — values like "Technology & Digital Services, Financial Services & Fintech" comma-separated in a single column. A standard .eq('sector', 'technology_digital') would never match.

The schema was refactored from scratch:

PostgreSQL enums for single-value categoricals (opportunity_type, status, format) — validation enforced at the database layer, not application code
text[] arrays for multi-value fields (sectors, stages) — a single opportunity can belong to multiple sectors, which is the real-world case
GIN indexes on every array column — PostgreSQL's @> operator with a GIN index turns a multi-sector filter into a fast indexed lookup
Lookup tables (sectors, stages) as the canonical source of display names, decoupled from the enum slugs used in queries

I chose text[] arrays over junction tables deliberately. Supabase's JS SDK maps .contains('sectors', ['technology_digital']) directly to PostgreSQL's @> — one line, no JOINs, no raw SQL. Junction tables would have required supabase.rpc() or nested filters that broke the existing service layer pattern.

The migration ran as 8 sequential scripts, each documented with rollback considerations. The data mapping exercise — converting "Grant-NGO" to grant_ngo, "Rolling Applications" to rolling_applications, fixing edge cases where values were stored without spaces after commas, took as long as writing the migration code itself.

The result: filtering just works. .contains('sectors', [sector]) against a GIN-indexed text[] column is both correct and fast.

Documentation as a Force Multiplier

With 7 contributors and little daily standup, documentation was how I kept the team unblocked. By the end of the sprint, the docs/ directory contained:

docs/components/ — full API reference for every shared component
docs/api/endpoints.md — every endpoint with request/response examples, all query params, all error codes
docs/setup/system-design-case-study.md — the full architectural rationale, for onboarding and for the team's own understanding of what they were building on
docs/setup/es-modules-migration.md — the migration plan before execution
docs/setup/db-refactor.md — the schema refactor with every migration script, data mapping, and verification query documented

A contributor building the training page filter section shouldn't need to ask me what the Dropdown API is, what query params the /trainings endpoint accepts, or what slug values are valid for programme_type. That information lived in the docs. The friction of building fell from "wait for the lead to answer" to "read the reference."

The Bug That Broke Everything After Login

Midway through the sprint, I caught a subtle but critical bug: the opportunities page would load correctly for unauthenticated users, but return an empty array immediately after login.

The root cause was a Supabase singleton contamination bug. The auth.service.js was calling signInWithPassword() on the shared service role client — the same singleton used for all database queries. Even with persistSession: false, the GoTrueClient stores the returned user JWT in memory as currentSession. Every subsequent database query then sent Authorization: Bearer <user_jwt> instead of the service role key, making PostgREST apply RLS. Since there's no permissive RLS policy for the authenticated role, queries returned empty.

The fix was architectural: a separate Supabase client initialised with the anon key, used exclusively for user-facing auth operations. The service role singleton is never touched by auth flows.

// auth.service.js — separate client, never shared
const authClient = createClient(supabaseUrl, supabaseAnonKey, {
  auth: { autoRefreshToken: false, persistSession: false },
});

This is the kind of bug that's invisible in testing and devastating in production, because it only manifests after a user successfully logs in.

Orchestrating the Team

Breaking Features into Issues

I decomposed each feature into discrete GitHub issues with explicit acceptance criteria and assigned them across the team. The filter section for opportunities, the training page UI, the login wiring, the signup wiring, the navbar auth state — each became a separate issue with clear inputs and outputs.

Some contributors didn't complete their assignments before the sprint deadline. Rather than letting work stall, I reassigned and in several cases picked up the work myself.

PR Reviews — Holding the Bar

I reviewed every PR that touched the three core features. Two patterns emerged in reviews that I pushed back on consistently:

PR #63 — Signup wiring: Requested changes before approval. The initial implementation had issues with how the auth flow was handling the response from the server — needed corrections before merge.

PR #66 — Training & Resources filter section: Requested changes before approval. The initial UI wiring wasn't aligned with the component API established.

On both, the aim was on consistency with the patterns the rest of the codebase had already established. Inconsistency at the integration layer is what creates bugs that take hours to trace.

Wiring the Frontend to the API

Once the backend was live, I oversaw the integration work. Two issues surfaced during review:

Shared utilities extracted to prevent duplication. Both pages needed the same date formatting and amount scaling logic. Rather than letting each page carry its own copy, I extracted formatAmount, formatDate, daysUntil, humanize, and buildQueryString into a shared opportunity.utils.js module — imported by both the listing and detail pages.

Intl.NumberFormat memoization. The original amount formatter was constructing a new Intl.NumberFormat instance on every card render. On a listing page with 20 results, that's 40 expensive constructor calls per page load. I added a Map-based cache keyed by currency code, one construction per currency, reused on every subsequent call.

What Shipped

By end of sprint:

A live Express API on Render serving Features 3.1 and 3.3, with full filter support, pagination, and a consistent response contract
An opportunity detail page with full listing data, deadline countdown, sector/stage tags, and an apply CTA
Filter and search wired end-to-end on both the opportunities and resources pages
A shared sector taxonomy (Feature 3.4) implemented as enum slugs across the database, API, and frontend filter components
A /meta endpoint returning all filter enum values for dynamic dropdown population
Auth flow (signup, login, logout) wired across the frontend, with a critical singleton bug patched in the backend
PRs reviewed, 2 with requested changes before merge
Endpoint documentation and system design case study written for the team

What I'd Do Differently

The filter state on both pages is duplicated — the same filters object shape, the same onFilterChange pattern, the same buildQueryString call. With more time I would extract a shared FilteredPage module that both pages compose from, rather than each carrying their own copy of the pattern. It works now. It will diverge later.

The /meta endpoint also isn't being consumed by the frontend yet — filter options are still hardcoded in the JS files. The infrastructure is there; it just needs to be wired in.

Closing Thought

The most important thing I did this sprint wasn't writing code, it was actually making decisions early enough that the team could move in parallel without stepping on each other. The layered backend architecture, the response envelope, the sector taxonomy, the component API — these were the guardrails that let 7 people build towards the same system without needing a daily sync to stay aligned.

Engineering leadership at this scale is mostly about removing ambiguity before it becomes a bug.

How We Built Ekehi: Engineering a Women's Business Intelligence Platform in One Sprint

AJ — Sat, 07 Mar 2026 09:18:03 +0000

I want to tell you about one of the most satisfying weeks I've had as an engineer.

Okay, maybe the title was click bait, since we only built the landing page, but it is still a platform, nevertheless.

Twelve contributors. Three tracks. One sprint. Zero frameworks. A fully structured, token-based, responsive landing page — shipped for International Women's Day 2026.

This is the engineering story of Ekehi — what we built, how we coordinated it across three tracks (frontend, UI/UX, and backend), the architectural decisions I made as Engineering Lead, and what I learned from running a synchronised multi-track team build at this pace.

What Is Ekehi?

Ekehi is a business intelligence platform built for women entrepreneurs and women-led SMEs across Nigeria and Africa. It aggregates funding opportunities — grants, VCs, loans, government schemes, accelerators — alongside training programmes, mentorship networks, and business resources into a single searchable, filterable hub.

The platform was created as part of the Tabî Project by TEE Foundation for International Women's Day 2026.

The problem it solves is real: women-owned businesses across Africa experience what researchers call a "triple penalty" — limited access to capital, fewer connections to formal business networks, and low visibility in male-dominated investment ecosystems. When funding opportunities do exist, most women never hear about them. Ekehi fixes the information gap.

The tech stack:

Layer	Technology
Frontend	HTML, CSS, Vanilla JavaScript
Backend	Node.js + Express
Database	Supabase (PostgreSQL)
Auth	Supaash Auth + JWT
Hosting	Netlify (frontend), Railway (backend)

No React. No Vue. No build step. Deliberate choices — all of them.

The Team

Ekehi was built across three tracks working in parallel.

Frontend Track

Contributor	GitHub
AJ (Engineering Lead)	@AJ1732
Marion Braide	@MarionBraide
Florence	@Florence-code-hub
Okwuosa Oluchi	@luchiiii
Victor Okoukoni	@Okoukoni-Victor
Esther Orieji	@first-afk
Pheonixai	@Pheonixai

UI/UX Track

Contributor
Michael Babajide Boluwatife
Fisayo Rotibi
Osuji Wisdom

Backend Track

Contributor
Olusegun Adeleke
Sodiq Semiu

Contributor
Gabriel Abubakar

The frontend sprint described in this article ran concurrently with the UI/UX team producing the Figma designs and the backend team architecting the API and database layer. Everything you see on the landing page was built directly from those Figma deliverables — not interpreted, not approximated. Pixel-faithful implementation was the standard.

My Role: Engineering Lead

I wore a lot of hats on this project. Before a single line of product code was written, my job was to ensure every contributor could move fast, independently, and without stepping on each other.

That meant three things: architecture, tooling, and issue writing.

1. Monorepo Architecture (PR #2)

The first thing I merged was the project skeleton — before anyone else had touched index.html.

Ekehi/
├── client/
│   ├── pages/          # HTML files
│   ├── css/
│   │   ├── base/       # Reset, tokens, typography
│   │   ├── components/ # Reusable component styles
│   │   └── pages/      # Page-level styles
│   ├── js/
│   │   ├── api/        # Fetch wrappers
│   │   ├── components/ # UI interaction logic
│   │   ├── pages/      # Page entry scripts
│   │   └── utils/      # Shared helpers
│   └── assets/
└── server/
    └── src/            # MVC: routes, controllers, models, middleware, services

I also added the full contributor tooling before any work started:

CONTRIBUTING.md covering both frontend and backend workflows
Three GitHub issue templates (Bug Report, Feature Request, Task)
A PR template enforcing screenshots, linked issues, and a consistent checklist
.gitignore covering .env and node_modules
server/.env.example documenting every required environment variable

The principle here is simple: a team that can't onboard fast, can't ship fast. Every hour saved on "where does this file go?" is an hour spent building.

2. The Design System (PRs #26 + #31)

This is the work I'm most proud of on this project.

Before the team styled a single element, I converted the Figma design system into a complete CSS-native token system — no Sass, no PostCSS, no JS-in-CSS. Pure custom properties.

:root {
  /* Color primitives */
  --color-purple-800: #4c0066;
  --color-purple-600: #9900cc;
  --color-neutral-950: #131213;

  /* Semantic aliases */
  --color-primary:          var(--color-purple-800);
  --color-primary-hover:    var(--color-purple-600);
  --color-text-on-primary:  var(--color-white);
  --color-bg-base:          var(--color-white);

  /* Type scale */
  --font-size-base: 1rem;
  --text-xs:   calc(var(--font-size-base) * 0.75);   /* 12px */
  --text-sm:   calc(var(--font-size-base) * 0.875);  /* 14px */
  --text-base: var(--font-size-base);                /* 16px */
  --text-5xl:  calc(var(--font-size-base) * 3);      /* 48px */

  /* Spacing */
  --spacing: 0.25rem;
  --space-4:  calc(var(--spacing) * 4);   /* 16px */
  --space-8:  calc(var(--spacing) * 8);   /* 32px */
  --space-16: calc(var(--spacing) * 16);  /* 64px */
}

Two layers — primitives and semantic aliases. The primitives (--color-purple-800) give you the raw value. The aliases (--color-primary) give you the intent. This separation means you can retheme the entire product by changing three or four semantic aliases without touching a single component.

The rule I enforced for every contributor: no hardcoded values, anywhere. No #4c0066 in a component file. No font-family: 'Urbanist' in a section stylesheet. Every value references a token.

I also built the button component — the first real piece of UI. It uses local CSS custom properties to create a self-contained state machine:

.btn {
  --btn-bg:           transparent;
  --btn-color:        var(--color-text-primary);
  --btn-bg-hover:     transparent;
  --btn-color-hover:  var(--color-text-primary);

  background-color: var(--btn-bg);
  color:            var(--btn-color);
  transition: background-color 150ms ease, color 150ms ease;
}

.btn:hover {
  background-color: var(--btn-bg-hover);
  color:            var(--btn-color-hover);
}

.btn--primary {
  --btn-bg:           var(--color-primary);
  --btn-color:        var(--color-white);
  --btn-bg-hover:     var(--color-primary-hover);
  --btn-color-hover:  var(--color-white);
}

The modifier (--primary) only sets local properties. It never writes background-color or color directly. The base .btn rule is the only rule that does. This means specificity stays flat — modifiers can't fight each other.

One file per section was the other structural decision I made in PR #31. Every BEM block lives in its own scoped file:

css/pages/landing/
├── nav.css
├── hero.css
├── about.css
├── value-proposition.css
├── mission.css
├── what-we-offer.css
├── cta.css
└── footer.css

landing.css imports them in document order. The result: six developers styling six different sections simultaneously with zero merge conflicts on CSS files.

3. Issue Writing as Engineering Work

This part often goes undocumented. I want to talk about it.

Every issue I wrote before the sprint started had:

A screenshot from Figma showing exactly what to build
A full content specification (copy, heading levels, BEM class names)
An explicit list of dependencies (which issue must merge first)
A numbered acceptance criteria checklist
Implementation notes covering tricky edge cases

Here is an excerpt from the mobile nav toggle issue (#38):

On outside click:
If the menu is open and the user clicks anywhere outside .nav__inner, close the menu and reset all states.

On window resize:
If the viewport width exceeds the mobile breakpoint and the menu is open, close the menu and reset all states (prevents a stuck-open menu if the user resizes from mobile to desktop).

Implementation Notes:
Use aria-expanded as the single source of truth for open/closed state. Mobile breakpoint for the resize listener should match the CSS breakpoint — extract it as a named constant at the top of the script (const MOBILE_BREAKPOINT = 768).

That's not a vague ticket — it's a spec. The developer assigned to it, @MarionBraide, shipped the implementation in a single PR with every acceptance criterion met.

Well-written issues are one of the highest-leverage activities an engineering lead can do. They eliminate back-and-forth, reduce PR revision cycles, and let contributors focus on writing code instead of inferring intent.

4. Contributors Page (PR #44)

My final individual contribution was the contributors page — HTML structure, JavaScript renderer, and full CSS.

The architectural choice I want to highlight here is the JS rendering approach:

const contributors = [
  {
    name: "AJ",
    role: "Engineering Lead",
    image: "../assets/images/contributors/aj.jpg",
    imageStyle: { objectPosition: "top center" }
  },
  // ...
];

function renderContributors(data, containerId) {
  const container = document.getElementById(containerId);
  if (!container) return;

  const fragment = document.createDocumentFragment();

  data.forEach((contributor, index) => {
    const card = document.createElement("article");
    card.className = "contributor-card";
    card.dataset.variant = String((index % 5) + 1);
    // ...build card elements...
    fragment.appendChild(card);
  });

  container.appendChild(fragment);
}

document.addEventListener("DOMContentLoaded", () => {
  renderContributors(contributors, "contributors-grid");
});

Three things worth noting:

DocumentFragment batches DOM writes — one reflow instead of N. For a grid of cards, this matters.
createElement over innerHTML — XSS-safe by construction. No string interpolation, no injection surface.
Adding a contributor requires only a new data entry — no HTML changes, no render function edits. The imageStyle field lets each contributor's photo be positioned correctly without touching CSS.

How We Coordinated Seven People in One Sprint

The team was fully distributed. We had no standup calls during the build phase. What we had instead was process.

GitHub Issues as the Source of Truth

Every task existed as a GitHub Issue before work started. Contributors picked up issues, created branches named after them, and opened PRs that closed the linked issue with Closes #N. This kept the board clean and made progress visible in real time.

Dual Workflow: ClickUp + GitHub

Internal contributors tracked tasks in ClickUp (moving cards from In Progress to Done as PRs merged). External contributors worked entirely through GitHub Issues. Both systems pointed at the same work, so nothing fell through the gap.

PR Template Enforcement

Every PR had to include:

A description of what changed and why
Screenshots for any UI change
Closes #N linking the issue
A checklist: branch up to date, no .env committed, mobile tested

PRs without all of this were held for revision. This sounds strict — and it is. It also means I never had to ask "what does this PR do?" when reviewing.

Branching Strategy

main
└── development  ← all PRs target here
    ├── feature/*
    ├── fix/*
    └── chore/*

No one committed to main or development directly. Every piece of work lived on a branch. This protected the integration branch and meant we could always roll back a section without touching others.

What the Team Shipped

In the order they merged:

#	PR	Contributor
#2	Monorepo architecture + contributor tooling	@aj1732
#26	Design system — CSS tokens + utilities	@aj1732
#31	Button component + section CSS scaffold	@aj1732
#15	About section HTML	@Florence-code-hub
#17	Navigation HTML	@MarionBraide
#19	Footer HTML	@Pheonixai
#20	Mission section HTML	@luchiiii
#23	What We Offer section HTML	@MarionBraide
#24	Value Proposition section HTML	@Okoukoni-Victor
#32	CTA section HTML	@Florence-code-hub
#34	Hero section HTML	@first-afk
#35	Mission eyebrow image assets	@luchiiii
#36	Navigation CSS	@MarionBraide
#37	About section CSS	@Florence-code-hub
#39	What We Offer section CSS	@MarionBraide
#40	Hero section CSS	@first-afk
#42	Value Proposition section CSS	@Okoukoni-Victor
#43	Mobile navigation toggle JS	@MarionBraide
#44	Contributors page (HTML + JS + CSS)	@aj1732

Lessons Learned

1. The architecture investment pays back immediately

I spent the first hours of the sprint on things that produced no visible UI — folder structure, token system, CSS architecture, issue templates. Every hour I spent there saved the team two. When six people are styling six sections simultaneously, they are not stepping on each other because of architecture decisions made before they wrote their first rule.

If you're leading a multi-contributor frontend project: set up the system before you invite contributors in.

2. Issue quality is a force multiplier

The difference between "style the navigation" and a four-paragraph spec with Figma screenshots, BEM class names, acceptance criteria, and implementation notes is the difference between three revision cycles and one. Your time writing the issue is paid back in review time saved.

3. CSS custom properties are a full design system

I did not reach for Sass. I did not reach for Tailwind. CSS custom properties with a thoughtful primitive/semantic layer give you everything you need for a design system — theming, inheritance, component-level overrides, responsive tokens — in native CSS. The DX is excellent once contributors understand the naming convention.

4. Vanilla JS is underrated for constrained scopes

The contributors page renderer, the mobile nav toggle, the offerings tab interaction — all written in plain JavaScript. No bundler, no framework, no dependency to maintain. The frontend opens directly in a browser. The bundle size is zero because there is no bundle. For a project at this stage, that is the right call.

5. One file per section is not over-engineering

It sounds like premature organisation. It isn't. When you have seven contributors and eight CSS sections, one file per section means eight people can make CSS changes in the same branch with zero merge conflicts. The cost is eight @import lines in landing.css. That's a good trade.

What's Next for Ekehi

The landing page sprint was phase one. What comes next:

Mission and CTA section CSS — two open issues being finished by the frontend track
Backend API — Olusegun and Sodiq are building the Express + Supabase layer for the funding opportunity database
Search and filter — full-text search with sector, stage, location, and funding size filters
Opportunity submission system — funder-facing form with an admin review workflow
Authentication — Supabase Auth + JWT for registered users
QA integration — Gabriel's QA process formalised as acceptance test criteria against each API endpoint and UI flow

The codebase is open source. If you're a developer who wants to contribute to a project with real-world impact for women entrepreneurs across Africa — the issues are open, the CONTRIBUTING.md is thorough, and the bar for a good PR is clearly documented.

GitHub: github.com/Tabi-Project/Ekehi

Shoutout to the Team

None of this ships without every one of these people.

Frontend Track

@MarionBraide — Navigation HTML and CSS, What We Offer section, mobile nav JavaScript. Marion owns the most technically complex section on the page and delivered a clean, accessible, BEM-compliant implementation with a working JS interaction layer across four separate PRs.
@Florence-code-hub — About section HTML and CSS, CTA section HTML. Florence nailed the mixed serif/sans heading treatment that gives Ekehi its distinct visual identity.
@luchiiii (Okwuosa Oluchi) — Mission section HTML and the SVG decoration assets for the mission eyebrow. Oluchi also spotted and fixed missing <img> tags in a follow-up PR — exactly the attention to detail that keeps a shared codebase clean.
@Okoukoni-Victor (Victor Okoukoni) — Value Proposition section, HTML structure and CSS. Victor's responsive two-column layout with the visual block and caption section was clean from the first commit.
@first-afk (Esther Orieji) — Hero section HTML and CSS. Esther set the visual tone of the page with the wide-aspect hero display block that grounds the entire landing page.
@Pheonixai — Footer HTML. The footer is one of the most content-dense sections on the page — three navigation groups, a brand block, and a legal bottom bar — structured cleanly in a single PR.

UI/UX Track

The frontend sprint could only move at the speed it did because the designs were ready. Every section that got built had a Figma frame to implement against — with precise layout specs, color tokens, type scales, and component states defined before a single HTML file was touched.

Michael Babajide Boluwatife — Core product design and design system foundation. The purple scale, the serif/sans heading pairing, the token naming convention — these design decisions shaped the CSS architecture built.
Fisayo Rotibi — Component and section design. Fisayo's contributor card designs directly informed the card rendering system, including the five SVG background variants and the per-card image positioning approach.

Working from a well-produced Figma file is a gift to a frontend engineer. You're not guessing. You're translating.

Backend Track

While the frontend sprint was running, the backend team was laying the foundation for what Ekehi will become once the product goes live.

Olusegun Adeleke — API architecture and database schema design. The Express MVC structure I scaffolded (routes → controllers → models → services) was designed to directly receive Olusegun's implementations.
Sodiq Semiu — Backend development and Supabase integration. The server/.env.example I included in the initial monorepo commit documents the Supabase keys and connection strings that Sodiq's work depends on.

The separation of client/ and server/ in the monorepo was intentional — frontend and backend contributors never needed to be in each other's directories. Both tracks moved independently on the same codebase.

QA

Gabriel Abubakar — Quality assurance. Gabriel was the safety net across all three tracks — verifying that implementations matched the design specs, that mobile breakpoints held, and that interactions behaved as the issues defined. QA on a multi-track team is often underacknowledged. Without it, bugs that feel "done" in development show up in production.

This project matters. Women entrepreneurs in Africa are funding their businesses with imperfect information, or no information at all. Ekehi is a small piece of the solution to that — and it was built by a team of developers who showed up, picked up issues, and shipped.

That's the kind of work worth documenting.

Built for International Women's Day 2026 as part of the Tabî Project by TEE Foundation.
Open source — contributions welcome.

Forem: AJ

Building Ekehi — Week 4: Admin Tools, Profile Images, Submissions, and Closing the Loop

Where We Left Off

What I Personally Shipped

1. Profile Image Upload — Backend (PR #114)

2. Profile Image Upload — Frontend (PR #130)

3. Admin Content Management — Full Lifecycle (PR #136)

4. RBAC Implementation (Issue #120)

5. Submissions Page, Resources Wiring, and Clean Code (PR #136)

What I Coordinated as Engineering Lead

Technical Decisions and Why

Bugs I Encountered and Fixed

Admin dashboard showing empty — data?.items vs data

Guide TOC scrolling to wrong section

Multer field name mismatch

Guide cards rendering with no description text

Sprint Reflections

What I'm Most Proud Of

Team

Ekehi Engineering Sprint 3 — Detail Pages, Save States, and Leading a Sprint

Previously on Ekehi Engineering — What We're Building

What I Personally Shipped

1. Fixed the Broken Filter and Search Wiring (PR #83)

2. Structural Backend and Client Updates (PR #97)

3. Opportunity Detail Page Redesign + Save Feature (PR #111)

Technical Decisions and Why

Bugs I Encountered and Fixed

Modal appearing in the top-left corner

Modal closing when clicking inside the content

is_saved always returning false

Saved tab count always showing zero on page load

What I Coordinated as Engineering Lead

Sprint Reflections

What I'm Most Proud Of

Team

Closing Thought

Ekehi Engineering Sprint 2 — Building the Ekehi Resource Discovery Engine

Context

Designing the Architecture First

The Security Model

Layered Architecture

Keeping the Free-Tier Server Alive

Building the Data Layer

The Filter-as-Query-Builder Pattern

Feature 3.4 — Sector Taxonomy as a First-Class Design Decision

Consistent API Contract

Building the Frontend Foundation for a Team of 7

The Component Library

Migrating to ES Modules

The Database Refactor That Made Filtering Possible

Documentation as a Force Multiplier

The Bug That Broke Everything After Login

Orchestrating the Team

Breaking Features into Issues

PR Reviews — Holding the Bar

Wiring the Frontend to the API

What Shipped

What I'd Do Differently

Closing Thought

How We Built Ekehi: Engineering a Women's Business Intelligence Platform in One Sprint

What Is Ekehi?

The Team

My Role: Engineering Lead

1. Monorepo Architecture (PR #2)

2. The Design System (PRs #26 + #31)

3. Issue Writing as Engineering Work

4. Contributors Page (PR #44)

How We Coordinated Seven People in One Sprint

GitHub Issues as the Source of Truth

Dual Workflow: ClickUp + GitHub

PR Template Enforcement

Branching Strategy

What the Team Shipped

Lessons Learned

1. The architecture investment pays back immediately

2. Issue quality is a force multiplier

3. CSS custom properties are a full design system

4. Vanilla JS is underrated for constrained scopes

5. One file per section is not over-engineering

What's Next for Ekehi

Admin dashboard showing empty — `data?.items` vs `data`

`is_saved` always returning `false`