DEV Community: Kane

I fine-tuned an open model to be the front desk at my friend's nail studio

Kane — Sun, 04 Oct 2026 17:52:11 +0000

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

What I Built

Meet Sugar
Sugar is my friend. She does nails in GRA, Port Harcourt: gel, acrylic, Gel-X, BIAB, French tips, chrome, little hand-painted flowers. She's good at it, so she's busy.
I've watched the same thing happen at her station many times. She has a client's hand in one hand and a brush in the other. Her phone keeps lighting up: "Hi dear, are you free today? How much is acrylic?" Someone walks in and asks how long the wait is. She can't stop to reply, she can't write down who came first, and she can't ask the next person if they want coffin or almond, nude or wine, or whether they're allergic to anything.
So people wait, some leave, and the order of who's next lives in her head.
She doesn't need salon software. She needs a front desk: someone to greet people, write down exactly what they want, tell them the price, take payment and give her a clean list of who's next. So I built one.

What it does

Two screens.
The customer site. Customers open it on their phone, from a link Sugar shares or a QR code she can print for her station. The front desk greets them and asks for their name and number, then the service, style, colours, length, shape, allergies and a time. They can tap the options or type the way they talk, in English or Pidgin. They see the full order and the total in naira, pay, and get a ticket that updates on its own: "You're #2 · 1 person ahead of you."
Sugar's queue. A PIN-protected page on her phone or tablet. It shows who's in the chair, who's next, and each person's order: services, style, colour swatches, length, shape, any allergy note (highlighted), the price and whether they've paid. She taps Start when someone sits down and Done when they leave. New bookings chime and slide in by themselves.
The front desk is Qwen3-8B, an open-weight model I fine-tuned with LoRA on Tinker. It talks like Sugar's front desk, knows her menu and prices, and ends every booking with a structured order the app can check.

Demo link

https://sugar-nails-nine.vercel.app

Demo video

https://youtu.be/ZyzuW1q0ZAE?si=SgPEC1N9pV0yKqDI

Code

https://github.com/comzzy/sugar-frontdesk

How I Built It

Sugar doesn't need a chatbot that sounds smart. She needs one that gets the order right: the correct service, the correct price, and the correct time, in the way her customers actually talk, which is often Pidgin.

A general model couldn't do that well. When I tested base Qwen3-8B on her menu, it made up prices, forgot to ask about allergies, and sounded nothing like her. So I trained it on Tinker.

How I used Tinker:

I wrote about 1,750 booking chats in Sugar's voice, in English and Pidgin. Each one ends with a clean order card: name, phone, service, style, colours, length, shape, allergies, time and naira total.
I fine-tuned Qwen3-8B with LoRA on Tinker. I didn't have to set up any GPUs. The training took under 5 minutes and cost about $1.65.
I tested the base model and my trained model on 40 chats neither had seen before.

The results:

Orders that came out fully correct went from 22.5% to 95%.
Prices that were right went from 35% to 92.5%.
Order cards the app could actually read went from 72.5% to 100%.

The live chat runs on that trained checkpoint through Tinker. Each reply costs about ₦0.31, and a full booking comes to roughly ₦2.80.

The rest of the app: The site is a FastAPI app on Vercel. When a customer finishes booking, the order card lands in Sugar's queue, a PIN-protected page where she taps Start when she begins a set and Done when she finishes. The payment step is simulated for now.

Why Does Open Innovation Matter?

Sugar is one person with one phone, working out of GRA, Port Harcourt. She's never going to pay for an enterprise AI subscription, and no big company is building a booking assistant that speaks Pidgin and knows her prices.

Open models change that. Because Qwen3-8B is open-weight, I could take it and shape it to fit her exact menu, her customers and the way she talks. Tinker made the training part easy: I didn't need a GPU or a big budget, just good data and a few minutes. The whole fine-tune cost less than a plate of food.

That's what open innovation means to me. The tools aren't only for big tech anymore. Anybody who knows a small business well enough can build something that actually fits it, and keep full control of it. The code is open too, so another nail tech, barber or caterer can fork it, swap in their own menu, and have their own front desk.

