Shoaib Ahmed

Shoaib AhmedJul 11, 2026

𝗖𝗮𝗻 𝗔𝗜 𝗯𝗲𝗰𝗼𝗺𝗲 𝗺𝗼𝗿𝗲 𝘀𝘂𝘀𝘁𝗮𝗶𝗻𝗮𝗯𝗹𝗲 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝘀𝗮𝗰𝗿𝗶𝗳𝗶𝗰𝗶𝗻𝗴 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲? 🌱 That was the goal of my Final Year Project. As AI models continue to grow in size and computational demand, my goal was to explore whether model compression could reduce 𝗲𝗻𝗲𝗿𝗴𝘆 𝗰𝗼𝗻𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗖𝗢𝟮 𝗲𝗺𝗶𝘀𝘀𝗶𝗼𝗻𝘀 without sacrificing performance. To validate this, I evaluated 𝟭𝟭 𝗖𝗡𝗡 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀 across 𝟰 𝗰𝗼𝗺𝗽𝗿𝗲𝘀𝘀𝗶𝗼𝗻 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀, resulting in 𝟰𝟰 𝗲𝘅𝗽𝗲𝗿𝗶𝗺𝗲𝗻𝘁𝘀. Training that many models wasn't easy. I started on my RTX 3070, but with each experiment taking 𝟭𝟬–𝟭𝟮 𝗵𝗼𝘂𝗿𝘀, I moved to 𝗥𝘂𝗻𝗣𝗼𝗱, which significantly accelerated the research. I built 𝗚𝗿𝗲𝗲𝗻𝗔𝗜, an end-to-end platform for benchmarking model compression and measuring its environmental impact using 𝗖𝗼𝗱𝗲𝗖𝗮𝗿𝗯𝗼𝗻. 𝗪𝗵𝗮𝘁 𝗚𝗿𝗲𝗲𝗻𝗔𝗜 𝗱𝗼𝗲𝘀:  • Benchmarks 𝗣𝗿𝘂𝗻𝗶𝗻𝗴, 𝗤𝘂𝗮𝗻𝘁𝗶𝘇𝗮𝘁𝗶𝗼𝗻, 𝗞𝗻𝗼𝘄𝗹𝗲𝗱𝗴𝗲 𝗗𝗶𝘀𝘁𝗶𝗹𝗹𝗮𝘁𝗶𝗼𝗻, 𝗮𝗻𝗱 𝗛𝘆𝗯𝗿𝗶𝗱 𝗖𝗼𝗺𝗽𝗿𝗲𝘀𝘀𝗶𝗼𝗻  • Tracks 𝗮𝗰𝗰𝘂𝗿𝗮𝗰𝘆, 𝗹𝗮𝘁𝗲𝗻𝗰𝘆, 𝗺𝗼𝗱𝗲𝗹 𝘀𝗶𝘇𝗲, 𝗲𝗻𝗲𝗿𝗴𝘆 𝗰𝗼𝗻𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻, 𝗮𝗻𝗱 𝗖𝗢𝟮 𝗲𝗺𝗶𝘀𝘀𝗶𝗼𝗻𝘀  • Compares all 𝟭𝟭 𝗖𝗡𝗡 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀  • Deploys optimized models to 𝗔𝗻𝗱𝗿𝗼𝗶𝗱 𝘂𝘀𝗶𝗻𝗴 𝗢𝗡𝗡𝗫 𝗥𝘂𝗻𝘁𝗶𝗺𝗲 𝗥𝗲𝘀𝘂𝗹𝘁𝘀: 📉 𝟵𝟳.𝟳𝟮% 𝗺𝗼𝗱𝗲𝗹 𝘀𝗶𝘇𝗲 𝗿𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 using Knowledge Distillation ⚡ 𝟵𝟮.𝟯𝟲% 𝗹𝗼𝘄𝗲𝗿 𝗶𝗻𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗹𝗮𝘁𝗲𝗻𝗰𝘆 🌱 𝟳𝟯.𝟴% 𝗺𝗲𝗮𝗻 𝗖𝗢𝟮 𝗿𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 with Hybrid Compression 🎯 𝗢𝗻𝗹𝘆 𝟬.𝟮𝟭 𝗽𝗲𝗿𝗰𝗲𝗻𝘁𝗮𝗴𝗲 𝗽𝗼𝗶𝗻𝘁 𝗮𝗰𝗰𝘂𝗿𝗮𝗰𝘆 𝗱𝗿𝗼𝗽 with Quantization 📊 𝟱𝟱.𝟭% 𝗮𝘃𝗲𝗿𝗮𝗴𝗲 𝗖𝗢𝟮 𝗿𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 across all 44 experiments One key finding: 𝘁𝗵𝗲𝗿𝗲 𝗶𝘀 𝗻𝗼 𝘂𝗻𝗶𝘃𝗲𝗿𝘀𝗮𝗹 𝗰𝗼𝗺𝗽𝗿𝗲𝘀𝘀𝗶𝗼𝗻 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆. ResNet benefited from pruning due to redundant parameters, while MobileNet already optimized for efficiency performed better with quantization. Finally, I deployed the compressed 𝗥𝗲𝘀𝗡𝗲𝘁-𝟭𝟴 𝗺𝗼𝗱𝗲𝗹 to Android with 𝗢𝗡𝗡𝗫 𝗥𝘂𝗻𝘁𝗶𝗺𝗲, enabling real-time on-device inference without the cloud. This project reinforced one idea: 𝗧𝗵𝗲 𝗳𝘂𝘁𝘂𝗿𝗲 𝗼𝗳 𝗔𝗜 𝗶𝘀𝗻'𝘁 𝗷𝘂𝘀𝘁 𝗮𝗯𝗼𝘂𝘁 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗹𝗮𝗿𝗴𝗲𝗿 𝗺𝗼𝗱𝗲𝗹𝘀 𝗯𝘂𝘁 𝗮𝗯𝗼𝘂𝘁 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗺𝗼𝗱𝗲𝗹𝘀 𝘁𝗵𝗮𝘁 𝗮𝗿𝗲 𝗲𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁, 𝗱𝗲𝗽𝗹𝗼𝘆𝗮𝗯𝗹𝗲, 𝗮𝗻𝗱 𝗲𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝗮𝗹𝗹𝘆 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗹𝗲. I'd love to hear your perspective: 𝗪𝗶𝗹𝗹 𝗚𝗿𝗲𝗲𝗻 𝗔𝗜 𝗯𝗲𝗰𝗼𝗺𝗲 𝘀𝘁𝗮𝗻𝗱𝗮𝗿𝗱 𝗶𝗻 𝗺𝗮𝗰𝗵𝗶𝗻𝗲 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴, 𝗼𝗿 𝘄𝗶𝗹𝗹 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗲 𝘁𝗼 𝗼𝘂𝘁𝘄𝗲𝗶𝗴𝗵 𝘀𝘂𝘀𝘁𝗮𝗶𝗻𝗮𝗯𝗶𝗹𝗶𝘁𝘆? Thanks to Muhammad Zaeem Ul Hassan for helping me access cloud GPUs, which significantly accelerated this research. #GreenAI #MachineLearning #DeepLearning #PyTorch #ComputerVision #ONNX #EdgeAI #ModelCompression #SustainableAI #ArtificialIntelligence #FinalYearProject #BuildInPublic

