DEV Community: Fadhlullah Mustapha

Onebar: You're on a ridge with one bar of signal and no data.

Fadhlullah Mustapha — Sun, 11 Oct 2026 13:44:01 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

OneBar is a low-bandwidth weather assistant for hikers. Ask a question like “when should I turn back?” and it replies with one SMS-length message based on the forecast for your location.

The language model writes the sentence, but it does not calculate the weather facts. Code computes details such as sunset, gust speed, and turnaround time; a separate checker verifies that the reply is under 160 SMS characters, includes the facts the question needs, and doesn’t introduce unsupported numbers or contradict the forecast. If a draft fails, OneBar retries once, then uses a checked template.

It’s for people who need a quick, readable answer on the trail, especially when a full weather app is inconvenient on a weak connection. OneBar is not a rescue service or a replacement for an official mountain forecast.

Demo

url: https://onebar-v46s.onrender.com ,demo video:https://youtu.be/KurEtVshOIM

Code

https://github.com/JUICEWRLD998/onebar

How I Built It

I fine-tuned the open-weight Qwen3-8B with LoRA for the specific task of writing short, forecast-grounded replies. The dataset contains 3,290 training examples and 514 validation examples, built from mountain locations and forecast scenarios. I evaluated it on 414 held-out questions, with locations separated by map cell from the training data.

On that test set, the tuned model passed OneBar’s checks on its first draft 98.1% of the time, compared with 56.8% for the base Qwen3-8B. It had no template fallbacks in that evaluation. Every answer still goes through the checker; those results are not a guarantee that a forecast or answer is always correct.

The application uses Python and FastAPI for the facts and checking pipeline, React and TypeScript for the web interface, Open-Meteo for forecast data, and Temporal for durable trip timers and overdue-contact alerts. Tinker was used to fine-tune and serve the model.

Why Does Open Innovation Matter?

Open-weight models let me adapt the model to a narrow, measurable task instead of treating a general-purpose assistant as a black box. I could fine-tune Qwen3-8B, compare it against the untuned model and a larger model on the same held-out questions, and build the product around the behavior the task needs: short answers that use facts computed by the application.

The model is only one part of the safety approach. OneBar keeps the facts and validation in ordinary code, so a model response must pass explicit checks before it is sent. That separation makes the system easier to inspect and improve than relying on a model provider’s answer alone

Prize Categories

Featured Category: Tinker
Partner Category: Temporal

Solo Builder: Mustapha Fadhlullah

Cue: a drum machine whose song is a Sanity dataset

Fadhlullah Mustapha — Sun, 04 Oct 2026 21:24:01 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Cue is a drum machine whose song is a Sanity document. There are no audio files. The browser reads the numbers in the dataset and plays them as sound.

A DJ cues the next track in headphones while the room hears the current one. A Sanity document already has that split: a draft and a published version. Cue makes it literal.

The Floor is a public page. It plays the published song, with no token.
The Deck is a Sanity App SDK app. It edits the draft and plays it in a Cue channel that only the DJ hears.
Drop publishes the draft. Every open Floor switches to the new song on the next bar line.

Published is the room. Drafts are the headphones. Publishing is the drop.

Demo

link: https://youtu.be/E2ly2dM5tJo
url:https://cue-steel-seven.vercel.app/
Live Deck (needs a sign-in to the Sanity organization): https://www.sanity.io/@o4h8r4fp1/application/hfqfe4stqbkn23mv9qs3bryp

Code

https://github.com/JUICEWRLD998/cue

How I Used Sanity

Drafts, published versions, perspectives and real-time listening are the instrument, not storage behind it. Nothing else in the project holds state, and there is no server of mine between the DJ and the room.

The Floor reads the song with perspective: 'published', useCdn: false and no token. It listens with client.listen() and polls every 2 seconds as a fallback.
The Deck uses the App SDK: useEditDocument changes the draft, and publishDocument is the Drop.
Sounds are synthesised in the browser from parameters stored in voice documents (pitch, decay, tone, gain).

The schema, and a trap I designed around

voice (document) name, kind, pitch, decay, tone, gain
song (document) title, bpm, swing, sections[]
section (object) title, kind, bars, lanes[]
lane (object) voice -> reference(voice), steps[]
step (object) index 0-15, velocity, probability, nudge (ms)

The obvious model makes sections and lanes separate documents that the song references. That breaks the Drop. Publishing a document does not publish the documents it references, so the song would go live while its patterns stayed in draft, and the room would play a half-new song. I embedded sections, lanes and steps in the one song document, so a Drop is a single commit. Voices stay as references because they are a shared kit that rarely changes.

Steps are objects, not a string like x...x...x.... A string cannot be queried. With objects, GROQ can ask "which lanes hit the off-beat", and each hit carries velocity, probability and a nudge in milliseconds.

Time without a server clock. Every device computes the step from the wall clock, so two tabs or a phone and a laptop stay in step without talking to each other. Measured in real Chrome against the live dataset: a publish was noticed after 1.4 to 1.9 s, and the new song started on the next bar, about 3.2 s after the publish at 118 bpm.