My Agent Session

https://dev.to/agent_sessions/building-sugar-nails-nocuim

Prize Categories

Best Use of Tinker.

I Built My Best Friend a Wedding Planner She Can Talk To

Kane — Fri, 02 Oct 2026 22:20:40 +0000

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

What I Built

Cynthia is my best friend, and she's getting married.
Her wedding plans are spread across voice notes. The budget is in one, a vendor's price is in another, and the list of things still to book is mostly in her head. When she wants to know what's left, she scrolls back and listens again.
Her guests are the same. Most of them won't fill in a form. They'll send a voice note saying "I go come with my husband" and expect someone to remember that he doesn't eat pepper.
So I built Cynthia's Wedding Plans: a wedding planner she can talk to, and an RSVP her guests can talk to.
The planner. Cynthia taps the mic and talks the way she already does in voice notes. For example: "Budget is five million naira, we're thinking December, and we've booked the photographer." The planner keeps four things up to date from what she says:
a checklist with due dates that fit the time she has left
a budget split across venue, food, outfits, decor and the rest
a timeline for the day itself
a vendor list showing who's booked, who's quoted and who she still has to find
It answers her out loud, in a short reply that confirms what it understood and asks for one missing thing at most. One tap gives her a briefing: how many days are left, what's overdue and the next three things to do. Download plan saves the whole plan as a PDF she can share with her family.
The planner, filled in with example numbers.
Voice RSVP. A guest opens the link and just speaks, in English or Pidgin: "Na Funmi. I go come with my husband. Abeg no add pepper for am." The site turns that into a card with name, coming or not, how many people, food needs and a message. The guest checks it, fixes anything that's wrong and sends it. Then they hear a thank-you that says their name.
Voice guestbook. Guests record a wish of up to a minute, or type one, then tap Send wish. Each wish is transcribed and sorted into blessings, advice, funny ones and memories. Cynthia ends up with a keepsake page that has the words and the original voices.
Cynthia's guest list. Only Cynthia can open it. She types her password once, and her phone remembers it for 30 days. It shows the headcount, every reply and the food needs. There's also a CSV download she can send straight to the caterer. Nothing on the site links to the list, and search engines are told to skip it. -->

Demo link

https://cynthias-wedding.vercel.app

Demo video

https://youtu.be/UDY3teDsXlo?si=s5e9bhlEeyu58eWm

Code

https://github.com/comzzy/cynthias-wedding-plans

How I Built It

The planning runs on gpt-oss-120b, OpenAI's open-weight model (Apache 2.0), served by Groq. If it's slow, the app retries once on gpt-oss-20b.
Every time Cynthia speaks, the app sends the model a short summary of her current plan and what she just said. The model sends back JSON: a short spoken reply, any facts she gave (budget, guest count, date), new tasks, tasks she's finished, budget changes, the order of the day and vendor updates. The app merges that into her plan. Models are bad at working out what day of the week a date falls on, so the prompt includes the real Saturdays for the next 14 months, and the model chooses a wedding date from that list. If no model is reachable, a small rule-based parser still picks up budgets, guest counts, dates and lines like "we booked the venue".
The same model reads guests' RSVPs and wishes. The prompt gives it examples of how people really talk: "I go come" means attending, "me and my wife" means two people, "I no dey chop meat" means vegetarian. It also sorts each wish into one of the four guestbook groups.
ElevenLabs does everything to do with voice:
Scribe (speech-to-text) transcribes Cynthia's planner notes, guests' RSVPs and guestbook wishes. It copes with Nigerian names and with Pidgin, which mattered more than anything else here. If the transcript is wrong, nothing after it works.
Voice Design made the planner's voice. I described a young Nigerian woman with a calm, warm voice, someone who sounds like home, and saved the result as "Cynthia Planner".
Text-to-speech in that voice reads the planner's replies and the daily briefing.
The RSVP thank-you is spoken to each guest, using their name.
My note to Cynthia on the home page has a button to hear it read aloud. I generated the audio once and saved it as a file, so playing it costs nothing.
The API keys stay on the server, and the browser only talks to the app's own routes.
Stack: Next.js, Tailwind and Framer Motion on Vercel. RSVPs, wishes and recordings go into a private Vercel Blob store, or into a local folder when it runs on a laptop. Cynthia's plan is saved in her own browser. The guest list sign-in uses a signed, httpOnly cookie, with a limit on how many wrong passwords can be tried. The flowers are hand-drawn SVG, and the look is based on a save-the-date card Cynthia liked.

