showcase

Shipped: Responsive developer portfolio built from scratch

Built my personal developer portfolio, built from scratch using HTML, CSS, and JavaScript — with no frameworks or templates. - Clean & responsive multi-page design - Interactive project filtering & FAQ - GitHub activity integration - Terminal-style hero section - Contact form with validation - Fully responsive across all screen sizes

Built an AI-Powered Industrial Vision Inspection System

I built a simulated manufacturing environment in Unity to demonstrate automated visual quality inspection. The simulation connects to a Python/FastAPI + OpenCV computer vision backend, which analyzes products and classifies them as PASS or FAIL. Defective products are then automatically identified and removed from the production line. Built this as a way to explore how computer vision and AI can be applied to industrial quality control. Would love to hear your feedback!

Portfolio drop 🕷️

Finally shipped my personal portfolio. Projects, experiments, tech + a little Spider-Man energy. Rate it /10? 🔗 https://nitinpatidar.vercel.app/ Your friendly neighborhood developer has entered the web. 🕷️

Shipped: AI-Powered Product Review Analyzer

I built an AI-powered Product Review Analyzer that turns customer reviews into useful insights. The goal was to make it easier to understand what customers actually think about a product without manually going through hundreds of reviews. What it does Analyzes product reviews Identifies customer sentiment Extracts useful insights from review data Presents the results through a simple interface What I learned 🤖 Working with AI and NLP 📊 Processing real-world review data 💻 Building an end-to-end AI application 🎨 Improving UI/UX for an AI tool 🧩 Turning an idea into a working product I'm still improving the project and would love feedback from other builders. GitHub: https://github.com/nidhishreebai-gif/product-review-analyzer What feature would you add to make this more useful? 🚀

Abdul Web Agency

abdulwebagency.online abdulwebagency.online/aiconsultation

Built Snaptic: AI powered Attendance management system

Ever wondered how much time teachers spend taking attendance every day? We built Snaptic , an AI-powered attendance system that makes the process faster and easier. 📸 A teacher simply points the camera at the class. 🤖 Snaptic recognizes the students automatically. ✅ Attendance is marked in real time. 📊 Teachers can then review the attendance and make changes if needed. The best part? The face recognition happens directly on the device, so classroom video doesn't need to be sent to a server for recognition. 🔒 Snaptic also includes: 👨‍🏫 Teacher & student accounts 📚 Class management 📅 Class scheduling 📈 Attendance records & analytics ✋ Manual attendance as a fallback 🌙 A clean, modern interface 👨‍💻 Built by Tushar Sahu 🔗 Try Snaptic: https://snaptic-one.vercel.app 💻 GitHub: https://github.com/Tushar-Sahu7/Snaptic

I made an Inteligent lead system in python.

Intelligent Lead Management System Introduction The Intelligent Lead Management System is a Python-based project designed to help businesses manage potential customers, also known as leads. It allows users to add, update, delete, search, and filter lead information through a simple menu-driven system. The main goal of the project was to use Python programming concepts to solve a real-world business problem. Lead Information Each lead contains important information such as: Name Contact Number Email Job or Profession Budget Current Status Each lead is stored as a Python dictionary, while multiple leads are stored inside a list. For example: Main Features 1. Add Lead The user can enter a new lead's information, and the system stores it in the leads list. 2. Update Lead Existing information can be changed. For example, a lead's status can be changed from "New" to "Contacted" or "Interested." 3. Delete Lead The user can remove a lead when the information is no longer needed or the lead is no longer relevant. 4. Search Lead The system allows the user to search for a specific person, such as Ali, and display all of that lead's information. 5. Filter Leads Leads can be filtered according to specific conditions, such as status, job, or budget. For example, the user can find all leads with a budget above 50,000. Intelligent Command Feature One of the important parts of the project is the intelligent command functionality. Instead of always using menu options, the user can enter simple commands such as: The system identifies the command and searches for the lead named Ali. The basic process is: Lead Status The system can track the stage of each lead, for example: A lead can also become "Not Interested" or "Lost." This helps businesses know which potential customers require follow-up. Python Concepts Used The project combines several important Python concepts: Variables Lists Dictionaries Functions if , elif , and else for and while loops User input Type conversion Searching and filtering Data manipulation Functions such as add lead() , update lead() , delete lead() , search lead() , and filter leads() help keep the program organized and easier to manage. Real-World Purpose This type of system can be useful for businesses such as software companies, marketing agencies, freelancers, consultants, real-estate businesses, and other service providers. Instead of keeping customer information scattered, the system keeps everything organized in one place and makes it easier to find and manage leads. Future Improvements The project can later be upgraded with: A database Graphical interface AI-powered search Automatic lead scoring Email or WhatsApp integration Follow-up reminders Google Sheets integration Analytics and dashboards Conclusion The Intelligent Lead Management System demonstrates how basic Python concepts can be combined to create a practical business solution. It goes beyond simply storing data by providing searching, filtering, updating, status tracking, and an intelligent command feature. It provides a strong foundation that can later be developed into a complete AI-powered CRM and lead management system.

Spot the Scam — AI Phishing & Scam Awareness Trainer 🛡️

Shipped my AI-powered phishing/scam awareness trainer! 🚀 Paste any suspicious message (email, SMS, WhatsApp) and it flags red flags instantly using AI — plus a quiz mode to test your scam-spotting skills. Combined my SOC/networking background with AI to build something practical, not just another demo. Stack: - Frontend: Plain HTML/CSS/JS - Backend: Vercel serverless function (api/analyze.js) - AI: Groq API (openai/gpt-oss-20b) Also building a companion Chrome extension for on-the-fly message analysis. 🔗 Try it live: https://security-awareness-trainer.vercel.app/ Would love feedback — try pasting a scammy message and see what it catches! 👇 ai security saas

InkRead — Handwriting to Digital Text ✍️

InkRead is an AI-powered handwriting recognition application built using fine-tuned TrOCR, OpenCV, FastAPI and Next.js. It supports handwritten word recognition as well as multi-line text through an adaptive segmentation pipeline. Tech: PyTorch • TrOCR • OpenCV • FastAPI • Next.js Model accuracy: 91.20% 🔗 GitHub: https://github.com/rihan-mdk/InkRead.git

Building Selah: A Modern Offline Bible App with Flutter 📖

🚀 I built a Bible app with Flutter over the weekend. I’ve been working on something I’m really excited about Selah. I wanted to build a Scripture experience that feels calm, beautiful, and intentional, while still being fast and fully usable offline. Here’s what I ended up building: 📖 7 complete Bible translations bundled directly into the app, with 31,000+ verses each. I used Dart Isolates to handle the parsing in the background so it doesn’t slow down the UI. 🔥 A custom 3D-style onboarding experience built entirely with Flutter’s CustomPainter —68 ember particles, 90 twinkling stars, aurora effects, floating Scripture cards, parallax and depth. No 3D engine. 🏗️ A proper app architecture using Riverpod, GoRouter with StatefulShellRoute.indexedStack, and a feature-first structure across 25+ screens. 📚 A full Bible reader with highlights, bookmarks, notes, sharing, text-to-speech, translation comparison, and saved reading progress. 🌍 6 UI languages — English, Yoruba, Igbo, Spanish, Portuguese and French. ⚡ One of the things I’m happiest about: it works completely offline. The translations are bundled, parsed once, and cached so you can just open the app and read. There were also a lot of small things that aren't as exciting to post about notification permissions, preference migrations, APK optimization, testing, fixing bugs, and making sure everything actually works together. The weekend went by pretty quickly 😂, but it was genuinely fun building this. Selah is still a work in progress, but I’m really happy with how it’s coming together. 🔗 View my LinkedIn post: https://lnkd.in/p/eFTUQeTT 🔗 Try Selah / Download the APK: https://lnkd.in/ehD6u2Cf 💻 GitHub Source Code: https://lnkd.in/eeiwEtni Tech: Flutter · Dart · Riverpod · GoRouter · Isolates · flutter animate · flutter tts · Dio · SharedPreferences Flutter Dart SoftwareEngineering MobileDevelopment FlutterDev BibleApp BuildInPublic

Building & Deploying 3 Real-World Websites with Next.js, React & PostgreSQL

Over the past few weeks, I’ve been building and deploying three real-world web projects, each with a different business requirement and technical scope. 🚀 Projects 1. PSDigiLabs Live: www.psdigilabs.in My own digital services and development portfolio, built as a production-ready business website rather than just a static portfolio. Key work included: Next.js App Router architecture React + TypeScript development Tailwind CSS responsive UI Mobile-first responsive design Service and pricing pages Contact and lead-generation workflow PostgreSQL database integration using Neon Server-side API routes for lead capture Make.com webhook integration Google Sheets lead workflow Custom-domain deployment Vercel production deployment Cloudflare DNS and email routing SEO foundations including sitemap and robots.txt Git/GitHub version control 2. Ritika Jaiswal Fashion Live: www.ritikajaiswalfashion.com A luxury fashion website developed with a strong focus on visual presentation, responsive design and content management. Key work included: Next.js + React + TypeScript Tailwind CSS Responsive luxury-fashion UI Product/collection management Admin dashboard CMS-driven content Image and media management Customer authentication Google sign-in Customer testimonial workflow Testimonial moderation Role-based admin functionality PostgreSQL/Supabase integration Row Level Security Dynamic blogs and media pages SEO administration Hero video optimisation Vercel deployment 3. Creative Monks Live: www.creativemonks.in A cinematic photography and creative-services website designed around portfolio presentation and customer enquiries. Key work included: Next.js + TypeScript Responsive frontend development Supabase/PostgreSQL backend CMS-driven stories, films and commercial projects Dynamic service and package pages Contact/enquiry management Admin dashboard Customer testimonial system Moderation workflow Authentication and database security SEO management Google Analytics 4 integration Responsive testimonial marquee Vercel deployment 🧠 What I Learned These projects gave me practical experience across much more than frontend development. I worked through the complete lifecycle: Requirement Analysis → UI/UX → Development → Database → Authentication → APIs → Testing → Git/GitHub → Deployment → DNS → Analytics → Automation I also spent considerable time debugging real production issues involving responsive layouts, database permissions, authentication, email delivery, deployment configuration and third-party integrations. One of the biggest lessons was that building a production website is not only about writing code. It requires understanding the business requirement, designing the workflow, integrating multiple systems, testing edge cases and maintaining the application after deployment. 🛠️ Technologies Next.js • React • TypeScript • JavaScript • Tailwind CSS • PostgreSQL • Neon • Supabase • REST APIs • Git • GitHub • Vercel • Cloudflare • GA4 • Make.com These projects are helping me build practical experience across full-stack web development, business workflow automation, QA/testing and technical project implementation . nextjs react typescript postgresql webdevelopment fullstack showcase

Domotics

Domotics is an intuitive smart home app designed to give users effortless, real-time control over connected IoT devices, lighting, and automated routines through a sleek mobile UI. It organizes devices by room, monitors energy usage, and delivers a fast, responsive home automation experience tailored for modern living.

I Built a 3D Particle Universe You Can Control With Your Hands ✋🌌

What if you could control a 3D world without a mouse or keyboard? I built AetherParticles 3D — an interactive particle universe where hand gestures become the controls. Just a camera, your hands, and thousands of particles. ✋ Gesture → Action ✊ Fist → Implode particles 🖐️ Open Palm → Scatter particles 🤏 Pinch → Scale the particle world ☝️ Point → Attract particles like a magnet ✌️ Peace → Switch to the next 3D shape 🤘 Rock → Trigger a particle burst 👍 Thumbs Up → Increase energy 👌 OK → Randomize the experience The particles can transform into different 3D forms such as galaxies, Saturn, hearts, fireworks, lotus shapes, and more. 🪐❤️✨ 🧠 What I Wanted to Explore The goal wasn't simply to create a visually impressive particle system. I wanted to explore a bigger question: What happens when we remove the traditional interface and let humans interact with digital worlds naturally? Instead of clicking a button, moving a mouse, or pressing a key, your hand becomes the interface. ⚙️ What I Built The project combines: Real-time hand tracking Gesture recognition 3D particle simulation Interactive particle physics Dynamic 3D shape transformations Real-time visualization Modern web UI One of the interesting challenges was making the gestures feel responsive without making the particle system unstable or unpredictable. There is still plenty I want to improve: Better gesture accuracy More realistic particle physics Improved performance More interactive shapes More complex gesture combinations Better visual effects 🚀 Try AetherParticles 3D https://normal-amethyst-pnff6pqr.edgeone.dev/ This project started as an experiment with computer vision and 3D graphics. It turned into something I enjoyed much more: Making the human hand the controller of a digital universe. ✋🌌 I'm continuing to learn, build, experiment, and explore where AI + computer vision + creative coding can take interactive experiences next. If you try it, I'd love to know: Which gesture or particle shape should I add next? 👀 showcase ai computervision threejs creativecoding webdev javascript 3d

Website for gym registration or login,signup

I just build website for gym studio when anyone want to register in gym so they are do easily. This website have login or signup option when a person register himself so they have command that they see everything about his workout plan. In this website also have meal suggestions or workout plan i automate it ai agents which give him best workout plan or meal suggestions.

Dental Booking AI Agent 🦷🤖

An AI-powered WhatsApp agent that automates dental appointment booking end-to-end — no manual front-desk work required. Patients message the clinic like they normally would; the AI handles the entire conversation, checks real calendar availability, and books the appointment directly. Built as a hands-on project to explore agentic AI workflows using n8n. 💡 The Problem Most dental clinics still handle appointment booking manually: a patient messages, staff replies, checks the calendar, confirms, and books it by hand. It's repetitive, slow, and pulls staff away from patients who are physically in the clinic. ✅ What This Agent Does Receives patient messages over WhatsApp Holds a natural conversation to collect: name, preferred date/time, and reason for visit Checks real-time calendar availability before confirming anything Confirms the details back to the patient and asks for a final "yes" Only after confirmation, creates the actual appointment on Google Calendar Remembers conversation context per patient (so it doesn't ask the same question twice) No forms. No hold music. No manual back-and-forth. 🛠️ Tech Stack Component Tool Workflow orchestration n8n AI / LLM Google Gemini (via n8n's Google Gemini Chat Model node) Messaging channel WhatsApp (via Twilio Sandbox) Calendar & booking Google Calendar API Memory n8n Buffer Window Memory (keyed by patient's phone number) 🧩 Architecture Patient (WhatsApp) │ ▼ Twilio WhatsApp Sandbox │ ▼ n8n Webhook (trigger) │ ▼ Extract Fields (parse incoming message) │ ▼ AI Agent (Gemini + system prompt) ├── Chat Model → Google Gemini ├── Memory → Conversation Buffer (per patient) ├── Tool → Check Availability (Google Calendar) └── Tool → Book Appointment (Google Calendar) │ ▼ Send WhatsApp Reply (Twilio) │ ▼ Patient (WhatsApp) ⚙️ Setup 1. Prerequisites An n8n instance (cloud or self-hosted) A free Twilio account (for WhatsApp Sandbox) A free Google Gemini API key A Google account with Calendar access 2. Import the workflow Import dental-booking-agent.json into n8n via Import from File. 3. Connect credentials Twilio — Account SID + Auth Token (from Twilio Console) Google Gemini — API key (from Google AI Studio) Google Calendar — OAuth2 (connect via "Sign in with Google" inside the node) 4. Configure the WhatsApp Sandbox In Twilio Console → Messaging → Try it out → Sandbox settings, set "When a message comes in" to your n8n webhook's Production URL. 5. Activate the workflow Toggle the workflow to Active in n8n. Test by messaging the Twilio sandbox number on WhatsApp. 🚧 Known Limitations (Demo Version) Runs on Twilio's free Sandbox, which is capped at a small number of messages/day and requires each tester to "join" the sandbox manually — not production-ready for real clinic use yet. Uses gemini free-tier models — tool-calling reliability can vary; verified fixes included for date-handling accuracy. Single calendar/clinic only — no multi-provider or multi-location support yet. 🗺️ Roadmap Appointment reminders (proactive, outside patient-initiated conversations) No-show follow-up automation Lead qualification for new patient inquiries Move off Twilio Sandbox to a verified WhatsApp Business number for production use 🙋 About This Project Built as a learning project to move from no-code workflow automation (n8n) into agentic AI — where the AI doesn't just answer questions, but takes real actions (checking availability, creating calendar events) on a user's behalf.

