DEV Community: Akin Ajobo

The live realtor model passed. The goodbye failed. published: true

Akin Ajobo — Tue, 06 Oct 2026 10:03:01 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

I run a voice CRM for a realtor. The agent is supposed to take a lead over the phone: hear a fact, save it, ask for the one missing detail, and stay on the line until the realtor says that is all.

In production it kept missing that script. It went silent after saving a field. A phone number made it skip the email and jump toward the close. It asked again for a name or a budget it had just been given. It stored "call him Friday" and never said Friday. It saved and hung up before asking whether that was everything.

I turned those five failures into five Kaggle tasks. The tools return only the fields they saved. They do not hand the model its next sentence. A short spoken reply is in the prompt, and it is not what the score measures. A task scores 1 only when every check passes.

speak-after-update. After a new lead, ask one missing question out loud.
email-after-phone. A phone number must not skip the email question.
no-repeat-known. Do not ask again for a field the realtor already gave.
confirm-before-end. Ask if that is all before saving, and end the call only after yes.
speak-the-reminder. Say the follow-up day. Storing it is not enough.

Models Tested

The model on the live phone line is Gemma 4 26B (gemma-4-26b-a4b-it). That was the one I most wanted to see fail in the same way the calls fail.

I also ran Gemini 3.7 Flash, which Kaggle ran when each task was created, plus Gemini 3 Flash, Claude Sonnet 5, and GPT-5.4 mini. Same prompt, same tools, same leads: Ada in Akobo, Tunde's land in Ibadan, Ngozi's duplex in Lekki, and a Friday reminder for Chidi.

Findings

Gemma passed all five. So did Gemini 3.7 Flash. Gemini 3 Flash and Claude passed four. GPT-5.4 mini passed two.

Task	Gemma 4 26B	Gemini 3.7 Flash	Gemini 3 Flash	Claude Sonnet 5	GPT-5.4 mini
speak-after-update	Pass	Pass	Pass	Pass	Pass
email-after-phone	Pass	Pass	Pass	Pass	Fail
no-repeat-known	Pass	Pass	Pass	Pass	Fail
confirm-before-end	Pass	Pass	Fail	Fail	Fail
speak-the-reminder	Pass	Pass	Pass	Pass	Pass

On the opening lead, Gemma saved Ada Okafor, the three-bedroom flat, and Akobo, then said, "Got it. Do you have her phone number?" Given the phone number, it asked, "Thanks. Do you have an email for her?" Told she had no email, it moved on: "No problem. What is her budget?" For the reminder it said, "I'll remind you to call Chidi this Friday." Before ending Ngozi's call it asked, "Is that all?" and closed with, "The lead is saved. Have a great day!"

That is the opposite of what the live calls do. The intake policy is in this model. The production misses are in the voice loop around it: silence after a tool call, a phone number that skips a step, a reminder that is stored and never spoken.

GPT-5.4 mini is the model that actually skipped the script. After Ada's phone number it asked, "What's her budget?" Told she had no email, it stored the email as "No email" and jumped to, "Is that all for Ada Okafor?" For Tunde it first asked, "What's his email?" Then, when the realtor said, "What else should I tell you?" it saved the lead, ended the call, and said "Saved." Email and a follow-up were still missing.

Claude and Gemini 3 Flash failed only the last sentence of the closing task. Both asked whether that was all, both saved, and both ended the call. Claude said, "Saved Ngozi's lead successfully!" and then, after the hang-up, "Thanks for calling, have a great day!" Gemini said the details were saved, ended the call, and finished with "Omnipresent Voice AI CRM lead capture complete." The check looks at the final sentence. A correct save followed by a polite goodbye scores zero. GPT did say "Saved." and still failed, because it never called end_call.

Two measurements are worth doing next. One is the spoken audio path, because a perfect text transcript did not reproduce the live failures. The other is a closing check that accepts "saved" anywhere in the closing turn, so a second goodbye sentence is not an automatic miss.

My Benchmark

Realtor intake on Kaggle

OVAM AI: A Voice Assistant for My Wife A Realtor

Akin Ajobo — Mon, 05 Oct 2026 01:04:15 +0000

