DEV Community: Adil Khan

🎭 What if fictional characters could actually text you back?

Adil Khan — Sun, 12 Jul 2026 13:31:35 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Think of a character from a movie or show you loved. Not the show just them.

How long ago did you watch it? What's the one line, the one expression, the one moment you still remember?

After finishing a great series, I always wished I could keep talking to the characters instead of waiting months (or years) for the next season.

So I built the next best thing.

FandomDial is a WhatsApp-inspired AI chat application where you don't just read about a character you message them, hear their voice, and watch them remember your previous conversations.

Rather than recreating existing fictional characters, I designed three completely original personalities, each with their own conversational style, humour, and voice.

🟢 Gullu

Quiet. Dry. Brutally honest.

He barely talks but when he does, every sentence lands.

🔵 Sohail

The childhood friend who'll help you with almost anything...

...except lending you money.

Every conversation turns into an interrogation about your life choices.

🟠 Zaid

Endlessly confident.

King of jugaad.

Every disaster somehow has a shortcut solution even if it absolutely shouldn't.

Every character remembers previous conversations, generates responses with Google Gemini, and occasionally just like a real friend sends an unexpected voice note generated with ElevenLabs.

The goal wasn't to build another chatbot.

It was to build characters people would actually enjoy talking to.

Demo

🌐 Live Demo

https://fandomdial.onrender.com

Try this first:

Open Gullu, then send him something slightly rude like:

"Why are you like this?"

His reply usually tells people everything they need to know about the project.

Note: The project is hosted on Render's free tier. If the application has been idle, the first request may take around 30–50 seconds while the server wakes up.

Screenshot

Code

FanoyG / fandomdial-

WhatsApp-inspired AI chat platform with original characters, voice notes, conversation memory, Google Gemini, ElevenLabs, FastAPI, and Hexagonal Architecture.

FandomDial

A voice for every character worth talking to.

Chat with original AI characters that remember conversations, express unique personalities, and occasionally reply with realistic voice notes

🚀 Built for the DEV Weekend Challenge — Passion Edition (2026)

🎥 Demo

Live Demo: https://fandomdial.onrender.com

Note: hosted on Render's free tier, which sleeps after ~15 minutes of inactivity. First load may take 30-50 seconds to wake up.

What you're seeing

The screenshot below demonstrates a live conversation with Gullu, one of FandomDial's original AI characters.

Responses are generated using Google Gemini, synthesized with ElevenLabs when voice is triggered, and delivered through a WhatsApp-inspired interface that preserves conversational memory.

✨ Overview

FandomDial is a WhatsApp-inspired conversational platform where users interact with original AI characters, each designed with a unique…

View on GitHub

The repository includes:

Complete FastAPI backend
WhatsApp-style frontend
Hexagonal Architecture
Full engineering documentation
Deployment instructions
Detailed README explaining every architectural decision

How I Built It

From the beginning, I wanted this to feel like a real software project rather than a weekend prompt wrapper.

The application follows Hexagonal Architecture (Ports & Adapters) with SOLID principles, allowing the business logic to remain independent from AI providers, voice engines, and storage implementations.

The core services communicate only through interfaces (AIProvider, VoiceProvider, and SessionStore), making providers replaceable without touching the domain logic.

Tech Stack

FastAPI
Python
Google Gemini
ElevenLabs
HTML
CSS
JavaScript

🧠 Google Gemini

Google Gemini powers every conversation.

Each character has a carefully designed behavioral prompt built around a different conversational mechanism instead of simply "being funny."

Gullu uses deadpan honesty.
Sohail constantly questions your decisions.
Zaid solves everything with reckless confidence.

One challenge was conversation growth.

Passing the entire message history to the LLM eventually becomes slow and expensive.

To solve that, I built a Context Builder that summarizes older conversations while preserving recent exchanges, keeping token usage predictable without losing conversational memory.

During development I also encountered real 429 quota errors, which led me to implement an ordered fallback chain so conversations continue even when a preferred model becomes temporarily unavailable.

🎙️ ElevenLabs

ElevenLabs powers all voice responses.

Every character has a matched voice, and about 20% of replies are automatically delivered as voice notes instead of plain text.

That randomness isn't arbitrary.

A dedicated VoiceTriggerDecider controls when voice should be generated.