AI-powered Customer Feedback Sentiment Analyzer & Alert Bot using n8n

An automated AI workflow built in n8n that analyzes customer feedback sentiment in real time, routes actionable insights, and triggers instant alerts for negative feedback! 💡 The Problem Businesses receive feedback across multiple channels, but manually reading, categorizing, and prioritizing urgent complaints takes too much time. Urgent negative feedback often gets lost or responded to late. ✅ What It Does Automated Data Ingestion: Collects customer feedback instantly via Webhooks or Forms. Sentiment & Intent Analysis: Uses AI (Gemini / LLM) to evaluate sentiment (Positive, Neutral, Negative) and extract key topics. Smart Routing & Alerts: Automatically sends real-time alerts (Slack, Telegram, or Email) to support teams when negative sentiment is detected. Data Logging: Logs structured sentiment metrics directly to Google Sheets or Supabase for analytics.

DEVX-Developer's social platform

DevX is a social platform built for developers to connect, share, and showcase their work.this project is my first mern project. Developers can create profiles, publish posts, interact through likes and comments, discover other developers, search for content and users, and showcase their projects in one place. ✨ Key Features 🔐 User Registration & Login 👤 Developer Profiles 📝 Create, Edit & Delete Posts ❤️ Like & Comment System 🚀 Project Showcase 🔎 Developer & Post Search 🌐 Developer-focused social experience

CipherVault — Multi-Technique Encryption & Decryption Lab

I built CipherVault, an interactive Python/Flask cryptography application that brings multiple encryption and decryption techniques into one cybersecurity-focused workspace. It supports Caesar, Vigenère, Atbash, Rail Fence, XOR, Fernet, and AES-256-GCM, along with a learning section, live transformation visualizations, side-by-side cipher comparison, encryption statistics, and password-strength feedback. The goal was to go beyond a basic encrypt/decrypt tool and create something that is also useful for understanding how different cryptographic techniques work and how their security characteristics differ. I'd love to get feedback from other developers and security enthusiasts on the project and ideas for where I could take it next. cybersecurity cryptography python flask infosec

Krooko

Krooko is a platform that lets people find partners and co founders. https://www.krooko.me/

Glow up ai

A beauty advisory ai app

InvoiceDeck: Design-first invoicing & client cash flow protection for freelancers

Hey everyone! Built this out of frustration with clunky enterprise invoicing tools that feel like software from 2008 and generate ugly PDFs. InvoiceDeck is a lightweight, design-focused invoicing app built specifically for developers, designers, and freelancers. Key things I focused on: • 9 design-first themes: Including a dark Terminal monospace layout and a clean Swiss Bauhaus style. • Zero-touch payment protection: Turn accepted estimates into 50% deposit invoices in 1 click, with automated late fee penalties if clients blow past grace periods. • Global compliance: 1-click tax presets (GST, UK VAT, EU VAT) and dynamic QR payment codes. • Client portal & e-signatures: Real-time status tracking so you know when a client views your bill. Live app (free to test, no sign-up required): https://invoicedeck.app Would love honest feedback on the UX or the Terminal template from fellow builders!

🚀 Built a Basic RAG and an Advanced RAG System from Scratch — Without LangChain

To understand how RAG works internally, I first built a Basic RAG Pipeline: Basic RAG PDF → Extraction → Chunking → Embeddings → FAISS Search → Top-K Chunks → Prompt → LLM → Answer It works well for simple questions, but struggles with exact keywords, IDs, and complex queries. So I built an Advanced RAG Pipeline: Advanced RAG PDF → Extraction → Chunking → Embeddings → Dense + Sparse Index → Query Understanding → Dense Retrieval + Sparse Retrieval → Reciprocal Rank Fusion (RRF) → Cross-Encoder Reranking → Noise Filtering → Context Fusion → Prompt → LLM → Answer Key Improvements ✅ Semantic Search (FAISS) ✅ Exact Keyword Search (BM25) ✅ Hybrid Retrieval ✅ Cross-Encoder Reranking ✅ Duplicate Removal ✅ Better Context Selection ✅ Reduced Hallucinations One of the biggest lessons from this project: A better RAG system isn't always about using a better LLM. It's often about building a better retrieval pipeline. Tech Stack: Python • Streamlit • FAISS • Sentence Transformers • BM25 • Cross-Encoder Reranker • Groq RAG GenAI LLM AIEngineering MachineLearning Python FAISS BuildInPublic

AI Screening Application

🤖 AI Screening Application An AI-powered candidate screening application that evaluates applicants based on the information they provide through an online form. 📌 Overview The AI Screening Application automates the initial candidate screening process. Instead of manually reviewing every applicant, a person fills out a screening form and submits their information. The AI analyzes the submitted responses according to the screening criteria and generates a candidate score. This helps recruiters and organizations quickly identify promising candidates and reduce the time spent on initial screening. ✨ Features 📝 Candidate screening form 🤖 AI-powered response analysis 📊 Automatic candidate scoring ⚡ Fast initial screening 📋 Structured candidate information 🎯 Helps identify suitable candidates 🔄 Reduces manual screening work 🔄 How It Works The application follows a simple workflow: Candidate ↓ Fills Out Screening Form ↓ Submits Information ↓ AI Analyzes Responses ↓ Candidate Score Generated ↓ Screening Result 1. Candidate Fills the Form The candidate provides the required information and answers the screening questions. 2. Form Submission After submitting the form, the candidate's responses are sent to the AI screening system. 3. AI Analysis The AI evaluates the candidate's responses based on predefined screening criteria. 4. Score Generation The system generates a score representing how well the candidate matches the screening requirements. 5. Result The screening result can then be used by recruiters or hiring teams to decide which candidates should move to the next stage.

Building My Backend Skills with FastAPI & SQLAlchemy

🚀 Building with FastAPI + SQLAlchemy I’m currently improving my backend development skills by building APIs with FastAPI and SQLAlchemy. So far, I’ve been practicing: • REST APIs • CRUD operations • SQL databases • Relationships & aggregations • Pydantic validation • JWT authentication • Password hashing I’m still learning, but consistently building and improving step by step. 💻🔥 Would love to hear feedback from other developers!

Trust Check BD

Trust Check BD Search before you pay. Report a scam when it happens. Trust Check BD is a community-driven scam reporting and trust verification platform built for Bangladesh. I’m building Trust Check BD to solve a simple but important problem: Before sending money to a person, seller, business, website, or online platform — how can you know whether you can trust them? In Bangladesh, online scams are becoming increasingly common across Facebook, e-commerce platforms, marketplaces, and direct transactions. Many people only discover that someone is a scammer after losing their money . Trust Check BD aims to help people make a more informed decision before they pay . 🚀 What I'm Building Trust Check BD allows users to search and verify digital identities before making a transaction. Users can search for: 📱 Phone numbers 💳 bKash / Nagad numbers 🌐 Websites and domains 📘 Facebook pages 👤 Other digital identities associated with online transactions If a suspicious person or entity has previously been reported, users can discover those reports before sending money. 🔍 Scam Search The core experience is a simple search: Instead of relying on rumors or random Facebook posts, users can find structured scam reports in one centralized platform. 🚨 Scam Reporting Anyone who has experienced an online scam can submit a report with relevant information such as: Scammer identity Phone or payment number Website or social media profile Transaction information Scam description Screenshots or supporting evidence The goal is to turn individual scam experiences into useful information that can protect other people. 🧠 Building a Community-Driven Database Trust Check BD is not just a search tool. I'm building a growing community-driven database of scam reports where information from individual incidents can become useful to thousands of other people. The long-term vision is to make scam-related information easier to discover, understand, and verify before money changes hands. 🛠️ Technology Trust Check BD is built using modern web technologies: Next.js React.js TypeScript Tailwind CSS Node.js Prisma MongoDB PostgreSQL The platform is designed with a focus on: ⚡ Performance 🔎 SEO 📱 Mobile-first experience 🔐 Data integrity 📈 Scalability 🤖 AI-friendly structured content 🎯 Why I'm Building It The idea came from seeing how difficult it can be to determine whether an online seller or individual is trustworthy before making a payment. A simple question inspired the project: "What if people could search someone before sending them money?" That question became Trust Check BD. I'm building it with the goal of creating a reliable digital layer of trust for online transactions in Bangladesh. 🌱 What's Next Trust Check BD is still evolving. Future plans include: Business verification Trusted seller profiles Verified business badges Product and business discovery Better scam intelligence More structured verification data Community-driven trust signals Tools to help businesses build online credibility Ultimately, I want Trust Check BD to become a place where people can check before they trust, search before they pay, and report when something goes wrong. 🔗 Project Website: https://trustcheckbd.com Tagline: Search before you pay, Report a scam when it happens --- 👨‍💻 Built by Monir Hossain — Full-Stack Developer & Founder I'm building Trust Check BD from idea to production, working across product development, architecture, frontend, backend, database design, SEO, and growth.

Shopify AI Customer Support Automation

An AI-powered assistant that instantly answers customer support questions for Shopify stores using the store's real policies — no more manually replying to the same questions over and over. 🚀 What It Does Store owners spend hours every week answering repetitive customer emails like: - "Where's my order?" - "Do you ship internationally?" - "What's your return policy?" This automation reads the store's actual shipping, return, and FAQ policies and generates accurate, human-sounding replies — instantly. ⚙️ How It Works 1. Customer asks a question (via chat, email, or support form) 2. AI reads the store's real policies (shipping, returns, international orders, etc.) 3. AI generates an accurate, natural-sounding reply 4. Reply is sent instantly — no manual work needed 💡 Why It Matters - Saves store owners hours every week - Customers never wait for a reply - Answers are based on the store's actual policies (not generic templates) - Works for Shopify stores, coaches, and service businesses 🛠️ Tech Stack (example — customize to your actual build) - AI/LLM : [e.g. Claude / OpenAI API] - Platform : Shopify API - Backend : [e.g. Node.js / Python] - Knowledge Source : Store policy pages, FAQs, order data - Deployment : [e.g. Vercel, AWS, etc.]

Shipped: A README for a stranger

I built a complete interactive Machine Learning learning platform focused on helping students learn ML concepts through structured lessons, practical examples, interactive learning experiences, projects, challenges, interview preparation, and an ML lab. The project is available as a live web application and the complete source code is provided in the GitHub repository. Reviewer verification: 1. Open the live demo and explore the Home and Learn sections to verify the ML-focused learning experience. 2. Navigate through the Machine Learning curriculum to view structured topics and explanations. 3. Use the ML Lab and interactive learning features to verify that the project goes beyond a static website. 4. Explore Projects, Roadmap, Interview, and Challenges sections to verify the broader learning workflow. 5. Test the responsive layout on desktop and mobile screen sizes. 6. Use the GitHub repository to inspect the implementation, project structure, components, and README documentation. The project is designed as an educational Machine Learning platform rather than a simple landing page, with interactive content and practical learning features intended for beginners, engineering students, interview preparation, and advanced learners. Repository: https://github.com/kakashsunny/MLL Live: https://machine-learning-111.vercel.app/ Built for the Verified Frontend Internship · Documentation

Shipped: Comparison table for three plans

I built an accessible pricing plan comparison table for three plans across 15 features with a "Highlight differences only" toggle control. How to verify acceptance criteria: 1. Keyboard Navigation & Visible Focus: Press 'Tab' to navigate through interactive elements. The toggle and table container display a clear visible focus outline. Use 'Space' or 'Enter' to operate the toggle. 2. Highlight Differences Logic: Toggle "Highlight differences only" to hide rows with identical values ( data-same="true" ). The remaining features are clearly legible while active. 3. Responsive & No Overflow (320px): On mobile viewports down to 320px, the page has no horizontal scrolling. The table is housed in an accessible container with horizontal scroll ( overflow-x-auto ). 4. Accessibility (A11y): Built with semantic HTML ( <table , <caption , <thead , <tbody , <th with proper scope attributes) for screen-reader support. 5. README: The reasoning behind the narrow-screen horizontal scroll approach is documented in the repository's README.md. Repository: https://github.com/naramirova/internship-plan-comparison Live: https://internship-plan-comparison-76juam26y-naramirovas-projects.vercel.app/ Built for the Verified Frontend Internship · accessible layout

Shipped: Conference schedule

Built a responsive, keyboard-accessible single-page conference schedule for a two-day conference with three parallel tracks. Sessions can be opened and dismissed using the keyboard, all interactive elements have visible focus, and the layout was tested at 320px with no horizontal scrolling. On narrow screens, the three tracks switch from columns to a single vertical sequence, and this decision is documented in the README. Repository: https://github.com/rajatpandey14/Conference-Schedule Built for the Verified Frontend Internship · accessible layout

Shipped: Currency converter with live rates

Built a responsive currency converter using React and the Frankfurter public API. The application supports successful conversion plus clearly distinct loading, error, and empty/data-gap states. Reviewers can reproduce all three states without changing the code using ?demo=loading, ?demo=error, and ?demo=empty, with the exact steps documented in the README. The interface is keyboard accessible, responsive at 320px, and has no horizontal scrolling. Repository: https://github.com/rajatpandey14/Currency-Converter Built for the Verified Frontend Internship · state and data

Shipped: A view onto a public dataset

Built Weather Window, a React app that turns hourly public weather forecast data into a practical outdoor-time recommendation. Users can search cities and supported region names, view a continuous outdoor window of up to three hours, and see the precipitation, wind, and temperature values behind the recommendation. The project uses Open-Meteo geocoding and forecast APIs. The repository includes setup and usage instructions, recommendation logic, limitations, and representative-location handling for supported regions. Loading, API error, and no-suitable-window states are handled explicitly. The project was tested with a production build, pushed to GitHub, and deployed on Vercel for reviewer access. Repository: https://github.com/rajatpandey14/weather-window Live: https://weather-window-five.vercel.app Built for the Verified Frontend Internship · Final project

Shipped: A README for a stranger