Shoaib AhmedJun 15, 2026

A heading change shouldn't need a deployment. 𝗦𝗼 𝗜 𝗯𝘂𝗶𝗹𝘁 𝗺𝘆 𝗼𝘄𝗻 𝗖𝗠𝗦. Frontend-only Next.js app — no backend. But the site had 15–20 headings per page, SEO meta tags, button text, button links, blog posts. All of it needed to be editable without touching code. Built it on Supabase. Three tables: 𝘀𝗶𝘁𝗲_𝗰𝗼𝗻𝘁𝗲𝗻𝘁 — every heading, button label, button link, body text. 15–20 rows per page. 𝘀𝗶𝘁𝗲_𝘀𝗲𝘁𝘁𝗶𝗻𝗴𝘀 — SEO meta title and description for every page. 𝗽𝗼𝘀𝘁𝘀 — full MDX blog content. New article = new row. Non-technical teams manage all of it from an admin portal. 𝗭𝗲𝗿𝗼 𝗱𝗲𝗽𝗹𝗼𝘆𝘀 𝗳𝗼𝗿 𝗮𝗻𝘆 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗼𝗿 𝗦𝗘𝗢 𝗰𝗵𝗮𝗻𝗴𝗲. ISR handles the delivery. Pages are pre-rendered and cached. Supabase updates → Next.js revalidates automatically. No rebuild, nothing. The painful part — 𝗜 𝗹𝗼𝘀𝘁 𝗮𝗹𝗹 𝘁𝗵𝗲 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗼𝗻𝗰𝗲 because I hadn't seeded the DB properly. Recovered it from uncommitted code. Close call. 𝗔𝗹𝘄𝗮𝘆𝘀 𝗸𝗲𝗲𝗽 𝗮 𝘀𝗲𝗲𝗱 𝗳𝗶𝗹𝗲 𝗶𝗻 𝘆𝗼𝘂𝗿 𝗿𝗲𝗽𝗼. Swipe through for the full architecture breakdown. How do you handle content updates in your apps — hardcoded, headless CMS, or something custom? Drop it below. #nextjs #supabase #webdev #buildinpublic #reactdeveloper #indiedev #frontenddeveloper #cms