Before using it in the application, I validated the probability over 2,000 simulated message iterations to ensure the distribution matched the intended behavior.

Another unexpected challenge appeared when the ElevenLabs API returned HTTP 402 errors.

It turned out that community Voice Library voices aren't accessible through the free-tier API.

Instead of hardcoding voice IDs, I queried the authenticated account for available voices and dynamically assigned compatible ones to each character.

⚡ Performance & Reliability

Several engineering problems appeared once the application started feeling "real."

To solve them, I implemented:

Request-ticket playback, preventing older voice requests from interrupting newer ones.
Local audio caching, so replaying the same response never consumes another API call.
Latency masking, using lightweight filler audio only when generation exceeds a short threshold, making the application feel responsive even while AI responses are still being generated.

🚧 Design Trade-offs

Some production features were intentionally left out to keep the project achievable within a weekend.

Current limitations include:

Conversation sessions are stored in memory and reset when the server restarts.
Voice quality is limited by the free ElevenLabs tier.
Real-time voice calls were intentionally scoped out in favor of asynchronous voice notes.

Because storage, AI providers, and voice engines are all abstracted behind interfaces, these improvements can be added later without changing the application's core architecture.

What I Learned

Building the interface was actually the easy part.

Making conversations feel believable turned out to be much harder.

The biggest challenges weren't writing prompts they were:

managing conversation context,
controlling latency,
handling API failures gracefully,
preventing overlapping voice playback,
and making voice notes feel spontaneous without exhausting API quotas.

Those engineering decisions ended up shaping the architecture far more than any single feature.

Prize Categories

🏆 Best Use of Google AI

Google Gemini powers all dialogue generation, contextual memory, model fallback handling, and personality-driven conversations.

🏆 Best Use of ElevenLabs

ElevenLabs provides realistic voice synthesis, smart voice-note generation, caching, and race-condition-safe playback.

Final Thoughts

This started as a weekend hackathon project.

By Sunday night, it had become something much bigger.

I no longer see FandomDial as just an AI chat application.

I see it as the beginning of a platform where writers could publish original AI-powered characters, let readers interact with them, and discover which personalities people genuinely connect with before investing months writing a book, game, or screenplay.

Whether it remains a hackathon project or grows into something more, building it reminded me that memorable software isn't created by APIs alone.

It's created by thoughtful engineering and by designing experiences people actually want to come back to.

Thanks for reading. ❤️

The Logic vs. Syntax Gap: A Backend DSA Journey, Documented

Adil Khan — Mon, 06 Jul 2026 09:54:06 +0000

Why This Series Exists

I froze on a simple dictionary access problem for 4 minutes last week.

Not because I didn't understand the pattern. I knew exactly what needed to happen: group by key, track the max, and return matching entries. But when it came to actually writing it, my fingers hesitated. I second-guessed syntax that I should have known cold.

That gap — between understanding a concept and executing it under pressure — is what quietly fails people in technical interviews and real-world backend engineering. It is rarely a lack of knowledge. It is execution lag.

[ Mental Logic ] ─── ( 4-Minute Execution Lag ) ───> [ Working Production Code ]

This series isn't another generic DSA course. There are already excellent, polished resources for that — NeetCode, Striver, take your pick.

Instead, this is a documented, honest account of me closing my own execution gap — problem by problem, mistake by mistake, with nothing filtered out.

What You'll Find Here

Real diagnostic sets — patterns I build to test where I actually stand. Not curated textbook problems, but the exact patterns that trip backend engineers up: aggregates, lambda sorting, nested dictionary access, loop tracking variables.
Timed attempts, not polished solutions — if I fumble, get an error, or blank out, you'll see it.
The reasoning, not just the answer — why a pattern works, and how the same logic scales when you move from a script to a real backend system.

Where I'm Starting

Before jumping into complex algorithms, I built a 15-question set covering three core areas:

List aggregates
Dictionary + lambda operations
String processing

Here's one example from the set:

Input  = [("Alice", 85), ("Bob", 92), ("Charlie", 78), ("David", 92)]
Output = ["Bob", "David"]

# Task: Return the names of students with the highest score.

It reads easy. Try writing it on a blank screen in under 60 seconds without looking anything up. That's the actual test — and that time constraint is where most developers, myself included, find their real gaps.