Built and documented Weather Window, a React application that turns hourly public weather forecast data into a practical outdoor-time recommendation. The README explains the project purpose, required Node.js and npm setup, installation and development commands, production build, data sources, recommendation logic, supported location handling, loading and error states, accessibility, responsive behavior, design decisions, and project limitations. A reviewer can clone the repository, install dependencies with npm install, start the Vite development server with npm run dev, and verify the production build with npm run build. The README also explains that state-level searches use representative cities and clearly states what the forecast data does and does not support. The project is available as a live Vercel deployment for comparison with the repository documentation. Repository: https://github.com/rajatpandey14/weather-window Live: https://weather-window-five.vercel.app Built for the Verified Frontend Internship · Documentation

Shipped: Bookmark service

I built a Bookmark Service HTTP API designed with strict input boundary validation and idempotency handling. What was built: 1. Endpoints: - POST /bookmarks: Validates input and creates a bookmark, or returns the existing bookmark if repeated. - GET /bookmarks: Retrieves the list of all bookmarks. - GET /bookmarks/:id: Fetches a single bookmark by ID (returns 404 if not found). - DELETE /bookmarks/:id: Deletes a bookmark by ID (returns 204 or 404). 2. Input Validation (Survives Bad Input with 400 status): - Returns 400 Bad Request with an explicit error message naming the 'url' field for: Missing 'url' field Non-string values (e.g., numbers, booleans) Empty strings or whitespace-only inputs URLs exceeding 2 KB in length Invalid URL format or protocols other than http/https - No bad input produces an unhandled 500 error. 3. Duplicate Recognition: - Compares canonical URL strings to identify duplicates. - Sending the same create request twice leaves only one row and returns the existing record with status 200 OK. How a reviewer can verify: - Send test POST requests with empty body, numbers, and strings over 2KB to verify 400 error responses naming the 'url' field. - Send identical valid POST requests twice to verify only one row exists and no duplicate is created. - Check the README.md in the repository for documentation on duplicate handling. Repository: https://github.com/roh155/Bookmark-Service-API Built for the Verified Backend Internship · an API that survives bad input

Shipped: Recipe with adjustable servings

Built a responsive, keyboard-accessible Chicken Biryani recipe page with adjustable serving quantities. Reviewer can verify: Tab through all interactive elements and check visible focus. Use the serving buttons with keyboard. Test at 320px with no horizontal scrolling. Change servings and verify quantities update and are announced to screen readers. Check the README for accessibility and responsive details. Repository: https://github.com/hassannnn13/Accessible-layout.git Built for the Verified Frontend Internship · accessible layout

Shipped: Conference schedule

Built a responsive, accessible two-day conference schedule with three parallel tracks. On desktop, the three tracks are displayed side-by-side to make the parallel schedule easy to compare. On narrow screens, the parallel tracks are replaced with a track selector so sessions remain readable without horizontal scrolling at 320px. The interface is keyboard accessible throughout, with visible focus indicators and interaction order matching the visual order. Sessions can be opened using the keyboard, with details presented in an accessible dialog that can be dismissed using Escape or the dialog close control, with focus returned to the triggering session. The project was tested at a 320px viewport, and the production build and Oxlint checks complete successfully with no warnings or errors Repository: https://github.com/kiths-bit/conference-schedule Live: https://conference-schedule-lilac.vercel.app/ Built for the Verified Frontend Internship · accessible layout

Shipped: Comparison table for three plans

I built a responsive and accessible plan comparison page using React. It compares Basic, Pro, and Premium plans across 15 features and includes a “Show differences only” control. A reviewer can verify the acceptance criteria by: Opening the GitHub repository and running npm install and npm run dev . Checking the desktop view to see the semantic comparison table. Resizing the browser to 320px and verifying there is no horizontal scrolling. The layout changes to stacked plan cards. Using the keyboard Tab key to reach the “Show differences only” checkbox and Space to toggle it. Verifying that the checkbox has a visible focus indicator. Enabling “Show differences only” and checking that only features with different values between plans are displayed. Inspecting the semantic table structure using table , caption , thead , tbody , th , td , and appropriate scope attributes. Reviewing the screenshots and demo recording included in the README for a quick visual demonstration of the responsive layout and functionality. The README also documents the accessibility, responsive design, and keyboard-testing decisions. Repository: https://github.com/AteefaAzhar-Syed/accessible-layout Built for the Verified Frontend Internship · accessible layout

Shipped: Bookmark service

Built a bookmark service with 4 endpoints: POST/GET /bookmarks, GET/DELETE /bookmarks/:id. Every malformed input (empty url, number instead of string, missing field, url over 2KB) returns 400 with a message naming the exact field -- never a 500. Idempotency is handled by a UNIQUE constraint on the url column: POSTing the same URL twice returns the existing bookmark with 200 instead of creating a duplicate row. A reviewer can verify this by running npm install && npm start , then bash test.sh in another terminal -- it walks through all 8 acceptance cases and prints the real HTTP responses. The README documents the idempotency decision and includes a captured run of this exact output. Repository: https://github.com/GhulamMustafaAnsari/bookmark-service Live: https://bookmark-service.bonto.run/bookmarks Built for the Verified Backend Internship · an API that survives bad input

Shipped: A service somebody else could run

A reading-list API with JWT-based accounts. Unauthenticated requests to /books return 401. Every book query is scoped to the caller's user id, and GET/DELETE on another user's book returns the same 404 as a nonexistent id -- so ownership can't be probed for. This is proven with node test-isolation.js, which registers two users, has user A create a book, and shows user B getting 404 on it while user A still gets 200. POST /books accepts an optional Idempotency-Key header: retrying the same key returns the original book instead of creating a second row -- node test-idempotency.js demonstrates this with real output (same id returned twice, list shows exactly one row). All 400 errors name the specific field that was wrong. No secret is committed -- JWT SECRET is read from an environment variable, with only a .env.example checked in. Reviewer steps: npm install, cp .env.example .env (set JWT SECRET), npm start, then run the two test scripts above in another terminal. Repository: https://github.com/GhulamMustafaAnsari/reading-list-service Live: https://reading-list-service.bonto.run/health Built for the Verified Backend Internship · Final project

Shipped: Bookmark service

Repository: https://sgm322.github.io/BookMarks/ Built for the Verified Backend Internship · an API that survives bad input

Shipped: The data model, explained

Documented the data model in README.md: each table's purpose and relationships, each constraint (foreign keys, the UNIQUE on reservations.seat id, the composite index) named alongside what it prevents, and the query plan for the highest-traffic query (SCAN vs SEARCH USING COVERING INDEX). Also ran the exact same query at 10x scale (100,000 seats vs 10,000) to find what actually breaks first -- not the index (it keeps using SEARCH), but the missing pagination: response time went from 0.662ms/666 rows to 5.681ms/6,666 rows and 272KB, growing linearly with result size. The decision documented: add LIMIT/OFFSET before that becomes a real problem. Repository: https://github.com/GhulamMustafaAnsari/ticket-sales Live: https://ticket-sales.bonto.run/events/1/seats?status=free Built for the Verified Backend Internship · Documentation

Shipped: Comparison table for three plans

Acceptance Criteria Responsive 3 plans are compared across 15 features. Desktop uses a semantic comparison table. At 320px and other narrow widths, plans switch to stacked cards. No horizontal scrolling is required on mobile. Accessibility The comparison uses semantic table markup with column and row headers. The “Show differences only” control is a native keyboard-accessible checkbox. All interactive elements are reachable using the keyboard. Focus indicators are clearly visible. A skip link allows keyboard users to jump directly to the comparison. The comparison remains understandable when differences-only mode is enabled. Interaction “Show differences only” hides features where all three plans have the same value. A live status message communicates how many features/differences are currently displayed. Verification Tested at: 320px mobile 375px mobile 768px tablet Desktop Keyboard test: Tab → Space/Enter → Tab through all interactive elements with no keyboard traps. Repository: https://github.com/Zainab-Ashraf-786/Comparison-Table/tree/main/my-app Live: https://my-app-six-opal.vercel.app/ Built for the Verified Frontend Internship · accessible layout

Shipped: Library loans

Repository: https://sgm322.github.io/LibraryLoansAPi/ Built for the Verified Backend Internship · a data model and the queries on it

Shipped: A service with a job running behind it

Repository: https://sgm322.github.io/finalBackendDevConnect/ Built for the Verified Backend Internship · Final project

Shipped: Currency converter with live rates

I built a Currency converter that fetches live exchange rates from the Frankfurter API. The app demonstrates three distinct fetch states: Loading (spinner + message while waiting) Error (clear alert when the request fails, with retry option) Empty (coverage gap when a currency pair isn’t supported, shown as “No rate available” instead of an error). How can a reviewer see that the acceptance criteria are met? All three states are visually and textually distinct and can be reached without code changes: Loading → open task2.html?demo=loading or enable Simulate a slow connection in Demo controls. Error → open task2.html?demo=error or enable Force the request to fail. Empty → open task2.html?demo=empty or select BTC or ETH as the “To” currency. The error message explains what failed and what to try next, including a retry button. Unsupported currency pairs are presented as a data gap, not an application error. Repository: https://github.com/hassannnn13/currency-converter.git Built for the Verified Frontend Internship · state and data

Shipped: A view onto a public dataset

I built Nepal Tourism Explorer, a React/TypeScript data visualization app using official Nepal Tourism Board tourism statistics. The reviewer can verify the acceptance criteria by: Making public data understandable: The app visualizes Nepal’s international visitor arrivals from 2019–2025 and the top 10 source markets for 2025. Handling loading/failure states: The app includes loading, error, retry, and empty-data states. Documenting limitations: The README explains the data source, what the data can show, and what it cannot measure. Reproducibility: The README includes local setup and build instructions. Development history: The GitHub repository contains the project’s commit history showing its development. Deployment: The live application is available at https://nepal-tourism-explorer-khaki.vercel.app/ Repository: https://github.com/tenjeebkc/Nepal-tourism-explorer Live: https://nepal-tourism-explorer-khaki.vercel.app/ Built for the Verified Frontend Internship · Final project

Shipped: Short link service

I built a simple Short Link Service using Python, Flask, and SQLite. It allows users to create short links from valid HTTP/HTTPS URLs, redirect to the original URL, count link clicks, and view link statistics. It also validates invalid input and returns HTTP 400, returns HTTP 404 for unknown short codes, and returns the same short code when the same URL is submitted again. A reviewer can verify the acceptance criteria by running the application with python app.py and testing the API at http://127.0.0.1:5000. The README contains the available endpoints and examples for testing the main functionality. Repository: https://github.com/LinaMustafa1/short-link-service Live: Not available. The service runs locally with Flask. Built for the Verified Backend Internship · an API that survives bad input

Shipped: Ticket sales

Built a concurrency-safe Ticket Booking REST API using Node.js and MySQL (InnoDB) meeting all Brief B criteria: 1. Data Model & Integrity: Normalized schema with events, seats, and orders using foreign keys, CASCADE constraints, and a UNIQUE constraint on seat reservations. 2. High-Volume Inventory: Seeded 10,000+ seat records across 5 events via an automated stored procedure. 3. Sub-200ms Latency: Implemented composite index idx event reserved on (event id, is reserved); GET /events/:id/free-seats fetches 2,000 available seats in under 25 ms. 4. Concurrency & Race Condition Safe: Applied pessimistic row locking (SELECT ... FOR UPDATE) inside database transactions. Verified via parallel PowerShell background jobs showing one request succeeding (201 Created) while simultaneous conflicting attempts fail (409 Conflict). Full schema, setup commands, and execution proofs are documented in the repository README.md. Repository: https://github.com/roh155/ticket booking Built for the Verified Backend Internship · a data model and the queries on it

Shipped: A rebuild of one feature you use

I built a pixel-perfect, interactive clone of the Canva export modal using strictly vanilla HTML5, CSS3, and JavaScript, without any external libraries. A reviewer can verify the acceptance criteria are met by checking the live demo and the repository: 1. Clean Code: All development comments have been removed from the source files. 2. UI/UX & Styling: Features custom-styled CSS radio toggles, gradients, and dynamic loading/success states. 3. Accessibility (a11y): Implemented aria-live="polite" for status messages and proper semantic labels for all inputs. 4. Defensive Programming: Includes state validation (preventing download if no page is selected) and a proactive navigator.onLine check to intercept offline requests immediately. 5. Documentation: The README.md file contains comprehensive setup instructions, technical decisions (defensive programming vs. UX), known limits, and a specific feature improvement comparison over the original Canva modal. Repository: https://github.com/Carmy4/canva-export-menu Live: https://carmy4.github.io/canva-export-menu/ Built for the Verified Frontend Internship · Final project

Shipped: Bookmark service

I built a lightweight, framework-free Node.js API for managing bookmarks, designed specifically to be easy to review. The README clearly maps out every endpoint and status code, so you know exactly what to expect. The server is rock-solid and returns helpful 400 errors for bad inputs without ever crashing. It also smartly handles duplicate URLs based on a real-world "one bookmark per page" rule. Everything is proven by 49 real HTTP tests that you can run instantly with a simple node --test, requiring absolutely no setup. Repository: https://github.com/Gloweeyahh/bookmark-service Live: https://bookmark-service-zg64.onrender.com/ Built for the Verified Backend Internship · an API that survives bad input

Shipped: Short link service

I built a full-stack URL shortener with a React/Vite frontend, Express.js backend, and PostgreSQL database hosted through Vercel and Neon. Users can enter a valid HTTP/HTTPS URL and generate a unique short link. Opening the short link redirects to the original URL, while the Statistics feature displays the link's current click count and stored information. The application also includes URL validation, duplicate URL handling, persistent database storage, and API health checking. A reviewer can verify the acceptance criteria directly from the deployed application by: 1. Entering a valid URL and creating a short link. 2. Opening the generated short URL and confirming it redirects to the original URL. 3. Clicking Statistics and confirming the stored URL and click count are displayed. 4. Opening the short URL multiple times and checking that the click count increases. 5. Refreshing the page or returning later to confirm the link data persists through PostgreSQL. 6. Testing invalid input to confirm that invalid URLs are rejected. 7. Checking the application's health endpoint to verify that the deployed backend is operational. The complete source code and implementation are available in the project's GitHub repository, allowing the reviewer to inspect the frontend, API, database integration, validation, and deployment configuration. Repository: https://github.com/AdyanShaikh/url-shortener Live: https://url-shortener-puce-ten.vercel.app/ Built for the Verified Backend Internship · an API that survives bad input

Shipped: A README a reviewer can follow

Repository: https://sgm322.github.io/READmeDev/ Built for the Verified Backend Internship · Documentation

Shipped: Comparison table for three plans

I build a Cloud Flow plan comparison data table using HTML,CSS,JavaScript and Readme. You can check throught netlify. Repository: https://github.com/aungmyintmyatmaggie129/CloudFlow Live: https://cloudflowcompareplan.netlify.app/ Built for the Verified Frontend Internship · accessible layout

Shipped: Personal reading list

I build a small browser only reading list app from open library search api that include add list function saved in the localstorge. Repository: https://github.com/aungmyintmyatmaggie129/LeafMark Reading List Live: https://leafmark.netlify.app/ Built for the Verified Frontend Internship · state and data

Shipped: Comparison table fo three plans