Why Does Open Innovation Matter?

This is a guest list and a wedding budget. It's family money, and it has her guests' names and what they can and can't eat. I didn't want that tied to one company's API that she has no control over.
Because the model is open-weight, the model is just a setting. The app talks to any OpenAI-compatible endpoint, and changing LLM_BASE_URL and LLM_MODEL in the env file swaps it out. I don't have to rewrite anything if a price changes or a model is retired.
It can also run on her laptop. Point it at Ollama with a small open model (I tested it with gemma3:1b) and keep storage on the local folder. Then the planning model runs on her machine, and her guest list and budget stay there too. To be clear, the voice parts still go through ElevenLabs, so audio is sent to them to be transcribed and spoken. Everything else stays on her laptop.
And it costs almost nothing. Each planner message is one small JSON request to an open model on Groq, which comes to a fraction of a cent. A friend's wedding planner shouldn't come with a monthly bill.

My Agent Session

https://dev.to/agent_sessions/building-cynthias-wedding-plans-khyaox

Prize Categories

Best Use of ElevenLabs: Scribe speech-to-text for English and Pidgin, Voice Design for the planner's voice, text-to-speech for spoken replies, the daily briefing and the RSVP thank-you, and my note read aloud.

It didn't crash. It just wouldn't wait.

Kane — Thu, 20 Aug 2026 09:14:48 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

StableRoute is a liquidity router on Stellar. The frontend is a Next.js app: quotes, pairs, admin controls, webhooks, audit logs. Most of it is forms and lists. The stats page is different. It is the room where you look at the protocol and ask a simple question: is it alive?

That page used to look like this.

useEffect(() => {
  const id = setInterval(refetch, POLL_MS);
  return () => clearInterval(id);
}, [refetch]);

Five seconds. Hit /api/v1/stats. Paint the pair count. Paint whether the router is paused. Do it forever. It is the kind of code you write when you want the dashboard to feel live, and you do not yet know what "live" costs.

I found out on a bad afternoon, not a dramatic one. The backend got slow. Not down, just sick. Latency climbed past five seconds. The stats page did not wait. setInterval does not care whether the last request came home. It fires on the clock.

Every five seconds refetch bumped a reload key. The fetch effect tore down the previous request, marked it cancelled, and started another. If the server needed eight seconds, the client never kept a request long enough to finish. The dashboard sat there asking, cancelling, asking again. From the server's side it looked like a client that would not stop poking a bruise.

When the API actually failed, it got worse. A 500 came back fast. The interval did not slow down. It kept hitting every five seconds. The UI flipped from error to loading to error. The alert unmounted and remounted. The page flickered. Anyone with the tab open became part of the outage.

That is the bug. It did not throw. It did not panic a contract. It just refused to be kind when the system needed kindness.

The fix was to stop treating time as the thing that drives the network.

I threw out setInterval and wrote useBackoffInterval. The idea is small enough to hold in your head. A poll is allowed to schedule the next poll only after the current one has settled. Settled means success or error. While status is idle or loading, nothing is scheduled. One request in flight. No pile-up. No cancelled work eating the only response you were going to get.

Failures remember themselves. A ref counts them, not React state, so counting a failure does not itself retrigger the effect. First error waits ten seconds. Then twenty. Then forty. Then it stops at sixty. The formula is the boring one everyone should have used from the start:

delay = Math.min(baseMs * 2 ** failureCount, maxMs)

The first success zeros the counter. The cadence comes back to five seconds without anyone pressing Retry. The page still has a Retry button, because a human should be able to say "try now" without waiting for the backoff clock. Automatic recovery is not the same as trapping someone in a delay.