👉 Grab the full 15-question set here to test yourself

Follow Along

I'm working through this in public — partly for accountability, partly because the messy middle of learning is more useful to see than a polished end result.

If you're a developer on a similar path, this series will help you audit your own execution speed.
If you're a hiring manager looking for engineers who care about clean execution over memorized patterns, this is a live view into how I think.

Next post: breaking down exactly where I got stuck on the 15-question set, and the fixes that closed the gap.

Tags: #python #dsa #beginners #softwareengineering

How to Learn SOLID Principles Through Real Python Projects (2026 Guide)

Adil Khan — Fri, 03 Jul 2026 13:36:47 +0000

If you have ever tried to learn SOLID principles, you have probably run into the same boring textbook examples: a Shape class with a Square subclass, or a Bird class that cannot fly.

Let’s be honest: Nobody builds a flying bird app at a real backend job.

When you are trying to learn Object-Oriented Programming (OOP) and Clean Code architectures, theoretical definitions just don't stick. You learn logic by building real systems, making mistakes, breaking things, and refactoring them with intent.

Welcome to The Practical SOLID Series. In this hands-on course, we skip the textbook definitions. Instead, we take messy, real-world Python scripts and systematically refactor them into clean, production-pattern prototypes.

🗺️ The Complete 12-Project SOLID & Test-Driven Roadmap

This series is broken into four ascending difficulty tiers, moving you step-by-step from raw in-memory mutations to distributed production architecture.

[ LEVEL 4: SYSTEM DESIGN & PRODUCTION ] -> Projects 10, 11, 12 (Async, Live SQL, Packaging)
                  ▲
                  │
[ LEVEL 3: MIDDLEWARE & CONTRACTS ]    -> Projects 7, 8, 9   (Generators, Decorators, ABCs)
                  ▲
                  │
[ LEVEL 2: DECOUPLED INJECTION ]       -> Projects 4, 5, 6   (Multi-file, DI, ORM Relationships)
                  ▲
                  │
[ LEVEL 1: IN-MEMORY MUTATION ]        -> Projects 1, 2, 3   (State Machines, References, Slices)

🟢 Level 1: Pure In-Memory State & Isolation

Project 1: The High-Throughput Vending Metrics Engine — Mastering the Single Responsibility Principle (SRP), creating deep-copy memory isolation layers, and setting up strict input validation.
Project 2: The Multi-Currency In-Memory Ledger Wallet — Implementing the Open/Closed Principle (OCP) using extensible mapping tables, managing Interface Segregation (ISP) via read-only wrappers, and unlocking testability through Dependency Inversion (DIP).
Project 3: The Stateful Notification State Machine — Managing isolated state changes and memory footprint safely across system-wide event flows.

🟡 Level 2: Multi-File Decoupling & Relational Persistence

Project 4: The Decoupled E-Commerce Cart & Billing Bridge — Breaking monoliths into distinct files while maintaining clean dependency compilation.
Project 5: The Multi-Service Library Index Adapter — Handling deep subclass substitution to actively demonstrate and validate the Liskov Substitution Principle (LSP).
Project 6: The Relational Transaction Auditing Engine — Mapping mock data streams to relational models and structural databases.

🟠 Level 3: Middleware Interception & Contract Abstraction

Project 7: The Dynamic Multi-Gateway Payment Router — Using Python generators and lookup plugins to extend payment methods seamlessly.
Project 8: The Log Streaming & Security Interceptor Engine — Using advanced Python decorators to wrap security contracts and trace analytics without changing business logic.
Project 9: The Validated Enterprise Router Gateway — Building absolute protocol abstractions via Python Abstract Base Classes (ABCs).

🔴 Level 4: Full-Stack Production System Engineering

Project 10: The High-Concurrency Flight Fare Engine — Tackling asynchronous operations and handling thread race conditions.
Project 11: The Live Production Microservices API Gateway — Connecting your local prototypes to a live SQL pipeline with production configurations.
Project 12: The Automated Pipeline Verification Suite — Bundling your engine as a distributable package and enforcing unit test regression coverage.

💻 The Open-Source Code Sandbox

Don't just read the articles—run the code yourself. You can clone the complete project vault directly from GitHub:

# Clone the open-source repository
git clone https://github.com/FanoyG/python-oop-solid-projects.git