I built a responsive and accessible comparison page for three plans: Basic, Pro, and Premium. It compares around 15 features and includes a “Show differences only” checkbox that hides rows where all three plans have the same value and highlights rows where the plans differ. The acceptance criteria can be verified as follows: Keyboard operation: The “Show differences only” checkbox can be reached with Tab and operated with Space. Visible focus: The checkbox has a clear visible focus indicator when using the keyboard. No horizontal scrolling at 320px: The desktop table changes to a stacked layout on narrow screens. I tested the page at 320px and confirmed there is no horizontal scrolling Assistive technology: The comparison uses a semantic HTML table with a caption, table headers, row headers, and scope attributes so the table structure is properly conveyed. Narrow-screen treatment: The README explains why the table changes to a stacked layout on small screens and how this keeps the comparison understandable without horizontal scrolling. The reviewer can open the repository, run the page, test the checkbox using only the keyboard, and resize the viewport to 320px to verify the criteria. Repository: https://github.com/likhitakarri22/accessible-plans-comparison Built for the Verified Frontend Internship · accessible layout

Shipped: Conference schedule

What I Built I built a responsive, accessible single-page conference schedule for a two-day conference with three parallel tracks. The interface allows visitors to: Switch between Day 1 and Day 2. View sessions across three conference tracks. Open individual session details. Navigate the complete interface using only a keyboard. Use the schedule comfortably on narrow screens, including a 320px viewport. How a Reviewer Can Verify the Acceptance Criteria 1. Keyboard Operation The reviewer can start at the top of the page and use only: Tab to move forward. Shift + Tab to move backward. Enter or Space to activate buttons. Arrow keys to switch between the conference day tabs. Escape to close the session details dialog. Every interactive element uses native HTML controls such as <button and <a , so all controls are keyboard reachable. The DOM order also follows the visual order, ensuring that keyboard navigation follows the same logical sequence as the page. 2. Visible Focus Indicators When navigating with the keyboard, every focused interactive element displays a clear focus indicator using :focus-visible . css :focus-visible { outline: 4px solid f59e0b; outline-offset: 4px; } The focus indicator is not removed, ensuring that keyboard users can always see where they are on the page. 3. Responsive Behavior On desktop screens, the three conference tracks are displayed side by side so visitors can compare sessions happening at the same time. On narrow screens, the three parallel columns are replaced with a single chronological vertical layout. This prevents horizontal scrolling and keeps every session readable and accessible. 4. 320px Testing The reviewer can open the browser's responsive/device mode and set the viewport to: text 320px wide At this width: The three tracks become a single vertical list. Session cards fit within the viewport. Text wraps naturally. Navigation adapts to the available width. No horizontal scrolling is required. 5. Session Details Every session has a native button: html <button type="button" View session details </button The reviewer can: 1. Tab to any session. 2. Press Enter or Space . 3. Verify that the session dialog opens. 4. Navigate through the dialog using the keyboard. 5. Press Escape to close it. 6. Verify that focus returns to the session button that opened the dialog. Therefore, the complete session-details interaction can be performed without a mouse. 6. Parallel Track Decision The three tracks remain side by side on larger screens because this makes simultaneous sessions easy to compare. On narrow screens, keeping three columns would make the content too narrow and could introduce horizontal scrolling. Therefore, below the responsive breakpoint, the tracks are converted into a single chronological list. This was chosen to prioritize: No horizontal scrolling. Readability. Chronological understanding. Keyboard accessibility. Access to all sessions. 7. README Documentation The repository README documents: Keyboard operation. Focus behavior. Session dialog behavior. Responsive behavior. The reason parallel tracks are changed on narrow screens. 320px testing instructions. Accessibility testing checklist. A reviewer can therefore verify both the implementation and the design decisions directly from the repository. Repository: https://github.com/techtuber9988/conference-schedule Live: https://conference-schedule-rust.vercel.app/ Built for the Verified Frontend Internship · accessible layout

Shipped: Comparison table for three plans

I built an accessible, responsive plan comparison table with a keyboard-operable toggle that highlights feature differences across three plans. A reviewer can test it by tabbing through the page to confirm the toggle has a clear visible focus outline and operates with the spacebar. Resizing the browser to 320px shows that the layout automatically stacks into card blocks without any horizontal scrolling. Additionally, inspecting the code or using a screen reader will show semantic table tags and hidden contextual labels, while the README file details the complete design strategy for narrow screens. Repository: https://github.com/ghazlsinjab80/accessible-layout Built for the Verified Frontend Internship · accessible layout

Shipped: Conference schedule

I built a responsive two-day conference schedule with three parallel tracks: Product, Technology, and Design & Culture. Each session is keyboard accessible and opens a details dialog. Reviewers can use Tab to navigate through the interface, Enter/Space to open a session, and Escape to close the dialog and return focus to the selected session. Focus indicators are visible on interactive elements. On narrow screens, the three tracks stack vertically within each time slot instead of remaining side-by-side, preventing horizontal scrolling at 320px. The README explains this responsive accessibility decision and includes a keyboard testing checklist. Repository: https://github.com/mutyalaraghavendra/conference-schedule.git Live: https://mutyalaraghavendra.github.io/conference-schedule/ Built for the Verified Frontend Internship · accessible layout

Shipped: Currency converter with live rates

Repository: https://github.com/mutyalaraghavendra/currencyconverter Live: https://mutyalaraghavendra.github.io/currencyconverter/ Built for the Verified Frontend Internship · state and data

Shipped: Recipe with adjustable servings

ReciPo, a recipe repository. It is extendable, searchable, and serving-adjustable. I even show images of the food. Only one dish so far, but it's easy to add new one. Repository: https://github.com/MedicMedic/Recipe-Repo Built for the Verified Frontend Internship · accessible layout

Shipped: Recipe with adjustable servings

Built a responsive recipe page with adjustable servings and accessibility in mind. I focused on keyboard navigation, visible focus states, responsive behavior at 320px, and making ingredient quantity changes accessible to screen readers. Repository: https://github.com/Ahmed6770/Recipe-page Live: https://ahmed6770.github.io/Recipe-page/ Built for the Verified Frontend Internship · accessible layout

Shipped: Currency converter with live rates

I built a responsive Exchange Rate Converter that fetches exchange rates from a public API and focuses on clearly handling different application states. What I Built 1. Currency Conversion Users can enter an amount and select the source and target currencies. The application fetches the exchange rate and displays the converted amount. A swap option is provided to quickly switch currencies. 2. Loading State While the API request is in progress, the application shows a clear loading indicator and message. This makes it clear that the system is working and the result has not arrived yet. 3. Error State If the API request fails, a separate error state is displayed. The message explains what went wrong and tells the user what they can do next, such as retrying the request. 4. Empty State If the request succeeds but the API does not provide a rate for the selected currency pair, the application shows an empty/data-gap state. It does not incorrectly treat missing data as a zero value. 5. Success State When a valid exchange rate is available, the application displays the rate and the converted amount clearly. How a Reviewer Can Verify the Acceptance Criteria The reviewer does not need to modify the source code to test the required states. Success: Open the application normally and perform a conversion. Loading: Open the application with ?state=loading . Error: Open the application with ?state=error . Empty: Open the application with ?state=empty . This allows the reviewer to directly verify that Loading, Error, Empty, and Success are separate and clearly distinguishable states. Acceptance Criteria Covered Loading, Error, and Empty states are visually and textually different. Errors explain what failed and what the user should do next. Missing exchange-rate data is treated as a data gap rather than displaying 0 . Unsupported currency pairs are presented as an Empty state, not as an application error. All required states are demonstrable without changing the code. The README provides instructions for testing each state. Repository: https://github.com/techtuber9988/exchange-rate-converter Live: https://exchange-rate-converter-sooty.vercel.app/ Built for the Verified Frontend Internship · state and data

Shipped: A view onto a public dataset

I built Quakescope, a real-time earthquake monitoring web application using React 19, Vite, Tailwind CSS, Leaflet, and the USGS Earthquake Catalog API. The application transforms earthquake data into an interactive and understandable interface. Users can view earthquake locations on a map, filter events by magnitude and time, and inspect individual earthquake details such as magnitude, coordinates, significance, and alert information. A reviewer can verify that the acceptance criteria are met by following these steps: Acceptance Criterion: Earthquake data is displayed Verification: Open the application and confirm that earthquake events are loaded from the USGS API and displayed in the interface. Acceptance Criterion: Interactive map works Verification: Check that earthquake markers appear on the Leaflet map and that the map can be explored. Acceptance Criterion: Filtering works Verification: Change the magnitude and time filters and verify that the displayed earthquake results update according to the selected criteria. Acceptance Criterion: Earthquake details are available Verification: Select an earthquake and confirm that its details, including magnitude, location, coordinates, and other available information, are shown. Acceptance Criterion: Loading and error states are handled Verification: Test the application during loading or with an unavailable network/API response and verify that the interface provides appropriate feedback rather than failing silently. Acceptance Criterion: Responsive and accessible interface Verification: Resize the browser and test keyboard navigation, focus states, and the usability of the main controls. Acceptance Criterion: Project can be run locally Verification: Clone the repository, run npm install, then npm run dev, and open the local Vite URL to inspect the application. The source code and implementation are available in the Quakescope GitHub repository: https://github.com/techtuber9988/quakescope. This allows the reviewer to inspect both the functionality and the technical implementation. Repository: https://github.com/techtuber9988/quakescope Live: https://quakescope.vercel.app/ Built for the Verified Frontend Internship · Final project

Shipped: A README for a stranger

What Was Built? Quakescope is a real-time earthquake monitoring web application built using React 19, Vite, Tailwind CSS, Leaflet, React-Leaflet, and the USGS Earthquake Catalog API. The application collects publicly available earthquake data and presents it through an interactive dashboard. Users can view earthquake locations on a map, filter events based on magnitude and time, and inspect detailed information about individual earthquakes. The main goal of Quakescope is to make earthquake activity easier to explore and understand through a clean, responsive, and interactive interface. How Reviewers Can Verify the Acceptance Criteria A reviewer can verify the project by cloning the repository, installing the dependencies, and running the application locally. 1. Run the Project bash git clone https://github.com/techtuber9988/quakescope.git cd quakescope npm install npm run dev Repository: https://github.com/techtuber9988/quakescope-overview Live: https://quakescope-overview.vercel.app/ Built for the Verified Frontend Internship · Documentation

Shipped: Recipe with adjustable servings

Built an accessible responsive recipe viewer with serving scaling, screen-reader announcements, keyboard/focus support, and independently scrollable mobile sections; reviewers can verify everything directly in the UI at 320px and with keyboard/screen-reader testing. Repository: https://github.com/abbasg-dev/recipe-accessible Live: https://recipe-accessible.vercel.app/ Built for the Verified Frontend Internship · accessible layout

Shipped: A view onto a public dataset

I built GitHub Repository Signals — you type in any public repo (like facebook/react) and it tells you something GitHub itself doesn't show you in one place: how much of the project actually depends on one person. It pulls the repo's contributors and calculates what percentage of commits came from the top contributor, so you can tell at a glance if a project is a healthy team effort or basically one person holding it together. Repository: https://github.com/hassannnn13/devConnect-Internship-Final-Project.git Live: https://git-repository-explorer.vercel.app/ Built for the Verified Frontend Internship · Final project

Shipped: Personal reading list

I built a very simple state-driven Personal Reading List application with localStorage persistence that lets users add and remove entries. Reviewers can verify all criteria directly in the UI using the built-in demo control panel at the top of the page without changing any code. Clicking "Trigger Loading" shows an animated spinner and status message, "Trigger Empty" explains the feature and offers an "Add Your First Book" button that focuses the input, and "Trigger Error" displays a red alert explaining what failed along with a "Retry Loading" button. Full details and setup instructions are documented in the README. Repository: https://github.com/ghazlsinjab80/personal-reading-list Built for the Verified Frontend Internship · state and data

Shipped: A rebuild of one feature you use

I rebuilt Spotify’s persistent web player UI as a standalone React app styled with Tailwind CSS and Lucide icons. A reviewer can verify the acceptance criteria directly through the GitHub repository's step-by-step commit history and the clear setup instructions provided in the README. Full keyboard navigation is supported out of the box using Space for play/pause, Arrow keys for seeking and volume control, M for mute, and Tab for visible focus navigation. Failure states are explicitly handled, showing a retry banner on media loading errors and an SVG placeholder if album art fails to load. Finally, the README compares the build against the original by detailing omitted features like authentication and highlighting an key UI accessibility improvement. Repository: https://github.com/ghazlsinjab80/spotify-mini-player Built for the Verified Frontend Internship · Final project

Shipped: Public repository search

A grid of my personal GitHub repos. The results are loaded once into the site, and searching and sorting are done locally; you can sort them by recent commits, stars, creation date, and name. Clicking one of the cells will open a modal showing the stats of the repository along with a link to it. Repository: https://github.com/MedicMedic/Stellar-s-Public-Repos Built for the Verified Frontend Internship · state and data

Shipped: Comparison table for three plans

I built a responsive, keyboard-accessible comparison table for three plans with around 15 features and a “Show differences only” control. A reviewer can verify the acceptance criteria by: Using only the keyboard: Tab through the interface and use Enter/Space on the comparison button. Focus indicators are clearly visible. Checking the Tab order, which follows the visual order. Testing the page at 320px width; the layout switches to a stacked mobile presentation with no horizontal scrolling. Inspecting the table with accessibility tools or a screen reader; it uses semantic <table , <caption , <thead , <tbody , and properly scoped row/column headers. Activating “Show differences only” and confirming that identical features are hidden while the feature names and remaining plan values stay understandable. Reviewing the README for the keyboard-operation details and the reasoning behind the narrow-screen treatment. Repository: https://github.com/vanshika2723/Accessible-Plan-Comparison.git Live: https://vanshika2723.github.io/Accessible-Plan-Comparison/ Built for the Verified Frontend Internship · accessible layout

Shipped: Personal reading list

What did you build? I built a responsive Personal Reading List web application using HTML, CSS, and JavaScript. Users can add articles/resources with a title and URL, view saved items, and remove items. The reading list uses browser localStorage for persistent data. How can a reviewer see that the acceptance criteria are met? Loading state: Open ?state=loading and the loading state will be displayed before the content loads. Error state: Open ?state=error to see the error message explaining what failed and providing a Try Again action. Empty state: Open ?state=empty to see an explanation of the reading-list feature and an Add your first article action. Normal data state: Add an article using the form and verify that it appears in the reading list and remains available after refreshing. Responsive design: Test the application on mobile and desktop widths; the layout adapts without horizontal scrolling. Accessibility: Use keyboard Tab navigation to verify visible focus states and use Enter/Space to operate buttons. Documentation: The README contains the exact steps and URLs for testing all three states without making any code changes. Live Demo: https://vanshika2723.github.io/Personal-reading-list/ Repository: https://github.com/vanshika2723/Personal-reading-list.git Live: https://vanshika2723.github.io/Personal-reading-list/ Built for the Verified Frontend Internship · state and data

UstaMarketplace Demo

