DEV Community: Okeke Chukwudubem

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.

21 build logs. Months of work. One shipped project. An autonomous AI agent that controls a phone. Web interface. Multi-app workflows. 94% accuracy. Full setup guide included so you can run it yourself. 👉 github.com/Dexter2344/phone-agent

Okeke Chukwudubem — Sun, 09 Aug 2026 09:32:18 +0000

Details jumping from 80% to 94% accuracy

Okeke Chukwudubem

Aug 9

Project Log #21: The Grand Finale. We Shipped. (Plus: Full Setup Guide)

#ai #webdev #python #automation

4 min read

Project Log #21: The Grand Finale. We Shipped. (Plus: Full Setup Guide)

Okeke Chukwudubem — Sun, 09 Aug 2026 09:30:30 +0000

21 build logs. Months of work. One shipped project. Here's the full journey—and how to set up the Phone Agent on your own device.

The first build log was published months ago. "I'm building an AI agent that controls a phone." No code. No repo. Just an idea and a cracked phone.

Today, after 21 build logs spread across months, the project is shipped.

This wasn't a straight line. There were gaps. Weeks where the log went silent—not because the work stopped, but because life doesn't pause for build logs. I took breaks to survive exam season. I paused to ship 9 portfolio websites. I stepped away when the code refused to cooperate and my brain needed rest.

But every time I came back, the agent was still there. Waiting. And every log picked up where the last one left off.

What We Built

An autonomous AI agent that controls an Android phone using natural language commands. It can parse your words into actions, read the screen, tap buttons, type text, switch between apps, verify financial data, and serve a web interface—all offline.

The Real Timeline

Phase	What Happened
Days 1-4	Foundation. Gemma 4 + ADB. First working pipeline.
Days 5-8	Vision overhaul. UI tree. OCR. Template matching.
Days 9-12	Accessibility audit. 30 apps scored.
Days 13-16	Multi-app workflows. Task memory. Home reset.
Days 17-19	Financial verification. Accuracy from 80% to 94%.
Breaks	Exams. Portfolio sites. Life.
Days 20-21	Web interface. Flask backend. Shipped.

📖 FULL SETUP GUIDE: How to Install and Use the Phone Agent

Follow these steps to get the agent running on your own Android phone.

Prerequisites

An Android phone (Android 7 or later)
At least 6GB of free storage space
A WiFi connection for the initial download

Step 1: Install Termux

Do NOT install Termux from the Google Play Store—that version is outdated. Install it from F-Droid instead.

Open your phone's browser
Go to f-droid.org
Download and install the F-Droid app
Open F-Droid and search for "Termux"
Install Termux from F-Droid

Step 2: Set Up Termux

Open Termux and run these commands one by one. Wait for each to finish before typing the next.


bash
pkg update
pkg upgrade
pkg install python git curl wget
pkg install tesseract
pkg install android-tools

Step 3: Install Ollama
Ollama is the tool that runs Gemma 4 locally on your phone.

bash
curl -fsSL https://ollama.com/install.sh | sh
After installation, start Ollama:

bash
ollama serve
Open a new Termux session (swipe from left, tap "New session") and pull the Gemma 4 model:

bash
ollama pull gemma4:4b
This downloads about 2-3GB. Use WiFi. Be patient.

Step 4: Clone the Phone Agent Repository
bash
git clone https://github.com/Dexter2344/phone-agent.git
cd phone-agent
Step 5: Install Python Dependencies
bash
pip install flask flask-cors requests numpy PyPDF2 lancedb
Step 6: Enable Developer Options and ADB
Go to Settings → About Phone

Tap "Build Number" 7 times until you see "You are now a developer"

Go back to Settings → Developer Options

Enable "USB Debugging"

Connect your phone to itself via ADB:

bash
adb devices
You may need to approve a prompt on your phone. Once approved, you'll see your device listed.

Step 7: Start the Phone Agent
Using the Web Interface (Recommended):

bash
python server.py
Then open your phone's browser and go to: http://localhost:5000

You'll see a chat interface. Type commands like:

"Open WhatsApp and send a message to Mom saying I'll call later"

"Copy my bank balance and send it to Mom on WhatsApp"

Using the Terminal (Alternative):

bash
python agent.py
Then type commands directly into the terminal.