# Move inside the project directory
cd python-oop-solid-projects

Inside the repository, every single project has dedicated Git tags (like p1-mvp, p2-mvp, and p2-solid-complete) so you can literally watch the code evolve step-by-step on your local computer.

🧠 Why This Project-First Approach Works

You See the "Why": We don't just show you perfect code. We show you the fragile, messy code first, simulate a problem (like a system crash or a race condition), and watch it break. You learn SOLID because you see exactly what disaster happens when you ignore it.
Honest Engineering Over Overclaims: We don't pretend our prototypes are magical enterprise systems. Every project includes a "What's Still Broken" section highlighting concurrency bottlenecks, memory limitations, and architectural tradeoffs. That is how real-world senior engineers think.
Built in Public: This series is a living portfolio designed to showcase system-thinking over superficial code streaks.

Are you ready to stop reading theory and start building? Bookmark this index page, grab the GitHub repo, and let's jump into the code!

Drop a comment below: Which SOLID principle trips you up the most when writing real backend logic?

UUIDv4 vs UUIDv7 in PostgreSQL: A B-Tree Index Performance Deep Dive

Adil Khan — Fri, 12 Jun 2026 07:50:07 +0000

Migrating MedicoSync: UUIDv4 → UUIDv7

(Why I'm doing it, and why it's cheap to defer)

When building MedicoSync (an open-source FastAPI + PostgreSQL medical records platform), hiding internal database IDs was a key requirement on Day 1 [source: 0.1.1].

The Problem with Integers: Simple sequential numbers like /api/v1/patients/42 leak data. A malicious user can guess the next numbers and scan your endpoints like /43, /44, or /45.
The Vulnerability: This mistake is called an IDOR (Insecure Direct Object Reference) vulnerability.

To fix this security risk, I used standard UUIDv4 keys [source: 0.1.1]. It stopped the endpoint scanning problem perfectly. However, random text strings create a hidden slowdown inside relational database storage engines over time.

THE PROBLEM: B-Tree Page Splits with UUIDv4

PostgreSQL keeps database rows organized on disk using a B-Tree index map. Think of your drive storage space as numbered storage boxes that are already completely full:

┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│   Box 1   │ │   Box 2   │ │   Box 3   │ │   Box 4   │
│  [ FULL ] │ │  [ FULL ] │ │  [ FULL ] │ │  [ FULL ] │
└───────────┘ └───────────┘ └───────────┘ └───────────┘

Because UUIDv4 is fully random, a brand-new row ID might belong right in the middle of Box 2. PostgreSQL cannot just append it to the end. It must force Box 2 open, execute a B-Tree page split, and reorganize the disk layout:

┌───────────┐ ┌───────────┐┌───────────┐ ┌───────────┐ ┌───────────┐
│   Box 1   │ │  Box 2A   ││  Box 2B   │ │   Box 3   │ │   Box 4   │
│  [ FULL ] │ │  [ HALF ] ││  [ HALF ] │ │  [ FULL ] │ │  [ FULL ] │
└───────────┘ └───────────┘└─────▲─────┘ └───────────┘ └───────────┘
                                 │
                     [ New random row forced here. ]
                     [ Everything else shifts down. ]

When tables grow to 1 million+ rows, this constant random disk fragmentation slows down write speeds.

THE FIX: UUIDv7's Time-Ordered Prefix

UUIDv7 solves this problem by arranging its internal layout chronologically:

Layout = [ 48-bit UNIX Timestamp ][ 80 Random Bits ]

Because the prefix is time-prefixed, every newly generated UUIDv7 is greater than the last one. PostgreSQL can now cleanly append new rows directly to the very end of the index tree:

┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│   Box 1   │ │   Box 2   │ │   Box 3   │ │   Box 4   │ │   Box 5   │
│  [ FULL ] │ │  [ FULL ] │ │  [ FULL ] │ │  [ FULL ] │ │ [ NEW ROW]│
└───────────┘ └───────────┘ └───────────┘ └───────────┘ └─────▲─────┘
                                                             │
                                                  [ Appends cleanly ]
                                                  [ with zero splits]

No page splits, no disk index reorganizing, and smooth data writing performance at scale.

THE STORAGE TRADE-OFF

