DEV Community: Okeke Chukwudubem

AccessBuild is done. From discovering that 100% of Nigerian banking apps are inaccessible to blind users to a live API, a public dashboard, and a full audit pipeline. Here's the complete journey and the roadmap to scale.

Okeke Chukwudubem — Mon, 12 Oct 2026 16:47:08 +0000

Okeke Chukwudubem

Oct 12

AccessBuild Is Done. Here's the Full Journey and What Comes Next.

#ai #webdev #programming #productivity

3 min read

AccessBuild Is Done. Here's the Full Journey and What Comes Next.

Okeke Chukwudubem — Mon, 12 Oct 2026 16:46:20 +0000

From one discovery to a live API, a public dashboard, and a plan for scale. Everything we built, and the roadmap to finish.

AccessBuild started with a simple observation: my Phone Agent couldn't use banking apps.

Not because the agent was broken. Because the apps had zero accessibility labels. No content descriptions. No screen reader support. The same reason millions of visually impaired Nigerians can't use them either.

I tested 30 apps. 100% of banking apps scored F. 100% of government apps scored F. Global apps like WhatsApp and Google Maps scored A.

That discovery became a project. Today, AccessBuild is built. And we're ready for the next phase.

What AccessBuild Is

An AI-powered accessibility audit tool that scans mobile apps, checks whether interactive elements have proper accessibility labels, and scores them from A to F.

A: 90%+ labeled. Fully accessible.
B: 70-89% labeled. Mostly accessible.
C: 50-69% labeled. Needs work.
D: 25-49% labeled. Mostly inaccessible.
F: Below 25% labeled. Completely inaccessible.

The API is live. The dashboard is live. Every audit saves to Supabase. The scoring engine works.

What We Built (Day by Day)

Day	What Shipped
Day 1	FastAPI backend, `/audit` endpoint, A-F scoring engine, deployed on Render
Day 2	Supabase integration, `/scan` endpoint for Android UI tree XML, `/stats` and `/audits/recent` endpoints
Day 3	Public dashboard showing all audited apps, scores, and recommendations
Day 4	Phone Agent bridge connecting real-time UI dumps to AccessBuild

The pipeline is now fully automatic: Phone Agent dumps the UI tree from any screen, AccessBuild parses it, scores it, and saves it to the database.

The Stack

Backend: FastAPI (Python)
Database: Supabase (PostgreSQL)
AI: Google Gemini
Hosting: Render (free tier)
Dashboard: HTML/CSS/JS
Parsing: Android UI Automator XML

What We Proved

Metric	Result
Apps audited	30+
Banking apps scoring F	100%
Government apps scoring F	100%
Global apps scoring A	100% (WhatsApp, Google Maps)
API response time	Under 2 seconds

Why This Matters

Over 1 billion people globally have some form of disability. In Nigeria alone, millions of visually impaired users are locked out of banking, government services, healthcare, and telecom apps.

The same neglect that locks out blind users also locks out AI agents. Accessibility is not a feature. It is infrastructure.

The Roadmap to the Final Goal

The goal: make African apps accessible to everyone. Here is how we get there.

Phase 1: Data Collection (Now)

Scan 100+ Nigerian apps across banking, government, telecom, health, and education
Build the first public accessibility score database for Africa
Publish findings as open data

Phase 2: Awareness (Next)

Reach out to journalists and regulators with the data
Partner with disability advocacy groups
Pressure banks and government agencies to fix their apps

Phase 3: Developer Tools (With Funding)

Build a self-serve audit portal where developers submit their app and get a report
Add fix recommendations with code snippets
Create a public scoreboard with rankings by industry

Phase 4: Compliance & Certification (Scale)

Partner with regulators to make accessibility scores mandatory
Offer certification for apps that pass
Provide ongoing monitoring for enterprises

Phase 5: Continental Expansion

Expand to Ghana, Kenya, South Africa, and beyond
Become the standard for accessibility auditing across Africa

What We Need

AccessBuild is built and working. To move from prototype to scale, we need:

Grant funding to support full-time development
Partnerships with disability advocacy groups and regulators
Visibility through media and developer communities

Until funding arrives, we continue scanning apps, publishing data, and building in public.

The Repo

👉 github.com/Dexter2344/accessbuild-api

The API

👉 accessbuild-api.onrender.com

The Dashboard

👉 accessbuild-api.onrender.com/dashboard

AccessBuild is done for now. The foundation is solid. The data is real. The mission is clear.

When funding comes, we scale. Until then, we keep building.

Day 3 of AccessBuild: Auto-scanning is live. The API now parses real Android UI trees, scores them A-F, and saves every audit to Supabase. First real scan: a test banking login scored D 40% accessible. Full build log on Dev.to.

Okeke Chukwudubem — Tue, 06 Oct 2026 12:54:06 +0000