What I Built
My wife runs a real-estate business, and one of the annoying parts of her workflow happens after she talks to a prospect.
She might finish a conversation knowing the person's name, phone number, preferred location, budget, property type, timeline, objections, and payment plans — but then she has to remember everything and manually turn that conversation into a CRM record.
So I built OVAM AI, a voice-first real-estate assistant for her.
Instead of filling out a form, she can simply tell it what happened:
“I just spoke to Sarah. She wants a residential plot around Akobo, Ibadan. Her budget is about 10 million naira and she wants to buy within two months. Her phone number is 08012345678.”

OVAM AI turns that into a structured lead.
She can then correct or add information naturally:
“Actually, her name is Kemi, not Sarah.”

or:
“She can pay 3 million down and the rest over 12 months.”

The assistant updates the existing lead instead of creating a mess of duplicate information.
It also doesn't save automatically.
Once it has enough information, it summarizes what it understood and asks for confirmation. “No” leaves the lead unsaved. “Yes, save it” creates the record.
The goal is simple:
Tell me what happened. I'll handle the CRM.

Demo
Live demo:
https://ovam-ai-fawn.vercel.app
Tap the microphone and talk to OVAM AI like you just finished speaking with a real-estate prospect.
You can also use the typed-note mode if you don't want to use your microphone.

Code
GitHub:
https://github.com/Mistakili/OVAM-ai
The repository contains the React frontend, API routes, Gemma integration, AssemblyAI voice integration, CRM tools, and setup instructions.

How I Built It
The core intelligence behind OVAM AI is Gemma.
I use Gemma to turn natural language into structured CRM information rather than forcing the realtor through a traditional form.
The application is built with:

Gemma for lead understanding and structured CRM reasoning
AssemblyAI Voice Agent API for real-time speech, transcription, turn detection, and voice responses
React + Vite for the frontend
Vercel serverless functions for the backend/API layer
Tool calling with update_lead and save_lead to modify the CRM state
Browser storage for the current lead records The important part is the interaction between the model and the application.

Gemma isn't just generating a conversational response. It can update structured lead state through tools. The system is designed to understand facts in whatever order the realtor provides them, preserve information that is still valid when something is corrected, avoid inventing missing information, and ask only for useful missing details.

Why Does Open Innovation Matter?
For this project, I didn't want the AI model to be a black box that my entire product depended on.
Gemma gives me an open-weight model that I can build around, experiment with, and potentially deploy differently as the product evolves.
That matters because OVAM AI is intended for a real business, not just a demo.
Today, I can use Gemma through an API. Tomorrow, I can experiment with different Gemma variants, deployment strategies, structured outputs, or private inference without having to redesign the entire product around a proprietary model.
More importantly, open innovation makes experimentation accessible.
I'm an independent developer building this for a small real-estate business. I don't have a giant infrastructure team or an enormous AI budget.
Being able to take an open-weight model and turn it into a useful product for someone close to me is exactly the kind of thing I think open innovation should enable.

Prize Categories
Best Use of Gemma
OVAM AI is built around Gemma as its lead-understanding layer.
The model takes messy, natural human conversation and turns it into structured CRM state that the application can act on through tools.
That is the core AI behavior of the product.

Why I Built This
I didn't build another CRM because the world needs another CRM.
I built this because my wife shouldn't have to finish a conversation with a potential buyer and immediately become a data-entry clerk.
She should be able to say:
“Here's what happened.”
And let the software take care of the rest.
Talk → Understand → Structure → Confirm → Save.
That's OVAM AI.

The Production Bug No Capacitor Push Notification Tutorial Prepared Me For

Akin Ajobo — Mon, 29 Jun 2026 08:39:58 +0000

Everything worked perfectly... until I uploaded my app to TestFlight.

Every push notification tutorial I read covered the same things:

Register for push notifications.
Request permission.
Get the device token.
Send your first notification.

And to be fair, all of those tutorials worked.

Until they didn't.

The moment I uploaded my Capacitor app to TestFlight, the entire push notification flow quietly fell apart.

No obvious errors.

No compiler issues.

No helpful stack traces.

Just... silence.

Over the next two days, I went down one rabbit hole after another before discovering that the problem wasn't a single bug—it was a collection of production-only assumptions that none of the tutorials mentioned.

This article is the postmortem I wish I'd found before I started.

The Setup

The stack was pretty standard.

Capacitor
TypeScript
Node.js backend
APNs
iOS

Everything behaved exactly as expected during development.

Push permissions appeared.

The device registered.

Tokens looked correct.

Notifications arrived instantly.

I genuinely thought this part of the app was finished.

Then I created a TestFlight build.

The Moment Everything Broke