There was a quieter bug inside the quieter bug. If you put callback in the effect deps, every new function identity kills the timer and starts another. Polling becomes jitter. If you freeze the callback, you poll with a stale closure. The way through is the unfashionable one: keep the latest callback in a ref, update it every render, and let the effect depend on status and timing, not on the function you plan to call.

const callbackRef = useRef(callback);
callbackRef.current = callback;

useEffect(() => {
  if (status !== 'success' && status !== 'error') return;
  // ... count, compute delay, schedule callbackRef.current
  return () => cancel(timeoutId);
}, [baseMs, cancel, maxMs, schedule, status]);

Unmount clears the timeout. I tested that by leaving, advancing fifteen seconds, and counting fetch calls. It stayed at one. That is the whole point of cleanup. Most people write it. Fewer people prove it.

The tests are the part I am actually proud of. I did not want to sit in a browser and wait for a minute of backoff. The hook takes schedule and cancel as arguments. In production those are setTimeout and clearTimeout. In Jest they are mocks. The test can say: you were told to wait 10,000ms, then 20,000, then 40,000, then 60,000, then 60,000 again. It can say: after an error, a success puts you back on 5,000. It can say: if the callback identity changes before the timeout fires, you call the new one, not the old one. It can say: idle and loading schedule nothing.

That is how the page stopped being a liability.

When the router is healthy, the tiles still update every five seconds. The "Updated just now" label still ticks. When the router is not healthy, the page tells you so once, holds the alert still, and backs away. The copy is honest: retrying automatically, with a longer delay, while the service is unavailable. It is not pretending everything is fine. It is also not kicking the thing that is already down.

I would not call this legendary. I would call it the work that makes software feel like it was written by someone who has been on both sides of a slow endpoint. The stats page is a small surface. It is also the first place an operator looks when they are worried. If that page panics, the rest of the product feels like it is panicking with it.

The win was not a clever algorithm. The win was that the dashboard learned how to wait.

PawGuard: A platform responsible for instant Abuse reporting and Community for Dogs in danger

Kane — Sun, 16 Aug 2026 18:19:45 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

PawGuard is a community web platform built to help protect dogs from abuse, severe neglect, and abandonment. When someone spots a dog in danger—whether chained without water, hit by a car, or dumped—they can submit a report in seconds with their GPS location, photos, urgency level, and even stay anonymous if needed. Those alerts are routed directly to local rescue contacts and volunteers via WhatsApp and email so someone can respond quickly.

In addition to emergency reports, the platform includes a noticeboard for lost and found pets (with instant printable flyers), an adoption and foster board, and practical guides on animal welfare.

My main goal with PawGuard was to remove the friction between seeing an animal suffering on the street and actually getting help to them. Too often, people don't know who to call or where to report neglect. PawGuard gives everyday people a direct, fast way to speak up and connects them with volunteers who can step in.

Demo

https://paw-guard-two.vercel.app

Code

https://github.com/comzzy-comzzy/PawGuard

How I Built It

I built PawGuard as a responsive single-page web application using React 18, TypeScript, and Vite, styled with Tailwind CSS and custom CSS animation keyframes.

A few key technical decisions shaped the build:

Zero-Delay Emergency Dispatch: Instead of locking emergency reports behind authentication or waiting on slow backend pipelines, I built client-side triage and routing that immediately bundles report details (GPS coordinates, urgency classification, incident notes) into structured WhatsApp and email dispatch links. Rescuers get the exact location and photos sent directly to their phones in real time.
Dynamic Audio & Custom Animations: Animal rescue platforms can often feel bleak and heavy. I used the Web Audio API for lightweight synthesized sound effects and custom keyframe animations for our canine mascots, creating an engaging, welcoming experience without bloating page load times.
Instant Printable Flyer Generation: For lost and abandoned dogs, we implemented client-side flyer generation directly in the browser so community members can print or share high-visibility search notices immediately.
Guided Intake Companion ("Picky"): I implemented an interactive conversation flow that walks stressed witnesses step-by-step through capturing the essential details needed for a rescue (exact landmarks, condition of the dog, immediate threats).