Okeke Chukwudubem

Oct 6

AccessBuild Day 3: Auto-Scanning Is Live. Here's What I Learned.

#ai #programming #productivity #python

2 min read

AccessBuild Day 3: Auto-Scanning Is Live. Here's What I Learned.

Okeke Chukwudubem — Tue, 06 Oct 2026 12:53:16 +0000

Day 3 of AccessBuild. The API is no longer just a calculator. It has a memory now.

What I Built Today

Yesterday, the API could only score elements you pasted in manually. Today, it parses real Android UI tree XML, extracts every interactive element, scores it, and saves the result to Supabase.

The new /scan endpoint accepts a raw UI tree dump. It walks through every node, classifies each element as button/input/icon/link, checks for accessibility labels, and returns a grade from A to F. Then it writes the audit to the database.

The Stack Grew Up

Day 1	Day 3
FastAPI	FastAPI
In-memory only	Supabase PostgreSQL
Manual element list	Android UI tree XML
One-off test	Persistent, repeatable audits
No history	`/audits/recent` endpoint
No stats	`/stats` endpoint

The First Real Scan

I ran the first auto-scan on a test banking login screen. Five interactive elements. Only two had labels.

Result: D — 40% accessible

Recommendation: "Urgent. Most elements are invisible to screen readers. Immediate fixes required."

That's the point. A real banking app with that score would be unusable by blind customers. And now the audit is saved in the database for future reference.

What Broke

The fix: update the start command to use $PORT, create the missing files, clear the build cache, and redeploy. Three hours of debugging. Ten minutes of actual feature work.

What Works Now

/scan — Auto-scan from Android UI tree XML
/stats — Aggregate statistics from Supabase
/audits/recent — Recent audit history
Supabase persistence — Every audit saved
Full pipeline: request → parse → score → save → respond

What's Next (Day 4)

Build a public dashboard showing audited apps and scores
Connect real app scanning to my Phone Agent's UI tree output
Start scanning Nigerian banking apps for real

The Repo

👉 github.com/Dexter2344/accessbuild-api

Day 3 is done. The API has a memory now.

— Dexter

One codebase. Two products. AccessBuild and AgriMind share the same FastAPI + Supabase + Gemini architecture. Built the foundation once, applied it twice. AgriMind backend is live. Meta sandbox is the only blocker.

Okeke Chukwudubem — Fri, 02 Oct 2026 11:12:08 +0000

Okeke Chukwudubem

Oct 2

One Codebase. Two Products. Here's How I Built Both at Once.

#ai #webdev #productivity #programming

2 min read

One Codebase. Two Products. Here's How I Built Both at Once.

Okeke Chukwudubem — Fri, 02 Oct 2026 11:11:36 +0000

AccessBuild taught me the pattern. AgriMind is applying it. Both are live.

If you've been following my build logs, you know the rhythm.

I was deep into AccessBuild—an AI-powered accessibility audit tool that scores mobile apps from A to F. Day 2 shipped: Supabase integration, UI tree parsing, auto-scanning. The API was live. The scoring engine worked.

Then I paused it.

Not because it failed. Because I saw the pattern.

The Pattern

AccessBuild and AgriMind share the exact same architecture:

FastAPI backend
Supabase database
Google Gemini AI
Render hosting
API-first design

Every line of code I wrote for AccessBuild's backend was directly reusable for AgriMind. So instead of finishing one and starting the other from scratch, I built the shared foundation once and applied it to both.

What AgriMind Is

AgriMind is an AI-powered farm advisor on WhatsApp. Farmers send text or photos of sick crops and livestock. The AI replies with diagnosis and treatment advice in their own language.

Free for 3 questions. ₦8,000/month for unlimited.

The goal: instant expert advice for farmers anywhere in the world. No app. No internet beyond WhatsApp. Just a conversation.

What I Built

Component	Status
FastAPI backend	✅ Live on Render
Supabase database	✅ Connected
Gemini AI brain	✅ Integrated
Paystack payment logic	✅ Built
Meta WhatsApp webhook	✅ Verified
Messages subscription	✅ Active

The backend is live at: agrimind-api-xm7p.onrender.com

The Shared Stack

Component	AccessBuild	AgriMind
Backend	FastAPI	FastAPI
Database	Supabase	Supabase
AI	Gemini	Gemini
Hosting	Render	Render
API Design	REST	REST

Same bones. Different problems.

The Wall I Hit

Meta's test number. It works differently than expected:

You can't just message it like a contact
You must receive a template first, then reply to that template
Only then does the 24-hour conversation window open

I'm still debugging this. The backend is ready. The AI is ready. The only blocker is Meta's sandbox restrictions.

What's Next