I installed the TestFlight build.

Opened the app.

Tapped my "Send Test Notification" button.

Nothing happened.

No notification.

No crash.

No useful error message.

At that point I made the same assumption I think most developers make:

"I must have misconfigured APNs."

That assumption cost me hours.

My Debugging Timeline

Here's roughly how the next two days went.

09:30

Verified notification permissions.

✅ Correct.

10:00

Verified APNs key.

✅ Correct.

11:15

Regenerated provisioning profiles.

No change.

12:40

Deleted and recreated the app on my phone.

Still nothing.

14:00

Started blaming Firebase.

Wrong direction.

15:30

Started questioning Capacitor.

Also wrong.

17:00

Realized something important.

TestFlight isn't your development environment.

It's production.

That changed everything.

Production Behaves Differently

This was the biggest lesson.

When you install from TestFlight, Apple expects production infrastructure.

Not development.

Not sandbox.

Production.

That sounds obvious now.

It wasn't obvious while debugging.

Once I started treating the build as a production deployment instead of "a beta version," the entire debugging strategy changed.

Then Another Problem Appeared

Even after fixing the APNs environment...

My backend occasionally crashed.

The error looked something like this.

Error: read ECONNRESET

Error: write EPIPE

At first I thought Apple was rejecting my requests.

It wasn't.

Apple was simply closing idle HTTP/2 sessions.

That's normal.

My server wasn't treating it as normal.

Production Software Needs Production Recovery

Once I stopped treating HTTP/2 disconnects as exceptional failures, the fix became straightforward.

Instead of allowing dropped connections to crash the process, the backend now:

Detects disconnects
Tears down the session cleanly
Reconnects automatically
Retries safely where appropriate

Those few changes completely changed the reliability of the notification service.

The Three Assumptions That Cost Me The Most Time

1. "If it works locally, production will work."

Wrong.

Development environments hide a surprising amount of complexity.

Production exposes all of it.

2. "It has to be my certificates."

Certificates were fine.

Provisioning profiles were fine.

The issue was the production environment itself.

3. "ECONNRESET means something is broken."

Not necessarily.

HTTP/2 sessions close.

Networks reconnect.

Production software should expect that.

What I Wish Someone Had Told Me

Before shipping a Capacitor app with push notifications:

✅ Test on a physical device early.

✅ Treat TestFlight as production.

✅ Don't hardcode APNs environments.

✅ Log every push response.

✅ Build reconnect logic into your APNs client.

✅ Expect HTTP/2 sessions to terminate.

✅ Document every native iOS change.

These sound simple.

They aren't obvious when you're learning from getting-started tutorials.

Why I Built an Open-Source Reference

While debugging this, I noticed something.

Most tutorials stop once the first notification appears.

That's the easy part.

Almost nobody talks about:

TestFlight failures
Production APNs routing
Backend reconnect logic
Native configuration drift
Production troubleshooting

Those are exactly the problems that consume entire weekends.

So instead of letting those lessons disappear into Git commits, I started building an open-source project called Production Hybrid Reference.

The goal isn't another starter template.

It's a collection of production-ready recipes, troubleshooting guides, and engineering postmortems based on real applications—not hypothetical examples.

The first module focuses entirely on production push notifications and includes:

A runnable Node.js APNs server
A Capacitor mobile example
Troubleshooting guides
A production postmortem
Practical engineering principles
Copy-paste reference code

If it saves even one developer from spending two days chasing the wrong problem, it'll have been worth publishing.

What's Next

Push notifications are just Module Zero.

The next production battle scars I'll be documenting include:

RevenueCat synchronization
AppDelegate configuration drift
Background tasks
Production logging
Apple review preparation
Hybrid app architecture

Each module follows the same philosophy.

Real bug.

Real investigation.

Real fix.

Final Thoughts

The biggest lesson wasn't technical.

It was realizing that there's a huge gap between "it works" and "it survives production."

Tutorials are great at helping you build features.

Production teaches you how software actually behaves.

If you've run into a production issue with Capacitor that took hours—or days—to solve, I'd genuinely love to hear about it.

Leave a comment below with your biggest production battle scar.

If enough people are fighting the same problem, it'll become the next module in the Production Hybrid Reference.

Let's save each other a few weekends.

About this series:
This article is the first in a series documenting real production issues I encountered while shipping a commercial Capacitor application. Every solution is based on an actual debugging session—not a contrived tutorial example.