Best Use of Google AI — Antigravity with Gemini 3.7 (High Reasoning)

I leveraged Google Antigravity powered by Gemini 3.7 (High reasoning mode) as our core development and architectural copilot throughout the project.

With Gemini 3.7's deep multi-step reasoning:

• I architected resilient state flows for complex multi-module forms (abuse intake, foster applications, and lost pet postings).

• I rapidly designed and refined the interactive triage logic and geolocation fallbacks, ensuring reports are formatted accurately even when network conditions or location services are spotty.

• Antigravity helped me implement clean, fully typed TypeScript schemas and custom UI micro-interactions, cutting development time drastically while keeping the codebase modular and maintainable.

Prize Categories

Best Use of Google AI.

Team Submissions: Hi I'm a Solobuilder i havent added anyone yet to my team

StableRoute Frontend: Resilient Polling with Adaptive Exponential Backoff

Kane — Sat, 15 Aug 2026 10:30:04 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

StableRoute Frontend is the web interface for StableRoute, an open-source decentralized liquidity routing protocol built on the Stellar network. The application is built with Next.js (App Router), React, and TypeScript.
The platform provides a comprehensive suite of tools for traders, liquidity providers, and developers:
Payment and Liquidity Routing: An interactive interface for querying optimal swap and cross-currency path routing quotes across Stellar asset pools.
Liquidity Pool Management: Workflows to register, inspect, and configure supported asset pairs.
Real-Time Protocol Monitoring: A live status dashboard that polls protocol health, operational state (active vs. paused), and liquidity pool counts.
Developer and Infrastructure Controls: Management consoles for generating and revoking API keys, registering webhook event subscribers, viewing immutable system audit logs, and inspecting OpenAPI documentation.

Bug Fix or Performance Improvement

The Bug

In src/app/stats/Client.tsx, dashboard statistics were updated using a raw setInterval:useEffect(() => {
const id = setInterval(refetch, POLL_MS);
return () => clearInterval(id);
}, [refetch]);

This caused three critical issues:

Overlapping In-Flight Requests (Race Conditions) setInterval fired strictly on a 5-second timer regardless of how long the network request took. If a request stalled or took 6 seconds due to network lag, a second request was fired before the first one finished. This created stacked concurrent requests where an older, delayed response could overwrite newer data in React state.
Backend Hammering During Outages (Thundering Herd) When the backend experienced downtime, high load, or returned errors (500s/429s), the frontend never backed off. It continued hammering the failing endpoint every 5 seconds unabated, causing rate limits and thrashing the UI with re-rendering error alerts.
Timer Churn on Re-render Because refetch was in the dependency array, whenever parent component updates created a new function reference, the old interval was cleared and a new one started from scratch, disrupting regular polling cadence.

How I Fixed It

I replaced setInterval with a custom, lifecycle-aware scheduling hook called useBackoffInterval:

Settled-State Scheduling Instead of a blind clock, the hook waits for the request to settle into either 'success' or 'error' before scheduling the next timer. While a request is in the 'loading' state, no timers run, completely eliminating overlapping requests.
Exponential Backoff on Failures
We track consecutive failures using a ref (failureCountRef). When errors occur, the delay doubles progressively:
```
    ⎛          failures      ⎞
```
delay = min ⎝baseMs × 2 ,maxMs⎠

This increases the retry delay from 5s to 10s, 20s, 40s, and caps at 60s, giving backend services breathing room to recover.

Instant Cadence Recovery On the very first successful response (status === 'success'), the failure counter resets to 0 and the polling interval immediately returns to the standard 5-second cadence without requiring user intervention.
Ref-Stabilized Callback We stored the callback in useRef(callback) and synced it on every render (callbackRef.current = callback). This guarantees that the timer always executes the freshest callback closure without tearing down and restarting the active timer on unrelated UI re-renders.
Clean Unmount Teardown Each scheduled timer returns a cleanup function calling clearTimeout(timeoutId), preventing memory leaks and state updates on unmounted components.