Get the Meta test flow working end-to-end
Register a real WhatsApp Business number
Complete Meta business verification
Launch AgriMind with real farmers
Return to AccessBuild with the same infrastructure

Why I'm Sharing This

Because this is what real building looks like. You pause one thing to finish another. You hit walls that have nothing to do with your code. You keep going.

AccessBuild will be finished. AgriMind is almost there. Both share the same bones.

That's the advantage of building systems, not just projects.

Dexter

AccessBuild Day 2: From Manual Testing to Real App Scanning

Okeke Chukwudubem — Thu, 24 Sep 2026 14:58:21 +0000

Added Supabase. Added auto-scanning. Parsed my first real Android UI tree. It scored D.

Day 2 of AccessBuild. I've been on this chair for hours.

What I Built Today

Yesterday, AccessBuild could only score elements you pasted in manually. Today, it can scan a real Android app.

The new /scan endpoint accepts a raw Android UI tree XML dump. It parses every node, identifies interactive elements, extracts accessibility labels, and scores the screen automatically. Then it saves the result to Supabase.

No more manual data entry. Real apps. Real screens. Real scores.

The Stack Grew Up

Day 1	Day 2
FastAPI	FastAPI
In-memory only	Supabase database
Manual element list	Android UI tree XML
One-off test	Persistent, repeatable audits
No history	`/audits/recent` endpoint
No stats	`/stats` endpoint

The First Real Scan

I ran the first auto-scan on a test banking app login screen. Five interactive elements. Only two had labels.

Result: D — 40% accessible

Recommendation: "Urgent. Most elements are invisible to screen readers. Immediate fixes required."

That's the entire point. A real banking app with that score would be unusable by blind customers.

What Broke

The deploy failed multiple times. First, Render couldn't find the port. Then it couldn't find models.py. Then the build cache held onto old code. Each error taught me something about how Render handles deployments. I fixed the start command to use $PORT, created the missing files, cleared the build cache, and redeployed.

Three hours of debugging. Ten minutes of actual feature work. That's real engineering.

What Works Now

/scan — Auto-scan from Android UI tree XML
/stats — Aggregate statistics from Supabase
/audits/recent — Recent audit history
Supabase persistence — Every audit saved
Full pipeline — Request → Parse → Score → Save → Respond

What's Next (Day 3)

Build a public dashboard showing all audited apps and scores
Connect real app scanning to my Phone Agent's UI tree output
Start scanning Nigerian banking apps for real

The Repo

👉 github.com/Dexter2344/accessbuild-api

Day 2 is done. The API has a memory now.

— Dexter

Day 1 of AccessBuild: I built and deployed a working accessibility audit API from scratch. No grant. No funding. Just code. It scans apps, scores them A-F based on accessibility labels, and shows exactly how inaccessible they are to blind users.

Okeke Chukwudubem — Wed, 16 Sep 2026 22:58:41 +0000

Okeke Chukwudubem

Sep 16

AccessBuild Day 1: I Built an Accessibility Audit API From Scratch

#ai #webdev #programming #productivity

2 min read

AccessBuild Day 1: I Built an Accessibility Audit API From Scratch

Okeke Chukwudubem — Wed, 16 Sep 2026 22:58:01 +0000

No grant. No funding. Just a working API deployed in one day.

I've been waiting on grant funding for AccessBuild for weeks.

The deadline passed. The emails went unanswered. So I made a decision: build with what I have.

Today is Day 1.

What AccessBuild Is

AccessBuild is an AI-powered accessibility audit tool for mobile apps. It scans an app's interface, checks whether interactive elements have proper accessibility labels, and scores the app from A to F.

If an app scores F, it means visually impaired users literally cannot use it. Screen readers can't read unlabeled buttons. Blind users are locked out.

I discovered this problem while building my Phone Agent. I tested 30 Nigerian apps. 100% of banking apps scored F.

What I Built Today

A working FastAPI backend, live on Render.

Feature	Status
`/audit` endpoint	✅ Live
`/grades` endpoint	✅ Live
A-F scoring logic	✅ Working
Accessibility percentage calculation	✅ Working
Recommendation engine	✅ Working

How It Works

You send a list of UI elements from any app screen. Each element has a type (button, input, icon) and an optional accessibility label. The API:

Filters out non-interactive elements
Counts how many interactive elements have labels
Calculates the accessibility percentage
Assigns a grade (A through F)
Returns a recommendation

The Test

I ran the first audit. A fake banking app with 5 interactive elements. Only 2 had labels.

Result: D — 40% accessible

Recommendation: "Urgent. Most elements are invisible to screen readers. Immediate fixes required."

That's the entire point. A real banking app with that score would be unusable by blind customers.

The Stack

FastAPI backend
Deployed on Render (free tier)
No environment variables needed
Pure Python logic

What's Next (Day 2)