I built a web site where people can find a 1 time job, in a nutshell, freelancing. However, it's not about programming, SMM like on UpWork, it includes jobs like electrician, plumbing, and etc. GitHub : https://github.com/SuhrobbekJorayev/ustamarketplace Link Demo : https://ustamarketplace.onrender.com/ What I used: Backend : -- Python -- Django -- JWT (Auth) -- Django-rest-framewrok Frontend : -- HTML5 -- CSS (Bootstrap 5) -- JavaScript (ES6+) DevOps : -- Deployed on Render -- Backend, Frontend, Database services on render Database : -- PostgreSQL How to use that web site : You get registered first to open an account, then login with your account. And you can be either a worker or a client. Clients : They can order a service from workers by browsing and choosing the ones they need. Workers : They can place services as much as they want, placing also name, price, work experience, and etc. They are not allowed to place an order, since they are not clients, only clients are allowed to place orders. You can see the whole experience on my website. Link up there 👆. Services run out of time (free for 30 days), and I redeploy sometimes. Therefore, if database isn't working, it's because it has expired. But I try to rerun database ASAP (as soon as possible), so others can see my work again. demo

Shipped: Three decisions, written down

A small React app called GitHub Repository Explorer. You type in any public GitHub repo (like facebook/react) and it tells you something GitHub doesn't show you directly: how much of that project depends on one person. It looks at the top contributor's share of commits and gives you a simple healthy, caution, or risk label. Three decisions: 1. I used React + Vite instead of just plain HTML/CSS/JS. 2. I call GitHub's API directly from the browser — and this one bit me later. 3. I picked one metric instead of building a whole dashboard. How a reviewer can check it: Commit history: run git log --oneline in the repo — you'll see it built up in steps , not dumped in one commit. README works on its own: it explains what the app does, how to run it (npm install then npm run dev), how to use it, and what it doesn't do. Handles a slow or broken connection to GitHub: every request times out after 8 seconds instead of hanging forever, and shows a clear message if the repo doesn't exist, if GitHub's rate limit is hit, or if there's no internet. You can test this by searching a fake repo name, or turning off your wifi and trying a search. Live link: https://git-repository-explorer.vercel.app/ Honest about limits: the README says plainly that the top-contributor number is just a commit count — it doesn't measure code quality, and it's not an official GitHub rating. Repository: https://github.com/hassannnn13/devConnect-Internship-Final-Project.git Live: https://git-repository-explorer.vercel.app/ Built for the Verified Frontend Internship · Documentation

Shipped: The data model, explained

Updated README.md file Repository: https://github.com/Sheryar7/devconnect-background-job-service Built for the Verified Backend Internship · Documentation

Shipped: Bookmark service

The project code has been pushed to GitHub, and the server is deployed and running on Render. I also included the Postman API collection in the repository, so you can import it directly into your Postman workspace and test all the endpoints against the live API. Repository: https://github.com/abbasg-dev/bookmark-api Live: https://bookmark-api-cy0b.onrender.com/ Built for the Verified Backend Internship · an API that survives bad input

Shipped: Short link service

I built a Flask and SQLite short-link service: https://github.com/quratulain-nayeem/api-suviver A reviewer can run it using the README instructions. POST /links creates a short code, GET /<code redirects and increments the visit count, and GET /links/<code displays statistics. Unknown codes return 404, malformed URLs return 400 before storage, and submitting the same URL twice returns the same code. The service uses 302 redirects, with the caching and visit-count reasoning documented in the README. Repository: https://github.com/quratulain-nayeem/api-suviver Built for the Verified Backend Internship · an API that survives bad input

Shipped: Library loans

Built a FastAPI/SQLite library-loans API with four related tables and 11,000 seeded loan records. The README includes before/after query plans and benchmarks showing the endpoint runs under 200 ms. Database constraints prevent double lending, and automated tests verify all requirements. Repository: https://github.com/quratulain-nayeem/library-loans-api Built for the Verified Backend Internship · a data model and the queries on it

Shipped: A service with a job running behind it

Project Overview I built an asynchronous Background Job Processing Service using Node.js, Express, MySQL (TiDB Cloud Serverless with TLS/SSL), and deployed it to Render. The architecture consists of: 1. REST API Server: Accepts job requests, validates authentication, enforces user scoping, and guarantees idempotency. 2. Background Worker: Polls pending tasks from the database, executes the job asynchronously, tracks attempt limits, and updates the status upon completion. 3. Persistent Database: Managed TiDB Cloud database storing jobs, idempotency keys, execution statuses, and timestamps. --- How to Test and Verify Acceptance Criteria Base URL: https://final-project-5nyu.onrender.com Auth Token: supersecrettoken123 1. Submit a New Job (POST /jobs) Run the following curl command to submit a background job: bash curl -X POST https://final-project-5nyu.onrender.com/jobs \ -H "Content-Type: application/json" \ -H "Authorization: Bearer supersecrettoken123" \ -H "x-user-id: user 101" \ -d '{"idempotencyKey": "demo-key-001"}' Expected Output: Returns HTTP 202 with jobId and status: "pending". 2. Check Job Status (GET /jobs/:id) Allow 1-2 seconds for the worker to process the job, then retrieve the status: Bash curl -X GET https://final-project-5nyu.onrender.com/jobs/1 \ -H "Authorization: Bearer supersecrettoken123" \ -H "x-user-id: user 101" Expected Output: Returns HTTP 200 with status: "completed" and execution details (processedAt). 3. Test Idempotency (Duplicate Prevention) Re-run the exact same POST request with the same idempotencyKey: Bash curl -X POST https://final-project-5nyu.onrender.com/jobs \ -H "Content-Type: application/json" \ -H "Authorization: Bearer supersecrettoken123" \ -H "x-user-id: user 101" \ -d '{"idempotencyKey": "demo-key-001"}' Expected Output: Returns HTTP 200 with the existing jobId and message "Job already registered" without creating a duplicate record. 4. Test Authentication & User Isolation Missing/invalid Authorization header returns HTTP 401 Unauthorized. Missing x-user-id header returns HTTP 401 Missing user identity. Repository: https://github.com/roh155/final project Live: https://final-project-5nyu.onrender.com Built for the Verified Backend Internship · Final project

Shipped: The data model, explained

I built a production-ready asynchronous Background Job Processing Service using Node.js, Express, and MySQL (TiDB Cloud Serverless with TLS/SSL), and deployed it to Render. Live Demo: https://final-project-5nyu.onrender.com GitHub Repository: https://github.com/roh155/final project Reviewers can test and verify the acceptance criteria using the following cURL commands: 1. Submit a New Job (POST /jobs): curl -X POST https://final-project-5nyu.onrender.com/jobs \ -H "Content-Type: application/json" \ -H "Authorization: Bearer supersecrettoken123" \ -H "x-user-id: user 101" \ -d '{"idempotencyKey": "demo-key-001"}' 2. Check Job Status (GET /jobs/:id): curl -X GET https://final-project-5nyu.onrender.com/jobs/1 \ -H "Authorization: Bearer supersecrettoken123" \ -H "x-user-id: user 101" 3. Test Idempotency (Duplicate Prevention): Re-run the same POST request with the same idempotencyKey to verify duplicate protection. 4. Security & Isolation: Missing Authorization or x-user-id headers are strictly guarded and return 401 Unauthorized. Repository: https://github.com/rohi55/final project Live: https://final-project-5nyu.onrender.com/ Built for the Verified Backend Internship · Documentation

Shipped: A guide for the next contributor

In this README.md, it includes how to run, the API needed, how to use, how to test, its limitations, and crucial decisions. Repository: https://github.com/MedicMedic/CryptoTracker Built for the Verified Frontend Internship · Documentation

Shipped: CryptoTracker

This is my take on a CryptoTracker. I've noticed that many cryptocurrency websites these days are confusing and brightly colored, with so many random numbers that can be overwhelming. Clicking one of them opens a modal (unlike other websites that lead to a new page) that shows the latest 48 hours and a naive prediction of where the price could go, along with an hourly compilation of prices. Repository: https://github.com/MedicMedic/CryptoTracker Built for the Verified Frontend Internship · Final project

Shipped: Bookmark service

What Was Built A bookmark service API with validation at the boundary — rejecting bad input before it reaches business logic. Quick Demo npm install && npm start Create curl -X POST localhost:3000/bookmarks -H "Content-Type: application/json" -d '{"url":"https://github.com","title":"GitHub"}' Duplicate (returns 200, not 201) curl -X POST localhost:3000/bookmarks -H "Content-Type: application/json" -d '{"url":"https://github.com","title":"Diff"}' List (shows 1 row) curl localhost:3000/bookmarks Bad input (returns 400 with field name) curl -X POST localhost:3000/bookmarks -H "Content-Type: application/json" -d '{"url":"not-url"}' Acceptance Criteria Verification 1. Three or more endpoints, each returning a documented status code The service has four endpoints: - POST /bookmarks → returns 201 (created), 200 (duplicate), or 400 (validation error) - GET /bookmarks → returns 200 with array of bookmarks - GET /bookmarks/:id → returns 200, 400 (bad ID), or 404 (not found) - DELETE /bookmarks/:id → returns 204, 400, or 404 2. Malformed input returns 400 with a message naming the field Test it: curl -X POST localhost:3000/bookmarks -H "Content-Type: application/json" -d '{}' Response: {"error":"validation failed","fields":{"url":"required"}} The error names the field (url) and the rule (required). 3. No input produces a 500 Every validation path returns 400: - Empty body → 400 - Wrong type (number instead of string) → 400 - Missing url → 400 - Invalid url → 400 - Unknown fields → 400 - Long strings exceeding limits → 400 4. The same create request sent twice leaves one row Test it: First request - creates row curl -X POST localhost:3000/bookmarks -H "Content-Type: application/json" -d '{"url":"https://github.com"}' Second request - returns existing, no new row curl -X POST localhost:3000/bookmarks -H "Content-Type: application/json" -d '{"url":"https://github.com"}' List shows only one row curl localhost:3000/bookmarks 5. README explains how repeats are recognized The README has a "Duplicate Detection" section explaining: - URL is used as unique identifier - Database has a UNIQUE constraint on URL - Same URL returns existing bookmark with 200, not a new row - Reasoning: two bookmarks with same URL are the same resource Repository: https://github.com/techtuber9988/bookmark-service Built for the Verified Backend Internship · an API that survives bad input

Shipped: Ticket sales

What Was Built A ticket reservation API with three endpoints: 1. GET /events — lists all events 2. GET /events/:eventId/seats/free — lists free seats for an event (27,040 seats for event 1) 3. POST /seats/:seatId/reserve — reserves a seat with race-condition protection Acceptance Criteria — How to Verify 1. Three or more related tables with foreign keys node -e "const db = require('./db'); console.log(db.prepare(\"SELECT sql FROM sqlite master WHERE type='table'\").all().map(r = r.sql).join('\n\n'))" Shows events, seats (FK to events), and orders (FK to seats) with constraints. 2. At least 10,000 seeded rows npm run seed node -e "const db = require('./db'); console.log('Seats:', db.prepare('SELECT COUNT( ) as c FROM seats').get().c)" Outputs Seats: 135200. 3. Listing free seats responds in under 200ms npm start node race-test.js or time the endpoint Response time: 20ms for 27,040 seats. 4. Two concurrent reservations cannot both succeed node race-test.js Outputs: Request 1 (Alice): Status 201 Request 2 (Bob): Status 409 SUCCESS: Only one reservation went through 5. README shows query plan before and after index node queryplan.js Outputs: - Before: SEARCH s USING INDEX sqlite autoindex seats 1 (event id=?) - After: SEARCH s USING COVERING INDEX idx seats event status (event id=? AND status=?) Repository: https://github.com/techtuber9988/ticket-sales Built for the Verified Backend Internship · a data model and the queries on it

Shipped: Public repository search

I built a React + TypeScript GitHub repository search application that fetches public repositories from the GitHub REST API and clearly handles loading, error, empty, and successful result states. The acceptance criteria can be verified directly from the deployed app: ▪ Search "react" to see successful repository results. ▪ Click "Test error state" to intentionally trigger a failed API request and verify the error state and recovery guidance. ▪ Search "this-query-should-not-match-anything-987654321-abcdef" to verify the successful empty-results state. ▪ The README document how to reproduce all required states without modifying the code. The repository is pushed to GitHub and the application is deployed to Vercel. Tools and technologies used: React, TypeScript, Vite, TanStack React Query, React Hook Form, Yup, yupResolver, SCSS, and the GitHub REST API. Repository: https://github.com/abbasg-dev/github-repository-search Live: https://github-repository-search-kappa.vercel.app/

Shipped: Library loans

Built a library loans REST API using Node.js, Express.js, MongoDB Atlas, Mongoose, Zod. The app includes related Books, Copies, Members, and Loans models with foreign keys, 15,000 seeded loans, a member loans endpoint ordered by most recently borrowed, and a MongoDB partial unique index that prevents a copy from being actively loaned twice. How to verify the acceptance criteria: ▪ Application code is pushed to the GitHub repository. ▪ Server is deployed on Render Cloud. ▪ Database is hosted on MongoDB Atlas. ▪ API endpoints were tested using Postman. ▪ The Postman collection is included in the GitHub repository so the reviewer can import it and test the APIs. ▪ The README includes the query plans before and after the performance index, along with the performance measurements. ▪ The MongoDB constraint demonstrates that double lending is prevented at the database level. Repository: https://github.com/abbasg-dev/library-loans-api Live: https://library-loans-api.onrender.com Built for the Verified Backend Internship · a data model and the queries on it

Shipped: A service with a job running behind it

What Was Built A CSV Import Service — a REST API that accepts CSV file uploads, processes them in the background, and returns results asynchronously. The key pattern: the upload request returns instantly (HTTP 202), and a background worker handles the slow part. Repository: https://github.com/techtuber9988/behind-the-service Live URL: https://behind-the-service.onrender.com How to Verify Each Criterion 1. Deployed and reachable with repository linked - Visit https://behind-the-service.onrender.com/health — returns {"status":"ok"} - Repository is public at the GitHub link above 2. Request returns without waiting curl -X POST https://behind-the-service.onrender.com/auth/register \ -H "Content-Type: application/json" \ -d '{"email":"reviewer@test.com","password":"testpass123"}' Copy the token, then: curl -X POST https://behind-the-service.onrender.com/imports \ -H "Authorization: Bearer <token " \ -F "file=@any.csv" Returns 202 instantly — processing happens after 3. Same outcome when run twice (idempotent) Use same Idempotency-Key header twice: curl -X POST https://behind-the-service.onrender.com/imports \ -H "Authorization: Bearer <token " \ -H "Idempotency-Key: test-key-123" \ -F "file=@any.csv" Second call returns existing job, not a duplicate 4. README documents worker death Section titled "What Happens When the Worker Dies Mid-Job" with state diagram and 5 guarantees — data never lost, caller can detect stuck jobs, partial progress preserved. 5. 401 without credentials curl -s -o /dev/null -w "%{http code}" \ https://behind-the-service.onrender.com/imports/any-id Returns 401 6. No secrets committed .env is in .gitignore. JWT SECRET is only in Render's environment variables, never in the repository. Repository: https://github.com/techtuber9988/behind-the-service Built for the Verified Backend Internship · Final project

Shipped: The data model, explained