Code

Pull Request / Branch: https://github.com/comzzy-comzzy/Stableroute-frontend/tree/performance/stats-polling-backoff
Target Repository: https://github.com/StableRoute-Org/Stableroute-frontend
Commit: 786106d62e4697aa4a9b536ab75bb320101edd9b (perf(stats): back off polling interval after repeated failures)

// Custom hook in src/app/stats/Client.tsx

export function useBackoffInterval(
status: PollStatus,
callback: () => void,
options: BackoffIntervalOptions = {}
): void {
const {
baseMs = POLL_MS, // 5,000ms
maxMs = MAX_POLL_MS, // 60,000ms
schedule = scheduleTimeout,
cancel = cancelTimeout,
} = options;

const callbackRef = useRef(callback);
const failureCountRef = useRef(0);
callbackRef.current = callback;

useEffect(() => {
// Only schedule next tick after a request settles
if (status !== 'success' && status !== 'error') return;

if (status === 'success') {
  failureCountRef.current = 0;
} else {
  failureCountRef.current += 1;
}

const delayMs =
  status === 'success'
    ? baseMs
    : Math.min(baseMs * 2 ** failureCountRef.current, maxMs);

const timeoutId = schedule(() => callbackRef.current(), delayMs);
return () => cancel(timeoutId);

}, [baseMs, cancel, maxMs, schedule, status]);
}

My Improvements

Custom useBackoffInterval Hook: Instead of hacking state inside the UI component, I decoupled retry scheduling into a reusable, lifecycle-aware hook.
Settled-State Gating: Scheduling only runs when the request status reaches 'success' or 'error'. While the status is 'idle' or 'loading', no timers are scheduled, strictly preventing concurrent in-flight requests.
Deterministic Exponential Backoff with Upper Bound: Consecutive failures increase the delay exponentially (baseMs * 2^failures), progressing from 10s to 20s, 40s, and capping at 60s (maxMs). As soon as an update succeeds, failureCount resets to 0 and normal 5-second polling immediately resumes.
Ref-Stabilized Callback Execution: Storing the refetch callback in a ref (callbackRef.current = callback) prevents timer teardown and re-creation when parent component props change across renders.
Inversion of Control for Deterministic Testing: The hook accepts optional schedule and cancel functions. This allowed writing deterministic unit tests that execute synchronously without flakey time-dependent assertions.
Comprehensive Unit and Integration Test Suite: Added comprehensive test coverage in src/app/stats/page.test.tsx verifying: .Base 5-second cadence on consecutive successful responses. .Delay doubling under network failures up to the 60-second limit. Immediate delay reset to 5 seconds upon recovery. .Prevention of duplicate alert renders during error backoff. .Clean timer cancellation on component unmount.
Contract Documentation: Documented the behavior, parameter options, and lifecycle guarantees in docs/hooks.md.

Best Use of Google AI

Throughout the development, architecture design, debugging, and testing phases of this project and related protocol repositories, I utilized Google Antigravity paired with the Gemini 3.5 Flash (High) model as a primary engineering assistant across multiple tech stacks (React/TypeScript, Rust Soroban, Solidity, and Node.js microservices).

Primary Project: Frontend Exponential Backoff & Lifecycle Safety (Stableroute-frontend) PR / Branch: performance/stats-polling-backoff (Commit 786106d) How Google AI Was Used: Root-Cause Diagnosis: Analyzed client network waterfall logs to isolate why client browsers flooded backend endpoints with requests during API degradation. Gemini 3.5 Flash (High) identified the unmanaged setInterval concurrency hazard. Hook Architecture: Formulated the useBackoffInterval pattern. The model advised storing active callbacks in useRef to prevent timer re-creation on renders while gating execution strictly to settled status states ('success' | 'error'). Deterministic Test Harness: Generated the Jest mock-timer test suite (src/app/stats/page.test.tsx), verifying exact progressive delay doubling (10s, 20s, 40s, 60s cap) and unmount cleanups.