Sanity Project Details

Project ID: jwc6peq5
Dataset: production (public, read-only)

Agent Session

Supported tools include Claude Code

Made by Mustapha Fadhlullah - Software Developer

Derica: new tin prices the moment the bag price changes

Fadhlullah Mustapha — Sun, 04 Oct 2026 13:46:06 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Derica is for my friend Amina, who sells rice, beans, garri and groundnut in a Nigerian market. She buys by the 50kg bag and sells by the derica, mudu and paint (three local tins). When her supplier raises the bag price, she has to redo the maths for every tin by hand. Her tin prices usually change late, and she earns less on every sale in between.

She pastes the supplier's WhatsApp message, for example "Rice 50kg now 78k". Derica reads it and shows what it understood. It then works out the new price for each tin, keeping her profit the same and rounding up to the next ₦50. One tap makes a price card picture she can share on WhatsApp.

Example: the bag goes from ₦78,000 to ₦82,000, and her ₦2,900 mudu becomes ₦3,050.

The AI only reads the message and never sets a price. Normal code does all the maths. If the AI reads something absurd, such as ₦15,000,000 for a bag, Derica refuses to show it.

Demo

Demo video:https://youtu.be/Md6PzFtvtso url:https://derica.onrender.com/

Code

https://github.com/JUICEWRLD998/Derica

How I Built It

I trained a small AI model (Qwen3.5-4B) on Tinker with about 3,500 practice messages I generated. Training took about 19 minutes and cost under a dollar.
Python with FastAPI serves the app. The page is plain HTML, CSS and JavaScript.
The price maths uses exact fractions, so there are no rounding surprises.
Render hosts it.
Amina's real messages (18) were the base for the tests. I also wrote two harder sets of 39 and 29 messages and locked them before testing.

Why Does Open Innovation Matter?

Derica reads messy WhatsApp price messages, like "Beans no dey cheap again, 92k now". That job needs a model that knows Nigerian Pidgin and local measures such as the derica, mudu and paint. A general closed API would need a long prompt full of rules and examples on every call.

Open weights let me fine-tune a small model, Qwen3.5-4B, on about 3,500 practice messages. Open models also let me test honestly. I compared my model against two other models and a plain rules reader, with test sets locked before scoring.

My Agent Session

Prize Categories

Tinker. I fine-tuned the model and served it through Tinker, and the app calls it live.
Render. The app is deployed there.

Team Submissions: Solo builder- Mustapha Fadhlullah

Thanks for participating!

I Built a Chatbot That Remembers You Across Devices — 6 Things I Learned

Fadhlullah Mustapha — Sat, 03 Oct 2026 13:29:21 +0000

I built Pickup, a chatbot that remembers users across browsers and devices using Walrus mainnet.

I thought the hard part would be storing and retrieving memories.

It wasn't.

The real challenge was making decentralized storage work smoothly behind a chatbot. These were the six things I learned.

Memory can't be allowed to freeze the chatbot

If memory retrieval is slow, the whole chat shouldn't have to wait.

I added an 8-second timeout. If memory doesn't come back in time, the chatbot answers normally and tells the user that it answered without the latest memory.

The chatbot should still work when memory doesn't.

Don't make users wait for writes

One Walrus mainnet write took 36 seconds in my testing.

Waiting 36 seconds after every message obviously isn't acceptable.

So I changed the flow:

Reply first → save memory afterward.

The user gets the response immediately while the memory is saved in the background.

Don't remember everything

Saving every message creates a lot of useless memory.

I added a simple filter that skips short conversations and messages that don't contain useful information about the user.

For example:

"Why does it 429?" → skip

"I'm running v0.1.8 and getting 429 errors." → save

The goal isn't to remember everything.

It's to remember the right things.

A successful write may not be immediately readable

I ran into an interesting consistency issue.

A memory could be successfully saved, but the next recall wouldn't find it because the index hadn't caught up yet.

So I temporarily keep recently saved memories on the client and include them in recall results until the server catches up.

In other words:

Written ≠ immediately readable.

That's something I had to design around.

Queue your writes

Sending several writes at once caused rate-limit failures.

The fix was simple:

One namespace, one write at a time.

Instead of firing every write immediately, I queue them.

Show the user what the chatbot remembered

Pickup shows the memories used for each response and how old they are.

This turned memory from a black box into something I could actually inspect.

When the chatbot gives an unexpected answer, I can see whether it used the wrong memory, an old memory, or no memory at all.

One limitation

The SDK I'm using currently doesn't provide a delete method.

So I didn't add a fake delete button.

Instead, the UI warns users not to store secrets or sensitive information in persistent memory.

I'd rather be honest about the limitation than pretend deletion is guaranteed.

The main lesson

Building persistent AI memory taught me that storage is only part of the problem.

Once storage sits behind a real-time chatbot, you also have to think about:

Latency. Consistency. Rate limits. Memory quality. Observability.

That's where most of the interesting engineering happened.

Pickup was built for Walrus Sessions 8.

Code:
https://github.com/JUICEWRLD998/pickup