I built an enterprise-grade database architecture for a document management system. This consists of three main components: the actual database schema, the technical documentation, and a high-end visual presentation. First, the core engine is a PostgreSQL schema. I implemented a multi-tenant design where every piece of data is isolated by a workspace ID, so different clients never see each other's data. To ensure total data integrity, I used an immutable versioning system. This means the system never updates a document's content; instead, it saves a new version every time a change is made, creating a permanent, unchangeable history. I also built a granular permission system for role-based access and an append-only audit log that uses JSONB to track every single action for compliance purposes. Second, I wrote a detailed architectural guide in the data model file. This isn't just a list of tables; it's a technical justification of the design. I explained why I chose UUIDs over integers, how the constraints prevent data corruption, and provided the exact query plans to prove that the system remains fast even as the amount of data grows. I even included a "failure analysis" section that predicts exactly where the system will struggle at 10x scale and how to fix it. Third, I created a premium web preview using HTML and CSS. This acts as a visual a brochure for the architecture. It uses a modern dark-theme aesthetic with interactive animations and a custom SVG visualization of the database engine, making the technical specs easier to communicate to non-technical stakeholders. To verify that this meets the requirements, a reviewer should start by running the SQL file against a PostgreSQL instance to ensure it is syntactically correct. They should then check the schema for the specific unique constraints on document versions and the check constraints on user roles to confirm that the business rules are enforced at the database level. Finally, they should read the design decisions in the documentation to verify that the architectural choices, like using a composite index for workspace slugs, are correctly implemented for performance. Repository: https://github.com/techtuber9988/document-model Built for the Verified Backend Internship · Documentation

Shipped: A rebuild of one feature you use

I built a responsive Personal Reading List feature using HTML, CSS, and JavaScript. Users can add, view, open, and remove saved resources, with data persisted using localStorage. The reviewer can verify the acceptance criteria through the README, which includes local setup instructions, keyboard accessibility details, failure-state testing, and a comparison with the original feature. Loading, error, and empty states can be demonstrated using the documented URL parameters without changing the code. Live demo: https://vanshika2723.github.io/Personal-reading-list/ Repository: https://github.com/vanshika2723/Personal-reading-list.git Live: https://vanshika2723.github.io/Personal-reading-list/ Built for the Verified Frontend Internship · Final project

Shipped: A guide for the next contributor

I documented the Personal Reading List project for future contributors. The documentation explains the code layout and architectural reasoning, where new features should be added, which files may need to be changed, how to run and check the project, what a passing run looks like, and which parts of the application are fragile. The repository includes both a user-facing README and a contributor-focused CONTRIBUTING.md so that another developer can understand, run, test, and safely extend the project. Repository: https://github.com/vanshika2723/Personal-reading-list.git Built for the Verified Frontend Internship · Documentation

Shipped: Recipe with adjustable servings

Built an accessible recipe application with adjustable serving sizes meeting all acceptance criteria: 1. Keyboard accessibility: Full keyboard operability with logical tab order, skip link, and high-contrast :focus-visible outlines on all interactive controls. 2. Screen readers: Used aria-live="polite" live regions to announce serving changes and scaled quantities immediately to assistive technology. 3. Responsive & 320px layout: No horizontal scrolling at 320px. 4. Narrow screen UX: Implemented an accessible mobile tab switcher between Ingredients and Method so users don't have to scroll back and forth repeatedly while cooking. Repository: https://github.com/GhulamMustafaAnsari/accessible-recipe-layout Live: https://ghulammustafaansari.github.io/accessible-recipe-layout/ Built for the Verified Frontend Internship · accessible layout

Shipped: Public repository search

Built a public GitHub repository search view against the live GitHub REST API handling all three core states: 1. Loading state: Animated loading spinner and active announcement. 2. Empty state: A search that returned 0 results is explicitly presented as a successful search with 0 matches, not an error. 3. Request failed state: Visual error alert explaining what failed with an interactive 'Try Again' retry button. 4. Reviewer testability: Provided top preset buttons enabling the reviewer to test loading, 0-match empty state, and simulated API error states directly without editing code. Repository: https://github.com/GhulamMustafaAnsari/public-repo-search-states Live: https://ghulammustafaansari.github.io/public-repo-search-states/ Built for the Verified Frontend Internship · state and data

Shipped: A view onto a public dataset

Built an explorer for the live USGS 24-hour seismic GeoJSON dataset: 1. Understanding the raw data: Computes aggregated peak magnitude, average hypocenter depth, and filtered categories (2.5+, 4.5+) not immediately obvious in raw JSON. 2. Resilience: Uses an AbortController for network timeouts and provides an in-place retry mechanism. A 'Simulate Timeout / Fail' button allows reviewer testing without code changes. 3. Analytical boundaries: Documented in the README and UI what the dataset establishes (recorded ground motion) vs what it cannot claim (earthquake prediction or structural damage). Repository: https://github.com/GhulamMustafaAnsari/earthquake-dataset-viewer Live: https://ghulammustafaansari.github.io/earthquake-dataset-viewer/ Built for the Verified Frontend Internship · Final project

Shipped: A README for a stranger

Provided an exhaustive, reviewer-ready README.md satisfying all brief criteria: 1. Stranger-ready setup: Documents concrete minimum runtime versions (Node.js v18+, Python 3.8+, modern browser versions) with 3 independent ways to run locally under 5 minutes without assumptions. 2. Environment variables: Fully audits all variables/endpoints, showing default fallbacks and confirming zero secret requirements. 3. Architecture decisions: Explains zero-dependency vanilla choices and AbortController timeout mechanisms. 4. Analytical limits & honesty: Explicitly outlines what the data establishes versus what it cannot claim (earthquake prediction, structural damage), alongside known technical constraints (50-item display cap, mock service limits). Repository: https://github.com/GhulamMustafaAnsari/earthquake-dataset-viewer Live: https://GhulamMustafaAnsari.github.io/earthquake-dataset-viewer/ Built for the Verified Frontend Internship · Documentation

Shipped: Job Application Tracker

I built a Job Application Tracker, a small personal tool for managing and tracking job applications and their current status. The reviewer can verify the acceptance criteria directly from the deployed application: ● Add job applications with company, job title, location, date, status, job URL, and notes. ● Search and filter applications by status. ● Edit application status and delete applications. ● Refresh the page to verify that applications persist through localStorage. ● Remove all applications to demonstrate the empty state. ● Submit the form with missing or invalid fields to demonstrate validation and failure handling. ● The application also handles corrupted stored data and provides a recovery option. ● The README includes local setup instructions, state-handling details, and a section explaining what was deliberately not implemented. The project repository has been pushed to GitHub with a development history, and the application has been deployed to Vercel. Technologies used: React, TypeScript, Vite, Redux Toolkit, React Redux, React Hook Form, Yup, yupResolver, SCSS, and browser localStorage. Repository: https://github.com/abbasg-dev/job-application-tracker Live: https://job-application-tracker-xi-jet.vercel.app/ Built for the Verified Frontend Internship · Final project

Shipped: Three decisions, written down

I updated the README for the Canva Export Menu replica to fully satisfy the documentation requirements. You can verify the acceptance criteria by scrolling down to the 'Architectural Decision Record' section in the README on GitHub. It includes: Three major technical decisions (Vanilla JS over frameworks, proactive offline checking, and CSS pseudo-elements for toggles). The alternatives that were considered for each. The explicit costs/downsides of each decision. The third decision (Pure CSS Toggles) explicitly describes an approach that has since proved awkward to maintain. Repository: https://github.com/Carmy4/canva-export-menu Live: https://carmy4.github.io/canva-export-menu/ Built for the Verified Frontend Internship · Documentation

Shipped: Short link service

A short-link HTTP service (Express + TypeScript + MongoDB) that turns a long URL into an 8-character code, redirects visitors to the target, and counts clicks. Endpoints under /v1/api : POST to create ( 201 new / 200 if it already exists), GET /:code to follow ( 302 ), and GET /links/:code/stats for click counts. - Create / follow / count work — test/url.test.ts covers all three end-to-end: fresh code on create, 302 with correct Location , and clicks: 3 after three visits. - 301 vs 302 justified — explicit 302 in src/controller/url.controller.ts ; rationale in README.md ("A note on the redirect"): a cached 301 would bypass the server and undercount clicks, and make links un-editable. - Unknown code → 404 — test asserts 404 with {"error":"shortId: no link found with this code"} , never a silent 200 . - Malformed URL → 400 before storage — validateCreateUrl returns a field-naming error for each case (missing, non-string, empty, 2048 bytes, non-http(s)); tests assert all ten cases return 400 and the DB count stays 0 . - Same URL twice → one code — reverse lookup returns the existing code with created: false , backed by a unique index on redirected url (race fallback catches duplicate-key 11000 ); test verifies the same code and exactly one document. Repository: https://github.com/Firefist111/Short-link Built for the Verified Backend Internship · an API that survives bad input

Shipped: A service with a job running behind it

I built and deployed an asynchronous digest service using Node.js, Express.js, MongoDB Atlas, Mongoose, JWT, bcryptjs, Zod, and JavaScript-based background workers. The API authenticates users, isolates user-owned data, accepts digest requests asynchronously, and returns "202 Accepted" without waiting for the background work to finish. Digest jobs are stored in MongoDB and processed by a separate worker with idempotency, retry handling, stale-job recovery, and actionable error states. The service also uses an in-memory cache for completed digest responses. The application code is pushed to GitHub, the API server is deployed on Render, the background worker is deployed as a separate Render Background Worker, and the database is deployed on MongoDB Atlas. The API has been fully tested with Postman, and the complete Postman collection is included in the GitHub repository so the reviewer can import it and test the endpoints directly. How the reviewer can verify the acceptance criteria ● Deployed and reachable: Open the deployed Render API URL and call "/health". The GitHub repository is linked in the project documentation. ● Request returns without waiting: Send "POST /api/v1/digests" with valid authentication and an "Idempotency-Key". The API immediately returns "202 Accepted", while the separate Render background worker processes the job afterward. ● Safe to run twice: Send the same digest request again using the same "Idempotency-Key". The existing digest is returned instead of creating a duplicate. ● Worker failure handling: The README documents the "QUEUED → PROCESSING → COMPLETED/FAILED" lifecycle, retry attempts, stale-job recovery, and what happens if the worker dies during processing. ● Authentication: Call a protected endpoint without an "Authorization" header. The API returns "401 Unauthorized". ● User isolation: Digest and event queries are scoped to the authenticated user's ID, preventing one user from reading another user's records. ● Actionable errors: The API returns structured "400", "401", "404", "409", and "500" responses with machine-readable error codes and human-readable messages. ● Caching: Completed digest responses are cached in application memory for 60 seconds, with MongoDB remaining the source of truth. ● No committed secrets: ".env" is excluded through ".gitignore". ● API testing: The included Postman collection contains the complete authentication, protected-route, event, digest, retry, and health-check flows and can be imported directly by the reviewer. Repository: https://github.com/abbasg-dev/async-digest-service Live: https://async-digest-service.onrender.com Built for the Verified Backend Internship · Final project

HeritageAI

Building HeritageAI 🎙️🤖 — a voice-controlled PowerPoint assistant that lets presenters navigate slides hands-free using natural voice commands. Currently improving it with smarter speech interpretation and AI-powered presentation features. 🚀 🔗 https://bit.ly/4Aj9LP0 AI MachineLearning VoiceAI Python HeritageAI

Shipped: Currency converter with live rates

I built a responsive currency converter using React and Vite. It fetches live exchange rates from the Frankfurter API and handles four distinct states: Loading, Error, Empty, and Success. The reviewer can run the project locally and use the URL query parameters documented in the README to demonstrate each required state without changing the code: Loading: /?state=loading Error: /?state=error Empty: /?state=empty Success: / The README contains step-by-step instructions for reaching and verifying each state. Repository: https://github.com/Ateefa-Syed/currency-converter Built for the Verified Frontend Internship · state and data

Shipped: A tool for a problem you have

What did i build? I built a Coding Practice Tracker, a React-based web application that helps students organize and track their coding practice. Users can add problems with details such as platform, topic, difficulty, link, and status. The app also supports editing, deleting, searching, filtering, and tracking progress through a dashboard. Data is stored using LocalStorage. How can a reviewer see that acceptance criteria are met? The reviewer can open the deployed application and test the main features directly. The GitHub repository contains the source code and development history. The README includes local setup instructions, project scope, and deliberately unimplemented features. The application also handles form validation, empty states, and no-result states. Repository: https://github.com/Ateefa-Syed/coding-practice-tracker Live: https://coding-practice-tracker.vercel.app/ Built for the Verified Frontend Internship · Final project

Shipped: Three decisions, written down

I created documentation for my Coding Practice Tracker project. I added a decision record in DECISIONS.md covering three important technical decisions, the alternatives considered, the reasons for choosing them, and the trade-offs of each decision. I also updated the README with the project architecture, setup instructions, and a link to the decision record. The reviewer can open the GitHub repository and check DECISIONS.md for the three documented decisions, alternatives, reasoning, and costs/trade-offs. The README explains the application architecture and how to run the project locally, and it links directly to the decision record. The documentation is written so the reasoning can be understood without needing prior knowledge of the code. Repository: https://github.com/Ateefa-Syed/coding-practice-tracker Built for the Verified Frontend Internship · Documentation

Shipped: Short link service

I built Ashorty, a full-stack URL shortener with a React/Vite frontend, Express API, PostgreSQL persistence, URL validation, normalization, duplicate URL reuse, random short codes, redirects, click tracking, and link statistics. It also includes a responsive light/dark interface, Vercel deployment configuration, an MIT license, and the DevConnect badge. A reviewer can verify the acceptance criteria by running npm install , npm test , and npm run build . The tests confirm link creation, redirects, click counting, invalid URL rejection, unknown-code handling, duplicate URL reuse, and URL normalization. For manual review, they can run the API and frontend, create a short link, open it, confirm the redirect and increased click count, view statistics, test search and remove actions, and check the /health endpoint. Repository: https://github.com/azizulabedinazmi/Ashorty-Url-Shortener Live: https://ashorty.vercel.app/ Built for the Verified Backend Internship · an API that survives bad input

Shipped: Ticket sales

I built Seatline, a ticket-sales API and browser interface backed by events, seats, and orders tables with foreign keys, indexes, and PostgreSQL support for Vercel, with SQLite available locally. A reviewer can run npm install , configure DATABASE URL , and run npm run seed to create 100 events and 10,000 seats, then open the deployed URL to see the API status, load an event, select a free seat, and reserve it through the UI. The acceptance criteria can be verified with npm run plan to inspect the indexed free-seat query, npm run benchmark to confirm listing performance stays below 200 ms, and npm run race to send two concurrent reservations for the same seat and observe exactly one 201 Created response and one 409 Conflict , proving that PostgreSQL row locking prevents both requests from succeeding. Repository: https://github.com/azizulabedinazmi/SEATLINE-Ticket-sales-API Live: https://seatline.vercel.app/ Built for the Verified Backend Internship · a data model and the queries on it

Shipped: Three decisions, written down