Troubleshooting
Problem Fix
"Ollama not found"  Make sure you ran ollama serve in a separate Termux session
"ADB device not found"  Check USB Debugging is enabled. Run adb kill-server then adb devices again
"Module not found"  Run pip install for the missing module
"Tesseract not found"   Run pkg install tesseract
Phone gets hot  Close other apps. The agent is CPU-intensive. Take breaks.
Agent misreads numbers  The verification layer will catch most errors. For financial data, always double-check.
Using the Web Interface
Once server.py is running and you've opened http://localhost:5000:

Status bar: Green dots mean Ollama and ADB are connected. Red dots mean something is wrong.

Command input: Type what you want the agent to do. Be specific.

Example commands: Click any example to auto-fill and send.

History: Your last 20 commands and responses are stored.

The Repo

👉 github.com/Dexter2344/phone-agent

21 build logs. Months of work. One shipped project. Full setup guide included.

Thank You

To everyone who followed this log—through the daily posts and the weeks of silence—thank you. This was never about shipping fast. It was about shipping honestly.

This was Log #1:

"I'm starting a new project. It's the most ambitious thing I've attempted from a phone."

This is Log #21. We shipped.

Day 20: Hours of debugging. CORS errors. Broken paths. Misspelled IDs. But the Phone Agent finally has a web interface. Flask backend. Chat-style frontend. No more terminal-only. 👉 github.com/Dexter2344/phone-agent

Okeke Chukwudubem — Tue, 04 Aug 2026 23:30:34 +0000

Okeke Chukwudubem

Aug 4

Project Log #20: After Hours of Screen Time, the Agent Has a Face

#ai #webdev #python #automation

2 min read

Project Log #20: After Hours of Screen Time, the Agent Has a Face

Okeke Chukwudubem — Tue, 04 Aug 2026 23:29:31 +0000

Day 20. I stared at my screen until my eyes burned. But the web interface is live. Flask backend connected. The agent is finally usable.

I've been staring at this screen for hours.

Not the productive kind of staring. The frustrating kind. The kind where you write 50 lines of code, test it, watch it break, rewrite it, test it again, and repeat until you forget what time it is.

Today was that kind of day.

What Got Built

After hours of debugging, I shipped two things:

A Flask server (server.py) that wraps the agent in a REST API. Three endpoints: /status checks if Ollama and ADB are connected. /command sends a natural language command to the agent and returns the result. /history returns the last 20 commands.
A web interface (interface.html) that looks like a chat app. Dark terminal theme. Gold accents. Type a command. See the agent respond. Real-time status indicators showing whether Ollama and ADB are alive.

The interface talks to Flask on localhost:5000. Flask talks to the agent. The agent talks to the phone. Everything local. No cloud. No external servers. Just a phone running its own AI.

The Grind

Here's what the polished build log doesn't show:

Flask refused to serve the HTML file for 45 minutes because I forgot send_file needs an absolute path.
The status endpoint kept returning false for ADB because I was checking the wrong string in the output.
The interface looked like a developer's debug page until the third redesign.
CORS errors because I forgot flask-cors. Ten minutes of confusion for a one-line fix.
The send button wasn't working because I misspelled getElementById. Thirty minutes. One missing character.

This is the real build log. Not the clean version. The "I need to step away from this screen before I throw my phone" version.

The Result

The interface works. It's not beautiful yet. The design will evolve. But you can type a command in a browser, hit enter, and watch the agent execute it on the phone. That's the milestone.

Status bar at the top. Chat display in the middle. Input area at the bottom. Example commands you can click. Loading states. Error messages. All the basics.

What Still Needs Work

The setup process is still manual. Install Termux. Pull Ollama. Configure ADB. Run the server. Open the browser. Too many steps. A setup script is next.
The interface needs polish. Animations are basic. The design is functional but not premium. I'll iterate.
End-to-end testing hasn't happened yet. The agent works in controlled tests. Real-world reliability is the next frontier.

What's Next

Day 21: Write the setup script. One command. Full install.
Day 22: End-to-end testing. Fix everything that breaks.
Day 23: Ship v1.0.

The Repo

👉 github.com/Dexter2344/phone-agent

server.py is live. interface.html is live. README is updated. The project has a face.

This is Day 20. My eyes hurt. But the agent is no longer trapped in a terminal.