You must balance system storage memory against data security:

UUID (v4 or v7) ➔ Consumes 16 bytes of disk and RAM index space.
BIGINT ➔ Consumes 8 bytes of disk and RAM index space.

UUIDs take up double the index storage space compared to standard integers, but they keep sensitive resources hidden.

RESOLVING QUERY OVERHEAD: THE DUAL-ID PATTERN

Fixing the write path with UUIDv7 doesn't fully close the topic. There's a related pattern worth knowing about for systems like this: the internal ID / external ID split, where a lightweight BIGINT is used for internal joins and lookups, while a UUID is exposed externally as the public-facing identifier.

A 16-byte UUID is more expensive to push through CPU cache lines and join operations than an 8-byte integer. At a high enough query volume, decoupling "what the database uses internally" from "what the API exposes externally" can shave meaningful overhead off hot-path queries.

┌────────────────────────────────────────────────────────┐
│                   INCOMING API REQUEST                 │
│              GET /api/v1/patients/[ UUID ]             │
└───────────────────────────┬────────────────────────────┘
                            │ Public Route Boundary
                            ▼
┌────────────────────────────────────────────────────────┐
│                   BACKEND SERVICE LAYER                │
│    1. Match external public 16-byte UUID               │
│    2. Extract internal private 8-byte BIGINT (Fast)    │
└───────────────────────────┬────────────────────────────┘
                            │ Internal Network Only
                            ▼
┌────────────────────────────────────────────────────────┐
│                   POSTGRESQL DATABASE ENGINE           │
│     Executes blazing fast JOINs via internal BIGINT    │
└────────────────────────────────────────────────────────┘

1. The Internal ID (BIGINT / 8 Bytes): Acts as the primary database key for table lookups and internal resource joins. This key never leaves your private backend network.
2. The External ID (UUID / 16 Bytes): A standalone unique column used solely for frontend payloads and public routing links to hide database context from automated scanners.

📝 Note: I haven't implemented this in MedicoSync — at MVP scale, the query-cost difference is negligible compared to the UUIDv7 write-path fix. But I saw this pattern often, and it's the natural next thing to evaluate if MedicoSync's traffic ever grows to where join performance on the patients/records tables becomes a bottleneck. Worth flagging as the "next escalation point" if you're designing a similar system and expect serious scale early. I will publish a full step-by-step implementation guide on this dual-ID abstraction layer next week!

ARCHITECTURAL SUMMARY: WHICH ONE SHOULD YOU CHOOSE?

Choosing between these options depends on the current lifecycle state of your database project:

Scenario 1: Starting a Brand New Project ➔ Use native UUIDv7. It provides security for public endpoints out of the box while naturally preserving index write performance on disk.
Scenario 2: Inheriting a Legacy System (Stuck on UUIDv4) ➔ Do not rush into a high-risk schema rewrite. You can protect endpoints against scanning attacks by embedding tracking metadata directly inside secure, encrypted JWT (JSON Web Token) Payloads. (I will be breaking down this pattern in an upcoming article!).
Scenario 3: High-Throughput Systems ➔ If your system writes millions of entries a day, decouple lookup stress entirely by adding a distributed caching store like Redis to protect your primary database tables.

THE ARCHITECTURAL VERDICT

At MedicoSync's current MVP scale, the UUIDv4 → UUIDv7 gap isn't an urgent fire [source: 0.1.1].

The reason it's cheap to defer is a foundational choice made on Day 1: Alembic migrations [source: 0.1.1]. Because the schema is wrapped in Alembic from the start, updating the SQLAlchemy model's UUID generation strategy and auto-generating the migration is a scaffolded, low-risk change — not a rewrite [source: 0.1.1].

Engineering isn't about shipping a flawless schema on day one [source: 0.1.1]. It's about building something clean enough to evolve when you learn there's a better way [source: 0.1.1].

LET'S CONNECT

🛠️ Building a secure, high-performance Python/FastAPI backend, data pipeline, or custom workflow automation engine? Let’s design your platform together:
👉 Work with me on Fiverr: Fiverr Profile

💾 Explore the full tested architecture codebase:
👉 GitHub Profile: FanoyG GitHub

🛠️ Working through similar backend/schema decisions? Happy to chat — find me here on dev.to or connect on LinkedIn.