I built the documentation for mern-auth-client, a React SPA with email-activated sign-up, sign-in, Google/Facebook login, password reset and role-gated pages. README.md covers the architecture, route table, session flow, run steps for macOS/Linux and Windows, and known issues. DECISIONS.md records three costly-to-reverse decisions (own identity system, JWT in a JS-readable cookie plus localStorage, and a CRA SPA on a separate host). Each entry lists the alternatives considered, the reason for the choice, its cost, and the cost to reverse. The criteria map one-to-one to its headings: "Alternatives considered" and "What it costs" in each entry, and the "Status: proved awkward" label on Decision 2 (the jsonwebtoken-in-the-browser fallout is also called out under Decision 1). Repository: https://github.com/abbasg-dev/mern-auth-client Built for the Verified Frontend Internship · Documentation

Shipped: The data model, explained

I built the documentation for mern-auth-api, an Express/MongoDB auth API with one users collection. README.md covers every endpoint with its real status codes (including the handlers that hang), local setup with env vars and a seed script, and eight decisions I'd revisit at ten times the traffic. DATA MODEL.md describes the collection field by field and the implicit links between documents, and has a constraints table with what each rule prevents. It lists the queries that carry the load with the index each uses, names the unindexed reset-token lookup as the one that breaks first at 10x, and includes the commands and seed script to capture the explain() plans. Repository: https://github.com/abbasg-dev/mern-auth-api Built for the Verified Backend Internship · Documentation

Shipped: A service with a job running behind it

I built and deployed relay/digest, a Vercel-hosted service that accepts authenticated CSV imports through a responsive dashboard and returns immediately with 202 Accepted , while Vercel Cron processes the import in the background. A reviewer can visit https://relay-digest-api.vercel.app and enter the configured AUTH TOKEN , submit the sample CSV, and observe the import move from queued to completed . The service uses account-scoped database queries so users cannot read another account’s rows, idempotency keys and unique database constraints make retries safe, and worker leases recover jobs that die mid-processing while storing visible errors. The protected API returns 401 Unauthorized without credentials, CRON SECRET protects the scheduled worker, the README documents failure recovery and deployment, the repository contains the requested DevConnect badge and MIT license, and secrets are supplied through environment variables rather than committed to source. Repository: https://github.com/azizulabedinazmi/Relay-Digest-API Live: https://relay-digest-api.vercel.app/ Built for the Verified Backend Internship · Final project

Shipped: A README a reviewer can follow

I built Task Desk, a deployable task-management application with a responsive web interface and JSON API. A reviewer can visit https://task-desk-api.vercel.app to see the working UI, add tasks, search and filter them, mark them complete, delete them, and confirm the service status. The API can be verified at /api/health and /api/tasks, while the README documents the data model, environment variables, local setup, Vercel deployment, endpoint inputs and outputs, success and failure status codes, Mermaid request flow, known limitations, and scaling decisions. The repository also includes an MIT license, concrete Node.js prerequisites, and the DevConnect badge, allowing the reviewer to clone, run, inspect, and test the project without additional guidance. Repository: https://github.com/azizulabedinazmi/Task-Desk-API Live: https://task-desk-api.vercel.app/ Built for the Verified Backend Internship · Documentation

Shipped: Recipe with adjustable servings

A pancake recipe with a servings stepper. Every ingredient quantity and every quantity mentioned in the method text is driven from one data source and recalculated when servings change nothing is hand duplicated, so the two never drift out of sync. Repository: https://github.com/rocklegend14/Fluffy-buttermilk-pancakes Live: https://fluffy-buttermilk-pancakes.vercel.app/ Built for the Verified Frontend Internship · accessible layout

Shipped: Personal reading list

A single web page for saving the books, articles, and links you want to get back to. Entries persist in the browser's local storage, accessed through a small async api layer (list, add, remove) that mimics a real REST backend including latency and failures so the loading and error states are genuine, not just mocked up visuals. Repository: https://github.com/rocklegend14/personal-reading-list Live: https://personal-reading-list-black.vercel.app/ Built for the Verified Frontend Internship · state and data

Shipped: E-Commerce Price Tracker watches Amazon & Daraz, emails you when the price drops

Ever kept refreshing a product page waiting for a sale? I automated that. Paste any Amazon / Daraz product URL + your target price, and it scrapes the live price, stores the history, re-checks every few hours, and emails you the moment it hits your target. What it does - 🔎 Live price scraping (works behind bot protection) - 📉 Full price history per product - ⏰ Auto re-check every few hours (Celery Beat) - 📧 Email alert when target price is hit - 🌐 REST API + Web UI + CLI Tech stack - Backend: Python, FastAPI, Pydantic - Background jobs: Celery + Celery Beat + Redis - DB: PostgreSQL, SQLAlchemy, Alembic migrations - Scraping: Selenium, undetected-chromedriver, BeautifulSoup, cloudscraper - Alerts: SMTP + Jinja2 templates Hardest parts - Anti-bot protection — plain requests gets blocked instantly. Ended up with undetected-chromedriver in headless mode, cloudscraper as a lighter fallback. - HTML keeps changing — Daraz especially. Built multi-selector fallback logic so one broken selector doesn't kill the whole scrape. - Parallel checks — moved from a loop to a Celery task queue so hundreds of products get checked concurrently. - Proper schema — versioned Alembic migrations, not a throwaway script. Same architecture works for competitor price monitoring, stock/availability alerts, or any "watch a site and notify me" automation. 🔗 Code: https://github.com/danish614 🌐 Portfolio: https://lnkd.in/dXE58DgU

Shipped: Short link service

GitHub repo URL ↓ Paste in box above ↓ Submit ↓ Automatic check ✅ Repository: https://github.com/garima-2006/Short-Link-Service Built for the Verified Backend Internship · an API that survives bad input

Shipped: Personal reading list

I built a Personal Reading List web application using React and Vite, backed by the Open Library Search API. Reviewers can search for books, view book details, add books to their personal reading list, remove them, and refresh the page to verify that the list persists through browser localStorage . The application includes clearly separated loading, error, and empty states. To make the acceptance criteria easy to verify without changing the code, the Reviewer Demo section at the top provides buttons for Show loading state, Show error state, and Show empty state, plus Reset demo. The empty reading-list state also explains the purpose of the list and how to add the first book, while the error state explains what failed and what the reviewer should do. Reviewers can therefore test all required states directly from the live application, while the README documents the implementation, setup, API, persistence, and state demonstrations. Repository: https://github.com/kiths-bit/personal-reading-list Live: https://personal-reading-list-beryl.vercel.app/ Built for the Verified Frontend Internship · state and data

Shipped: A rebuild of one feature you use

What I built & how to review it: I rebuilt GitHub’s repository search as a focused React/Vite application using the public GitHub REST API. The reviewer can verify the acceptance criteria by opening the deployed application, searching for repositories, and testing the initial empty state, loading state, successful results, no-results state, and API error/retry flow. The complete search experience is keyboard accessible with visible focus states, and the layout can be tested at a 320px viewport without horizontal scrolling. The GitHub repository contains the development history and README with setup instructions, scope, accessibility considerations, omitted features, and the comparison with the original GitHub feature. Repository: https://github.com/kiths-bit/github-repository-search Live: https://github-repository-search-seven.vercel.app/ Built for the Verified Frontend Internship · Final project

Shipped: Bookmark service

I built a Node/Express/Mongoose bookmark API with CRUD endpoints, strict URL validation, and duplicate detection by normalized lowercase trimmed URL. A reviewer can see the criteria in the README and tests: malformed input returns 400 with a message naming the url field, duplicate create requests keep only one row, and the API exposes create/list/get/delete flows with documented status codes. Repository: https://github.com/Tushar-Sharma-hub/Bookmark-Service Built for the Verified Backend Internship · an API that survives bad input

Shipped: A README for a stranger

What I built and how the acceptance criteria are met: I built a React + Vite GitHub Repository Search application that allows users to search GitHub repositories through the public GitHub REST API and view repository details such as name, description, language, stars, and last updated date. The README is written for a first-time user and provides concrete prerequisites, installation and run commands, environment-variable requirements, architecture, project structure, design decisions, available commands, and known limitations. A reviewer can verify the acceptance criteria directly by following the README from a fresh clone, running the documented commands, and checking the documented idle, loading, results, empty, and error states. The implementation also includes responsive behavior, visible keyboard focus states, semantic HTML, and accessible status/error messaging. The project was additionally verified with npm run lint (0 warnings/errors) and npm run build (successful production build). Repository: https://github.com/kiths-bit/github-repository-search Built for the Verified Frontend Internship · Documentation

Shipped: Recipe with adjustable servings

I built a responsive Pâté Chaud recipe page using React, TypeScript, and Vite. The page includes an ingredient list, an ordered cooking method, and a keyboard-accessible slider that adjusts the recipe for 12, 24, or 36 pastries. Changing the slider recalculates the ingredient quantities and triggers an aria-live announcement for screen-reader users. A reviewer can verify the acceptance criteria by: Using Tab to reach the serving slider and section-navigation links in visual order Using the arrow keys to adjust the slider Confirming that every interactive element has a visible focus indicator Listening for the ingredient-update announcement with a screen reader Testing the page at 320px and confirming there is no horizontal scrolling Confirming that the Ingredients and Method cards stack vertically on narrow screens Using the Ingredients and Method links to move quickly between the two sections Reading the README for setup instructions and an explanation of the narrow-screen design Repository: https://github.com/viveevu11/Adjustable-Recipe Live: https://adjustable-recipe.vercel.app/ Built for the Verified Frontend Internship · accessible layout

Shipped: Conference schedule

What I built: A single page for a two day conference with 3 tracks (Build, Design, Workshop). Sessions are buttons that open a dialog with their details. It's all HTML, CSS and a tiny script, no libraries. On wide screens the 3 tracks are laid out side by side in their time slots. On narrower screens they flow into a single list, sorted by time, with each session noting the track and room. The reasoning is in the README. How a reviewer can check it: Keyboard order: Everything is a real link or button in the order you see them on the page, so tabbing takes you through the items in the same order they're displayed at any viewport width. Visible focus: Tabbing through the page will show an outline on each link and button, including while in the dialog. No horizontal scroll at 320px width: check that the browser window isn't scrolling horizontally at 320px width. Keyboard Operations: Hitting enter on a session opens it in a dialog, which can be dismissed with escape or tabbing to the close button. The focus returns to the session that was opened when the dialog closes. README: Contains an explanation about the choice to stack sessions on narrow screens rather than using tabs or a horizontal scroll. Repository: https://github.com/sindhu-dev02/conference-schedule Live: https://sindhu-dev02.github.io/conference-schedule/ Built for the Verified Frontend Internship · accessible layout

Shipped: Short link service

I built an HTTP short-link service (Node.js + Express) that creates a short code for a URL, redirects on lookup, and tracks how many times each code has been followed. To verify the acceptance criteria: 1. Clone the repo, run npm install then npm start (listens on port 3000). 2. Run npm test — a self-contained test suite (test.js) exercises every criterion automatically and prints "All tests passed." 3. Or check manually with curl: - POST /links with a valid URL → 201, returns a code - POST /links again with the SAME url → 200 with the same code (no duplicate created) - GET /:code → 302 redirect to the original URL, increments its click count - GET /links/:code/stats → shows clicks incrementing - GET /an-unknown-code → 404, not an empty 200 - POST /links with a malformed url (e.g. "not a url") or a missing url field → 400, with the response naming the bad field, and nothing is stored The README explains why the redirect uses 302 rather than 301: a cached 301 would let browsers skip the server entirely on repeat visits, silently breaking the click counter in a way that can't be reversed once caches pick it up. 302 keeps every follow hitting the server so counting stays accurate. Repository: https://github.com/hibaimran107/short-link-service Built for the Verified Backend Internship · an API that survives bad input

Shipped: Conference schedule

I built a responsive two-day conference schedule with three parallel tracks: Frontend, Backend, and Developer Experience. Each session is keyboard accessible and opens a detailed session dialog with proper focus management. Reviewers can use Tab to navigate through the interface, Enter/Space to interact with controls, and Escape to close the dialog and return focus to the triggering session. Visible focus indicators are provided across interactive elements. On desktop, all three tracks are displayed side-by-side for easy comparison, while on narrow screens, a keyboard-accessible track selector displays one track at a time alongside the time column, preventing horizontal page scrolling at 320px. The README documents the responsive design decision, accessibility approach, and keyboard testing checklist. Repository: https://github.com/riki-k-dev/conference-schedule Live: https://riki-k-dev.github.io/conference-schedule Built for the Verified Frontend Internship · accessible layout

Shipped: Conference schedule

Built a conference schedule page for a fictional two-day event (Converge 2026) with Next.js 16 and Tailwind v4. What it does: Day 1 / Day 2 toggle plus Design / Engineering / Product track tabs, so each track's sessions run in parallel without needing separate pages Clicking any session opens a detail modal — abstract, speaker, room, and time — with an "Add to Calendar" link that generates a real Google Calendar event Shared (cross-track) sessions like the keynote and lunch show up under every track automatically instead of being duplicated per track Repository: https://github.com/Akuchi004-prog/Converge Live: https://converge-seven-pied.vercel.app/ Built for the Verified Frontend Internship · accessible layout

Shipped: Bookmark service

Built a zero-dependency Node.js HTTP service for saving bookmarks, with create, list, get-by-id, and delete endpoints. A reviewer can verify the criteria by running node test/acceptance.test.js, which starts the server and automatically checks all five requirements: three-plus endpoints with documented status codes; malformed input (missing url, empty string, a number instead of a string, a 2KB url) returning 400 with a message naming the field; no request producing a 500; and sending the same create request twice leaving exactly one row, since the service keys on the url itself and returns the existing bookmark with a 200 instead of creating a duplicate. The README explains the reasoning behind that dedupe approach and has curl examples for manual verification too. Repository: https://github.com/mohammedoomatia-max/bookmark-service Built for the Verified Backend Internship · an API that survives bad input

Shipped: Library loans

Built a library loan-tracking service on Node's built-in node:sqlite module (no external dependencies). Schema has four related tables — books, copies, members, loans — with foreign keys from copies to books and from loans to copies/members. Seeded with 12,000 loans. GET /members/:id/loans returns a member's currently checked-out books, most recently borrowed first, and responds in under 1ms on the full dataset (well under the 200ms bar) once the idx loans member active borrowed index is added — the README shows the real EXPLAIN QUERY PLAN output and timings both before (0.283ms, table scan + sort) and after (0.005ms, direct index search, no sort) adding it. Double lending is blocked at the database layer by a partial unique index (UNIQUE INDEX ... WHERE returned at IS NULL), not application code — test/acceptance.test.js proves this by inserting directly against the database, bypassing the server entirely, and confirming SQLite itself rejects the second active loan. Run node test/acceptance.test.js to verify all five reviewer checks automatically, or node scripts/measure-query-plan.js to regenerate the before/after evidence. Repository: https://github.com/mohammedoomatia-max/library-loans Built for the Verified Backend Internship · a data model and the queries on it

Shipped: A service somebody else could run

