BuildBridge
Community-Funding Platform
Engineering the guardrails behind a community-funding platform for Nigeria's informal economy.
Economic dignity for people
locked out of every system.
Mechanics, tailors, and artisans across Nigeria run on tight margins with no financial safety net. When a tool breaks or a storefront needs repair, their options are bad ones: predatory loan apps with crushing interest or global crowdfunding platforms like GoFundMe that were never built for low-digital-literacy users or Nigerian payment rails.
BuildBridge set out to close that gap: a community-vouched micro-funding platform where people fund each other's small, specific needs instead of going into debt for them. The mission wasn't just “build a crowdfunding app.” It was economic dignity for people locked out of every existing system.
I joined as the team's product designer and design engineer, responsible for turning a stalled, fractured codebase into a shipped, production-ready MVP.
Show the gap BuildBridge fills
Strong design direction.
Missing engineering layer.
By the time I stepped in, the team had already done the hard upstream work together: user research, problem definition, design direction, and a complete design system in Figma. BuildBridge wasn't a vague idea; it was a validated direction with real design tokens, typography, and component logic behind it. My role was the next phase: take that handoff and engineer it into a real, shippable product.
That's where the cracks showed up:
The team had started using AI coding agents to move faster, but without any context guardrails, the agents had no reliable way to "know" the design system. They drifted completely from the Figma source of truth, hardcoding hex values, ignoring design tokens, and breaking navigation.
The interface was rendering in default Roboto instead of the Poppins/Inter pairing the design system actually specified.
The design direction was strong. What was missing was the engineering layer that could translate it faithfully, especially once AI agents were doing a meaningful share of the coding. That's the gap I closed.
Figma design vs actual rendered output before context files
Four moves that
shipped the product.
1. Built the context-engineering foundation
The core problem wasn't a missing Git command; it was that our AI coding agents had no reliable way to “know” the design system, so they hallucinated their own version of it. The fix was building a structured set of context files (agents.md, colors.md, forms.md, architecture.md) that the agents were required to read and comply with before generating any code at all. No compliance plan against the spec, no code output.
This is the same principle behind how serious AI-assisted engineering actually works: an agent is only as reliable as the context it's grounded in. I treated those context files as real infrastructure — not documentation on the side, but the thing that made the design system enforceable at the code level.
I then wrote this up as a reusable engineering guide (skill-files.md) so the rest of the team could apply the same pattern going forward, turning a one-off fix into a repeatable system the whole team could build on.
agents.md, colors.md, forms.md, architecture.md → AI Agent → Consistent Output
2. Redesigned onboarding for a low-literacy user base
Our users are highly sensitive to long, complex forms — a dense signup flow would have meant losing them before they ever reached the product. I re-architected the onboarding journey end-to-end, deliberately deferring non-essential setup out of the initial flow and into a contextual “Add Needs” step later in the experience:
This kept the first-time session lightweight while still collecting everything the platform needed — just later, when it had context and lower cognitive cost.
8 steps reduced to 3 steps
3. Kept the team shipping through a live infrastructure failure
Days before the demo, our SMS provider network went down, taking phone verification with it. I made the call to pivot to an OAuth/email fallback and designed an environment-controlled “demo mode” that simulated real API and dashboard states without depending on live infrastructure — so the demo ran flawlessly on schedule.
Once the demo was over, I worked with the team to dismantle the mock layer and route real phone verification through Supabase's backend, so what stakeholders saw in the room matched what shipped to production.
SMS down → OAuth fallback → Demo mode → Production fix
4. Took the MVP from staging to production
I owned key parts of the final mile of shipping:
- Purchased and configured the domain (buildbridge.ng), resolving registrar issues and routing DNS through Vercel's edge network
- Worked with the team to translate the brand system into a launch-ready social and marketing rollout
Measurable results
in six weeks.
Guardrails, not just pixels.
Context, not just code.
I build the guardrails, not just the pixels.
An unconstrained AI-assisted engineering pipeline will quietly destroy a design system. I don't just catch that after the fact; I build the structural constraints that prevent it from happening again, and I document the pattern so the team can reuse it.
Design decisions are driven by who's actually using the product.
I restructured the onboarding architecture specifically because low-literacy artisans abandon dense forms — not because it looked cleaner in Figma.
I stay calm and ship when things break.
When the SMS provider failed days before a stakeholder demo, the response wasn't to delay; it was to engineer a fallback that protected the deadline without compromising what shipped afterwards.
Built by
12 people, shipped by all.
| Name | Role | Contact |
|---|---|---|
| Cephas Osayi | Product Designer / Design Engineer | [ADD LINKEDIN] |
| Ikechukwu Chinaz | Product / Git Lead | [ADD LINKEDIN] |
| Haye Binjo Emmanuel | Backend / Auth Engineer | [ADD LINKEDIN] |
Guardrails. Context.
Shipped.
Context engineering. Onboarding architecture. Infrastructure resilience. Production shipping. All in six weeks with a 12-person team.