Auto-extract UI elements from real apps
Store audit results in Supabase
Build a public dashboard showing app scores
Expand element types

Why I'm Building This Without Funding

Because the problem is real. 100% of Nigerian banking apps are inaccessible to visually impaired users. That's millions of people locked out of their own money.

I can't wait for a grant to fix that.

Day 1 is done. The API is live. Day 2 starts tomorrow.

— Dexter

I Got Tired of Waiting for Funding. So I Shipped a Live Product.

Okeke Chukwudubem — Wed, 09 Sep 2026 23:01:06 +0000

I planned to be building AccessBuild right now.

AccessBuild is my AI-powered accessibility audit tool—born from a discovery that hit me hard during the Phone Agent build: 100% of Nigerian banking apps are completely inaccessible to visually impaired users. Not one. Not some. All of them scored F.

I drafted the business plan. Mapped the revenue model. Defined the target audience. Wrote grant applications. Sent them out.

And now I wait.

Here's the plan I set for myself: if funding isn't available by next week, I build with what I have. No more waiting. No more "when the money comes."

That deadline is almost here.

What I Built While Waiting

ApexSignal—a premium multi-page trading dashboard.

It's not directly related to accessibility. It's not my life's mission. But it's proof of work. It's me refusing to sit still.

The architecture:

A FastAPI backend deployed on Render
A multi-page frontend deployed on Vercel
Full API integration via fetch()
Real-time WAT clock
Pair analysis interface
Market scan endpoint
Chart upload support
Premium dark gold aesthetic

Two live URLs. A working system. Shipped while waiting for an email that hasn't come.

The Lesson

Funding doesn't define you. Motion does.

I could have spent these weeks refreshing my inbox, waiting for a grant committee to decide my future. Instead, I built something. It's not perfect. The AI brain still needs wiring. The analysis is placeholder. But the infrastructure is real.

Backend. Frontend. Deployment. Connection. All done.

What Next

AccessBuild still gets built—with or without funding. If the grant comes, I scale faster. If it doesn't, I build the MVP myself and bootstrap from there.

ApexSignal continues too. The next phase is wiring in real AI analysis logic. Then chart screenshot reading. Then possibly auto-execution.

I'm not waiting anymore.

— Dexter

I asked AI to audit my shipped code. It found a silent bug in 2 minutes that I'd missed for months No crash. No error. Just wrong output in one edge case AI isn't just for building faster it's for catching what tired eyes miss When did a bug last humble u?

Okeke Chukwudubem — Fri, 04 Sep 2026 21:38:15 +0000

Back from Exam Season. Now I'm Building Something Bigger.

Okeke Chukwudubem — Tue, 25 Aug 2026 21:25:04 +0000

Exams are done. To the glory of God. Now the real work begins — AccessBuild.

I've been quiet again. But this time, it was for a good reason.

Exams are finished. To the glory of God.

If you've been following my build logs, you know the pattern: I build, I disappear for exams, I come back, I build again. This semester was brutal. Multiple courses. Long nights. The usual stress of being a software engineering student who's also trying to ship real projects.

But I made it through. And now I have space again.

The Break Wasn't a Pause on Everything

Even during exam season, I was building in the background. I remade several portfolio sites:

A luxury restaurant site (Onyx Dining)
A premium law firm site (Meridian Law Chambers)
A car dealership site (AutoLux Motors)
A salon site (Dexter Salon)

Each one a full multi-page build. Each one with working forms, professional design, and real attention to detail. My portfolio is sharper now than it was before the break.

What's Coming Next: AccessBuild

You might remember my accessibility audit from the Phone Agent build logs. I discovered something that's been sitting in my chest since then:

100% of Nigerian banking apps are completely inaccessible to visually impaired users.

Not one. Not most. ALL of them. Scored F on my audit. Invisible to screen readers. Unusable by millions of people.

That discovery became an idea. The idea became a plan. And now that exams are done, I have the space to build it.

AccessBuild is an AI-powered accessibility audit tool for mobile apps. It automatically tests apps, scores them from A to F, and tells developers exactly what to fix. The goal: make African apps accessible to everyone—not just the ones who can see.

I've already drafted the business plan. The revenue model. The target audience. The grant application. The foundation is ready.

Now it's time to build.

What to Expect

I'll be documenting the AccessBuild journey the same way I documented the Phone Agent—public build logs, honest challenges, real progress. No hype. Just building.

The first step: turning the manual audit methodology into an automated engine. The Phone Agent already has the vision system. AccessBuild repurposes it from automation to auditing.

If you're interested in accessibility, AI, or just watching someone build something meaningful from scratch—stick around. This one's going to be bigger.

The Repo

The Phone Agent is still here: github.com/Dexter2344/phone-agent

AccessBuild gets its own repo soon. I'll share when it's live.