Deployed an accounts-backed habit tracker (Node.js, built-in http and node:sqlite, no external dependencies) at https://habit-tracker-1u6z.onrender.com, repo at https://github.com/mohammedoomatia-max/habit-tracker. Users sign up/log in and get a bearer token; every /habits... route requires Authorization: Bearer <token and returns 401 with a named field if it's missing or invalid. Ownership is enforced by scoping every habit lookup to WHERE id = ? AND user id = ? — a habit that exists but belongs to someone else returns 404, identical to a habit that doesn't exist, so IDs can't be enumerated by watching for 403 vs 404; test/acceptance.test.js proves this with a real two-account test. The retry-safe write path is check-ins: POST /habits/:id/checkins is keyed on (habit id, date) with a UNIQUE constraint as the backstop, so the same check-in sent twice returns the existing row (200) instead of creating a duplicate — reasoning is in the README. All 400 errors return {error, field} naming exactly what was wrong. No secret is committed: password hashing reads a pepper from PASSWORD PEPPER, set as an environment variable on Render, with only a placeholder in the committed .env.example. Run node test/acceptance.test.js to verify the first four reviewer checks automatically (18/18 passing) Repository: https://github.com/mohammedoomatia-max/habit-tracker Built for the Verified Backend Internship · Final project

Shipped: Short link service

i tried build as much as the same which you requested Repository: https://github.com/sarvarbekbro/URL-shortner Built for the Verified Backend Internship · an API that survives bad input

Shipped: Personal reading list

I built a simple state-driven Personal Reading List application powered by the Open Library API, with localStorage persistence that lets users discover, search, add, and remove books. The application includes clearly defined loading, error, empty, discover, and reading list states. Reviewers can verify the error state directly using the built-in demo URL (?demo=error), while the loading and empty states can be reached through normal user interactions — no code changes required. The app also includes keyboard-accessible search with Cmd/Ctrl + K, book search, persistent saved books, and responsive UI. Full setup instructions and state-testing details are documented in the README. Repository: https://github.com/riki-k-dev/reading-list Live: https://riki-k-dev.github.io/reading-list/ Built for the Verified Frontend Internship · state and data

Shipped: Conference schedule

I built a single-page schedule for a two-day conference with three parallel tracks (Build, Design and Ship). It works with the keyboard alone and at 320px wide. It is plain HTML, CSS and JavaScript with no libraries. How parallel tracks work on narrow screens: the page is a list of time slots, not columns. On wide screens the three sessions in a slot sit side by side so you can compare them. On narrow screens they stack under the time heading in the same order. A track filter (All, Build, Design, Ship) and day buttons keep a phone screen short. The reasoning is in the README. How a reviewer can verify it: Keyboard order: press Tab from the top. You pass the skip link, the day buttons, the track filter, then the sessions in time order. There is one DOM order for every layout, so tab order always matches what you see. Visible focus: every button and the skip link shows a 3px orange outline. No horizontal scroll at 320px: set the viewport to 320px wide and confirm there is no sideways scrollbar. Session details without a mouse: press Enter on a session to open its dialog. Escape or the Close button dismisses it, and focus returns to the session you opened. README: explains the narrow-screen decision and includes a short keyboard test checklist. Repository: https://github.com/ibn-azam/NorthLight Live: https://github.com/ibn-azam/NorthLight Built for the Verified Frontend Internship · accessible layout Repository: https://github.com/ibn-azam/NorthLight Live: https://ibn-azam.github.io/NorthLight/ Built for the Verified Frontend Internship · accessible layout

Shipped: A tool for a problem you have

I built Nodex, a local-first JSON visualizer and editor that turns deeply nested JSON data into an interactive graph, making complex structures easier to understand, navigate, and edit. A reviewer can verify the project by: 1. Pasting or editing JSON and seeing it represented as an interactive node graph. 2. Editing primitive values directly from the graph and verifying that the JSON editor updates accordingly. 3. Collapsing and expanding nested objects and arrays to manage complex structures. 4. Using Cmd/Ctrl + K to search for nodes and navigate directly to them. 5. Refreshing the page to verify that the current workspace persists locally. 6. Generating a shareable URL and opening it in a new browser session to restore the same JSON. 7. Exporting the graph as a PNG. 8. Testing empty, invalid, and malformed share-link states to verify that failures are handled without breaking the application. 9. Switching between light and dark themes. The README includes local setup instructions, project architecture, testing details, limitations, and a section explaining what was deliberately not implemented. The repository also contains the project's development history through Git commits. Technologies used: Next.js, React, TypeScript, Zustand, React Flow, Monaco Editor, Tailwind CSS, Framer Motion, and Web Workers. Repository: https://github.com/riki-k-dev/nodex Live: https://nodex-jv.vercel.app Built for the Verified Frontend Internship · Final project

Shipped: Three decisions, written down

I created a decision record for Nodex documenting the major architectural decisions, alternatives considered, reasoning, and trade-offs. The DECISIONS.md covers the local-first architecture, Web Worker processing, React Flow + Dagre, Zustand state management, IndexedDB persistence, URL-based sharing, and primitive-only graph editing. The reviewer can open DECISIONS.md in the repository to verify the decisions and their associated costs/trade-offs. The existing README already covers the project architecture, setup instructions, testing, scope, and deliberately unimplemented features. Repository: https://github.com/riki-k-dev/nodex Live: https://nodex-jv.vercel.app Built for the Verified Frontend Internship · Documentation

Shipped: Short link service

What I built: A Flask + SQLite URL shortener with three endpoints: POST /links (create), GET /<code (redirect + count visit), GET /links/<code /stats (check URL + click count). All input is validated before it touches the database — bad requests get 400 with the exact field and rule that failed, never a 500. Short codes are a hash of the URL, so the same URL always maps to the same code, making creation idempotent. How a reviewer can verify it: Create/follow/count — POST /links → 200 + code; GET /<code → 302 redirect; stats endpoint shows clicks going up each follow. 301 vs 302 — README explains why 302 was chosen (not cached, so clicks are counted reliably). Unknown code → 404 — confirmed by hitting a code that was never created. Malformed URL → 400, nothing stored — confirmed by posting an invalid URL and checking its stats never resolve. Duplicate URL → same code — confirmed by posting the same URL twice and comparing the two responses. All verifiable with the curl/PowerShell commands in the README. Repository link: https://github.com/hassannnn13/Shortlink-service.git Repository: https://github.com/hassannnn13/Shortlink-service.git Built for the Verified Backend Internship · an API that survives bad input

Shipped: Library loans

What I built A Flask + SQLite API for a small library: books, copies, members, loans. GET /api/<member id /loans lists a member's current loans (newest first). POST /api/loans lends a copy. How to verify each criterion 3+ related tables with FKs: app/models.py — copies - books, loans - copies, loans - members. 10,000+ seeded rows: run python seed.py. Seeds 10,500 loans, 1,200 copies, 600 members, 300 books. Under 200 ms: run python run.py, call GET /api/261/loans. Measured 7-26 ms warm (see README). Query plan before/after index: seed.py prints EXPLAIN QUERY PLAN before and after creating ix loans member open; both are in README.md. Double lending blocked by a constraint: partial unique index uq one open loan per copy on loans(copy id) WHERE returned date IS NULL. POST /api/loans returns 409 on violation. Tested: same free copy id posted twice → 201, then 409. Repository link: https://github.com/hassannnn13/Library-loans.git Repository: https://github.com/hassannnn13/Library-loans.git Built for the Verified Backend Internship · a data model and the queries on it

Shipped: Library loans

Repository: https://github.com/sarvarbekbro/library-management-api Built for the Verified Backend Internship · a data model and the queries on it

Shipped: Bookmark service

I built a bookmark API with create, list, fetch-by-id and delete, each returning a documented status code. The live demo page has a "Run all checks" button that runs every acceptance criterion against the deployed server and shows each request with its expected and actual result. Node, Express 5 and SQLite Repository: https://github.com/Kam-ino/DevConnect-Internship/tree/main/BookmarkService Live: https://devconnect-internship-bookmark-service.onrender.com Built for the Verified Backend Internship · an API that survives bad input

Shipped: A rebuild of one feature you use

DropLink is a rebuild of Windows Nearby Sharing's "send to a nearby device" feature, running in the browser. Two laptops on the same WiFi pair with a 6 digit code, then send files or a zipped code folder directly to each other over WebRTC. The server only relays the handshake and never sees the files. Repository: https://github.com/rocklegend14/droplink Live: https://droplink-rl1f.onrender.com/ Built for the Verified Frontend Internship · Final project

Shipped: Ticket sales

A ticket sales API. There are three related tables: events, seats and orders. seats.event id references events, and orders.seat id references seats, with foreign keys enforced on every connection. The seed creates 12,000 seats across 5 events plus 1,714 pre-sold orders, for 13,719 rows in total. Node, Express 5 and SQLite Repository: https://github.com/Kam-ino/DevConnect-Internship/tree/main/TicketSales Live: https://devconnect-internship-ticket-sales.onrender.com Built for the Verified Backend Internship · a data model and the queries on it

Shipped: A README for a stranger

DropLink Send files and code folders between two laptops on the same Wi-Fi, directly from the browser. No account, install, cloud upload, or manual zipping. Demo: https://droplink-rl1f.onrender.com/ Run locally Prerequisites Node.js 18+ (developed on Node 22) npm Two devices on the same local network for transfers Open http://localhost:3000 . To use a second laptop, open: Both devices must be on the same Wi-Fi/network. The host computer's firewall must allow Node.js on private networks. Environment variables | Variable | Required | Purpose | | ------------- | -------- | -------------------------------------------------------- | | PORT | No | Changes the server port. Set this to any available port. | | CODE TTL MS | No | Changes pairing-code expiry, mainly useful for testing. | No API keys or other secrets are required. How to use 1. On laptop A, click Get pairing code . 2. On laptop B, enter the 6-digit code and click Connect . 3. On A, select files or a folder and click Send . 4. On B, click Accept , then use the Save links. Codes expire after 5 minutes and can only be used once. Files and folders Transfers support up to 50 items / 500 MB per batch . Folders are zipped in the browser before sending. By default, these are skipped: .env files are also skipped by default because they may contain secrets. Include .env files can be enabled when needed. .env.example files are always included. DropLink does not read .gitignore . How it works The server is used only for pairing and WebRTC signaling. After pairing, browsers establish a direct WebRTC data channel and send files directly between the two devices. No STUN or TURN servers are configured, so files stay on the local network. Tests The WebRTC transfer flow is also tested manually. Deployment DropLink requires Node.js and WebSockets, so static hosting such as GitHub Pages will not work. Render: use the included render.yaml Blueprint. Railway: create a service from the repository; it should detect npm start and provide PORT . Known limitations Both devices must be on the same local network. Guest/public Wi-Fi may block device-to-device connections. Deployed pairing requires internet access; file contents do not pass through the server. Transfers are limited to 500 MB / 50 items. Interrupted transfers cannot resume. The folder skip list is fixed and does not follow .gitignore . Internet transfers, Bluetooth discovery, transfer history, backup/sync, and whole-drive/app copying are not supported. Received files are held in browser memory until saved. Design decisions Why a pairing code? Browsers cannot freely perform nearby-device or Bluetooth discovery, so DropLink uses a 6-digit code instead. Why no STUN/TURN? They could enable more network configurations, but TURN would relay file data through a server. DropLink intentionally keeps transfers local. Why ZIP folders? Direct folder writing is not consistently available across browsers, so folders are sent as ZIP files instead. License MIT. Bundled fflate is MIT-licensed.

Shipped: Ticket sales

Repository: https://github.com/garima-2006/ticket-sales-api Built for the Verified Backend Internship · a data model and the queries on it

Shipped: Recipe with adjustable servings

Built a responsive recipe app using HTML, CSS, and JavaScript, with an accessible layout and adjustable servings. Ingredient quantities update automatically based on the selected number of servings, with a clean and user-friendly interface. Repository: https://github.com/e-dedaj/recipee Live: https://e-dedaj.github.io/recipee/ Built for the Verified Frontend Internship · accessible layout

Shipped: A README a reviewer can follow

Rewrote the README for the habit-tracker final project so a stranger can clone, run, and call one endpoint using only the README — verified with the exact quickstart commands (clone, node server.js, one curl call to /signup, expecting a 201 with id/email/token). Every environment variable (PASSWORD PEPPER, PORT, DB PATH, NODE ENV) is listed with whether it's required, its default if unset, and where it's used — none are required to start, which is documented explicitly. Every endpoint (/signup, /login, /habits, /habits/:id/checkins) has a full status-code table covering all failure cases (400s with field names, 401, 404, 409), not just the success path. Prerequisites name Node.js v22.x specifically (required for node:sqlite), not "a recent runtime." A dedicated "Known limitations" section lists what the service doesn't do: no pagination, no token expiry/revocation, no rate limiting, open CORS, single-file SQLite, Render free-tier cold starts, no migrations. Repository: https://github.com/mohammedoomatia-max/habit-tracker Built for the Verified Backend Internship · Documentation

Shipped: SpendingWrapped - my final project entry

I built a tracker that turns a year of spending, uploaded as a CSV, into a review like Spotify Wrapped: total spent, biggest month, most-visited merchant and a category breakdown. The upload returns 202 in milliseconds, and a separate worker process does the import in the background, saving its progress every 50 rows. Because the database refuses duplicate rows, running an import twice or retrying after a crash gives the same result, and a fingerprint of the summary proves it. Repository: https://github.com/Kam-ino/DevConnect-Internship/tree/main/SpendingWrapped Live: https://devconnect-internship-final-project.onrender.com Built for the Verified Backend Internship · Final project

Shipped: Bookmark service

Repository: https://github.com/VasiliSolap/bookmark-service Built for the Verified Backend Internship · an API that survives bad input

Shipped: Comparison table for three plans

I built a responsive, fully accessible, and keyboard-navigable Plan Comparison Component using Next.js (App Router), TypeScript, and Tailwind CSS. The application features a 3-plan comparison table (Basic, Pro, Enterprise) complete with a "Highlight differences only" toggle to help users quickly spot feature variations, and a custom narrow-screen mobile layout that replaces horizontal scrolling with an intuitive tabbed card view down to 320px. -3-Plan Comparison & Highlight Differences Toggle -Mobile Responsiveness (320px Support & No Horizontal Scrolling) -Accessibility (a11y) & Keyboard Navigation -Documentation Repository: https://github.com/onaolapomay/plan-comparison Live: https://plancomp.netlify.app/ Built for the Verified Frontend Internship · accessible layout

Shipped: Personal reading list

What you built: A Personal Reading List web application using Next.js App Router, TypeScript, and Tailwind CSS. It supports adding and removing books, local storage persistence, and a built-in Reviewer Testing Control Panel. Empty state requirement: When the list has no items, the UI shows a dedicated screen explaining what the list is for and provides a direct button to add the first book. Loading, error, and empty states: All three states are visually and textually distinct. Reviewers can trigger them directly using the control panel without changing any code. Error message requirement: The error state displays a clear explanation of what failed along with a "Try Again" recovery option. README documentation: The repository includes a README.md file documenting the project setup and how reviewers can test each required state. Repository: https://github.com/onaolapomay/ReadingLIST.git Built for the Verified Frontend Internship · state and data

Shipped: Personal reading list

A book reading list app built with React and Vite, where you can search books through the Open Library API and save them to a persistent list. It includes clearly distinct loading, error and empty states, plus demo buttons that let anyone preview each state without touching the code. Repository: https://github.com/e-dedaj/reading-list Live: https://booklover-bookshelf.vercel.app/reading-list Built for the Verified Frontend Internship · state and data