Shoaib AhmedJul 18, 2026

I built a full AI assistant into our internal company dashboard. 𝗡𝗼𝘁 𝗮 𝗯𝗼𝗹𝘁-𝗼𝗻 𝗰𝗵𝗮𝘁 𝘄𝗶𝗱𝗴𝗲𝘁. The kind where you can attach a PDF, ask questions about it, generate an image, and then say "turn this into a PowerPoint" — and get an actual .pptx file back. All in one thread. The architectural decision that shaped everything: all LLM calls live in Next.js server routes. The NestJS backend 𝗻𝗲𝘃𝗲𝗿 𝘁𝗼𝘂𝗰𝗵𝗲𝘀 𝗮𝗻 𝗟𝗟𝗠 𝗦𝗗𝗞 𝗮𝘁 𝗮𝗹𝗹. Its only job is persistence, S3 storage, content extraction, and rendering the actual files. I made that call early and deliberately. Keep the AI surface thin. Let the backend own the durable stuff. If we swap models tomorrow, the backend doesn't care. The thing nobody puts in a requirements doc — 𝗰𝗼𝗻𝘁𝗲𝘅𝘁-𝘄𝗶𝗻𝗱𝗼𝘄 𝗯𝘂𝗱𝗴𝗲𝘁𝗶𝗻𝗴. Once you support multiple file attachments per conversation, extracted text accumulates fast. Three PDFs and two DOCX files can easily blow past GPT-4's context limit. I hit that wall in testing, and instead of waiting for it to happen in production, I built a budgeting system. Older content degrades gracefully — images fall back to text descriptions, documents truncate under a cumulative character cap. Every request stays within limits without silently dropping something the user uploaded. 𝗡𝗼𝘁𝗵𝗶𝗻𝗴 𝗶𝗻 𝘁𝗵𝗲 𝗯𝗿𝗶𝗲𝗳 𝗺𝗲𝗻𝘁𝗶𝗼𝗻𝗲𝗱 𝗶𝘁. 𝗜 𝗷𝘂𝘀𝘁 𝗸𝗻𝗲𝘄 𝗶𝘁 𝘄𝗼𝘂𝗹𝗱 𝗯𝗿𝗲𝗮𝗸 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗶𝘁. Swipe through for the full breakdown — architecture split, file pipeline, streaming implementation, S3 security, and document generation flow. What's the most non-obvious thing you've built to make an AI feature actually production-ready? #nextjs #nestjs #openai #buildinpublic #webdev #fullstackdeveloper #aiengineering #typescript #reactdeveloper