internship
Accepted into the ambassador program?
Hey, if you got accepted into our ambassador verified internship program, you can see in the picture where you find more details and what you need to do. If you have any questions, please let me know. The other internship programs will open in the next 2 weeks, so please stay patient while we deliver the best possible quality.
The Verified Frontend Internship is officially open
It’s free, fully remote, and you’re assessed based on the work you actually produce. The program includes: • 18 lessons covering HTML, CSS, JavaScript, TypeScript, React, accessibility & deployment • A 30-question assessment • Two practical frontend tasks • A final project that you deploy and document • A community contribution and written record of your work There are 7 mandatory milestones, with a minimum runtime of 3 days, so this is about actually learning and building, not rushing through a checklist. Once completed, you’ll receive a certificate with a public verification page that employers can check without an account. You can find all requirements and milestones here: https://devconnectplatform.com/program Backend, Mobile, MCP & Agent Tooling, and Programming in the Time of AI are coming next. You can already pre-register for them :)
Need for a project partner
I am looking out for any project partner to assist or contribute with me in a react native app development projects
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
Clarifying language/framework requirements for backend internship assignments
Does this backend internship require a particular language/framework to complete the assignments?
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
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
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: 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
Shipped: Conference schedule
Single-page schedule for a two-day conference with three parallel tracks. On narrow screens the tracks stack into one column inside each time slot, with the track name on every card (reasoning in the README). Sessions open in a native dialog that closes with Esc or the × button, and focus returns to the session you opened. To check the criteria: Tab through the page, then resize to 320px, since there's no horizontal scroll. The README has a checklist. Repository: https://github.com/mohammedoomatia-max/conference-schedule Live: https://mohammedoomatia-max.github.io/conference-schedule/ Built for the Verified Frontend Internship · accessible layout
Shipped: Public repository search
Searches public GitHub repos via the real API. Open 'Reviewer: trigger each state' under the search box to see loading, error and empty without code changes. The README explains each state and the error messages. Repository: https://github.com/mohammedoomatia-max/repo-search Live: https://mohammedoomatia-max.github.io/repo-search/ Built for the Verified Frontend Internship · state and data
Shipped: A view onto a public dataset
Quake Explorer lets you filter recent USGS earthquakes by strength and place and see the busiest regions. Slow and failing sources are handled, and you can test both from the 'Reviewer' dropdown. The README explains how to run it locally and what the data does and doesn't support Repository: https://github.com/mohammedoomatia-max/Quake-Explorer Live: https://github.com/mohammedoomatia-max/Quake-Explorer Built for the Verified Frontend Internship · Final project
Shipped: A rebuild of one feature you use
React Date Picker rebuilt with Vite, TypeScript, and Tailwind CSS v4. Fully responsive calendar grid, dropdown toggle withclick-outside handling, keyboard navigation (arrow keys, Enter, Escape), clear/reset selection state, and a comprehensive README detailing setup, architecture, omissions, and improvrments. Live deployment and all reviewer criteria met Repository: https://github.com/onaolapomay/date-picker-rebuild Live: https://datepickerrebuild.netlify.app/ Built for the Verified Frontend Internship · Final project
Shipped: A README for a stranger
A documentation criteria fully satisfied. A comprehensive README.md is merged into the repository containing exact tech stack versions, a 20-minute local setup guide with concrete prerequisite versions, client-side configuration notes, architecture decisions, focus-management mechanics, explicit feature comparisons (omissions and improvements), and known limitations/boundary conditions. Repository: https://github.com/onaolapomay/date-picker-rebuild Live: https://datepickerrebuild.netlify.app/ Built for the Verified Frontend Internship · Documentation
Shipped: Short link service
I built a Short Link Service (URL Shortener API) using Python (Flask) that converts long URLs into short codes, performs redirects, tracks click metrics, and robustly handles invalid input. Here is how a reviewer can verify that all acceptance criteria are met: Repository: https://github.com/yanayem/Task-an-API-that-survives-bad-input Built for the Verified Backend Internship · an API that survives bad input
Shipped: A service somebody else could run
Repository: https://github.com/yanayem/task-3 Built for the Verified Backend Internship · Final project
Shipped: Bookmark service
Bookmark Service An HTTP service for saving bookmarks. A caller can create a bookmark, list their own, fetch one by id, and delete one. The interesting part is not the happy path. It is what happens when a caller sends an empty URL, a number where a URL belongs, no URL at all, or a URL that is two kilobytes long — and what happens when the same bookmark is sent twice. Repository: https://github.com/R0wanAdel/Bookmark-service Built for the Verified Backend Internship · an API that survives bad input
Shipped: Short link service
Built a Flask-based short-link HTTP service that creates short codes for valid HTTP/HTTPS URLs, redirects users with a deliberate 302 response, and tracks redirect counts. The service provides endpoints for creating links, following links, and viewing statistics. Invalid URLs return 400 with an error identifying the url field, unknown codes return 404, and submitting the same URL twice returns the existing short code instead of creating a duplicate. The README documents the API, validation behavior, duplicate handling, and the reasoning behind using 302 redirects. Automated tests cover creation, redirects, counting, malformed input, unknown codes, and duplicate submissions, with all 7 tests passing. The deployed API is available at the live demo URL above. Repository: https://github.com/kiths-bit/short-link-service Live: https://short-link-service-6vef.onrender.com/ Built for the Verified Backend Internship · an API that survives bad input
Shipped: Conference schedule
I built Wrenfield Frontend Day, a one-page React + Vite site for a fictional accessibility conference, designed as a printed programme: a live countdown or "On now" stamp, the day at a glance, a full two-room schedule as a real data table, venue and access details, and a registration form that turns into an attendee badge. Accessibility was built in from the start, with landmarks and a skip link, correct heading order, a schedule table that keeps its row and column headers even on phones, full keyboard support, an error summary, visible focus, WCAG AA contrast in light and dark mode, and reduced-motion support. Repository: https://github.com/Kam-ino/DevConnect-Internship/tree/main/AccessibleLayout Live: https://devconnect-internship-accessible-layout.onrender.com Built for the Verified Frontend Internship · accessible layout
Shipped: Recipe with adjustable servings
A responsive Recipe with Adjustable Servings app using React, TypeScript, and Tailwind CSS. Users can adjust servings, and ingredient quantities update automatically. How the reviewer can verify the criteria Keyboard: Use Tab to navigate and Enter/Space to operate the buttons. Focus: Every button has a visible :focus-visible indicator. Responsive: Test at 320px; no horizontal scrolling should occur. Accessibility: Serving changes are announced to screen readers using aria-live. Narrow screen: Ingredients and Method stack vertically on small screens. README: Explains keyboard operation and narrow-screen handling. Repository: Review the code and run the project from GitHub. Deployment: Netlify Live Repository: https://github.com/humaeidmansur/accessible-recipe.git Live: https://humaeid-internship-reciepe-project.netlify.app/ Built for the Verified Frontend Internship · accessible layout
Shipped: Currency converter with live rates
I built Specimen, a currency converter in React, TypeScript and Vite. It fetches live European Central Bank exchange rates from the public Frankfurter API, shows the result styled like a banknote, and charts the pair's rate history over 1 month, 3 months or 1 year. Repository: https://github.com/Kam-ino/DevConnect-Internship/tree/main/State%20and%20Data Live: https://devconnect-internship-state-and-data.onrender.com Built for the Verified Frontend Internship · state and data
Shipped: A rebuild of one feature you use
I built Stillroom, a full-stack web app that breaks a video into its exact frames. It uses React + TypeScript, an Express + ffmpeg API, and Supabase for the database, storage and email/password sign-in, with no AI anywhere. You upload a clip and get a numbered contact sheet and a 3D plate rack. You can step to any exact frame, keep frames, and download them as full-resolution PNG or WebP, a ZIP of kept frames, or a numbered image sequence with a manifest for frame-by-frame web animation. Repository: https://github.com/Kam-ino/DevConnect-Internship/tree/main/Stillroom Live: https://stillroom-qm1m.onrender.com Built for the Verified Frontend Internship · Final project
Shipped: A README for a stranger
Repository: https://github.com/Kam-ino/DevConnect-Internship/tree/main/Stillroom Built for the Verified Frontend Internship · Documentation
Shipped: Ticket sales
Repository: https://github.com/R0wanAdel/Ticket-Sales Built for the Verified Backend Internship · a data model and the queries on it
Shipped: API Response Debugger — a local-first dev tool
What did you build? - A lightweight browser-based API debugging tool for frontend development. It lets users configure HTTP methods, URLs, headers, query parameters, and request bodies, then send requests and inspect status, timing, response size, and formatted responses. - Built incrementally across 8 scoped PRs, with features including error states, query parameters, JSON highlighting, request history, retry, response size, in-response search, and saved favorites. - No backend, build step, or dependencies — plain HTML/CSS/JS. How can a reviewer verify the acceptance criteria? - Repository: GitHub commit/PR history shows each feature and its implementation. - README: Documents architecture, setup, features, and intentionally excluded scope. - Error states: Invalid URLs, network/CORS failures, timeouts, invalid/empty responses, and 4xx/5xx responses are handled visibly. - Live demo: https://sindhu-dev02.github.io/api-debugger/ - DECISIONS.md: Documents key technical decisions, alternatives, trade-offs, and a real bug discovered during development. Repository: https://github.com/sindhu-dev02/api-debugger Live: https://sindhu-dev02.github.io/api-debugger/ Built for the Verified Frontend Internship · Final project
Shipped: API Response Debugger — a local-first dev tool
What did you build? - A lightweight browser-based API debugging tool for frontend development. It lets users configure HTTP methods, URLs, headers, query parameters, and request bodies, then send requests and inspect status, timing, response size, and formatted responses. - Built incrementally across 8 scoped PRs, with features including error states, query parameters, JSON highlighting, request history, retry, response size, in-response search, and saved favorites. - No backend, build step, or dependencies — plain HTML/CSS/JS. How can a reviewer verify the acceptance criteria? - Repository: GitHub commit/PR history shows each feature and its implementation. - README: Documents architecture, setup, features, and intentionally excluded scope. - Error states: Invalid URLs, network/CORS failures, timeouts, invalid/empty responses, and 4xx/5xx responses are handled visibly. - Live demo: https://sindhu-dev02.github.io/api-debugger/ - DECISIONS.md: Documents key technical decisions, alternatives, trade-offs, and a real bug discovered during development. Repository: https://github.com/sindhu-dev02/api-debugger Live: https://sindhu-dev02.github.io/api-debugger/ Built for the Verified Frontend Internship · Documentation
Shipped: A view onto a public dataset
Climate Days is a web app that shows how many days per year exceed a chosen temperature in any city, using historical data from the Open-Meteo API. It includes an adjustable threshold, a linear trend line, and clear notes on what the data can and cannot tell you. Repository: https://github.com/e-dedaj/climate-days Live: https://climate-days.vercel.app/ Built for the Verified Frontend Internship · Final project
Shipped: Short link service
I built a short link service with FastAPI and PostgreSQL (SQLAlchemy + Alembic). POST /links takes a URL and returns a 6-character code. GET /links/{code} redirects to the original URL and counts the follow, and GET /links/{code}/stats shows the count without counting it. How to check the criteria (full setup steps are in the README): - Bad input: a malformed URL, an empty body, or a wrong type returns 400 with the field name and location, and nothing is stored. - Unknown code: returns 404 on both the redirect and stats endpoints. - Same URL twice: returns the same code. A unique constraint on the URL backs this up in the database. - Redirect and counting: follows return 302 (not 301, so browsers don't cache it and skip the counter). Each follow adds exactly 1 using one atomic UPDATE. - Code collisions: handled by retrying when the database rejects a duplicate code. - Tests: run "pytest -v" for 12 passing tests against a separate test database. They cover each point above. The work is split across several PRs: validation, create link, redirect and click counting, database, tests, and README. Known limits: no authentication or rate limiting, and the GET /links list endpoint is only a placeholder. Repository: https://github.com/Ramsha-Anwar/short-link-service Built for the Verified Backend Internship · an API that survives bad input
Shipped: Personal reading list
What I built: A personal reading list app. You can add books (title + author) and remove them. It's backed by a real backend — Node.js with Express, and the data is saved in a SQLite database file, so it doesn't disappear on refresh. The app shows four different states depending on what's happening: loading, error, empty, and the actual list. Each one looks and reads differently, so it's always clear which one you're looking at. How to check the loading, error, and empty states There's a small panel at the bottom of the page called "Reviewer tools." It has buttons to jump straight to each state, no code or dev tools needed: - Show loading state — shows the loading screen - Show error state — triggers a real failed request and shows the error screen, with a message saying what went wrong and a button to retry - Show empty state — shows the empty screen, which explains what the list is for and has a button to add your first book - Back to my list — goes back to your real saved books You can also see these naturally: open the app fresh (or clear the data) to see the real empty state, remove all books to get back to it, or stop the server to see a real error. All of this is also written out in the README in the repo. Repository: https://github.com/sindhu-dev02/reading-list Live: https://reading-list-jeah.onrender.com Built for the Verified Frontend Internship · state and data
Shipped: Ticket sales
Repository: https://github.com/kiths-bit/ticket-sales-api Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Comparison table for three plans
I built a responsive and accessible pricing comparison page for three plans (Basic, Pro, and Premium) with 15 features. It includes a “Show differences only” checkbox that hides identical features while keeping the comparison understandable. The page uses semantic HTML table structure with proper row and column headers for assistive technology. The control is keyboard accessible, with visible focus indicators and a logical tab order. On narrow screens, including 320px, the table changes to a stacked card-style layout so there is no horizontal scrolling. The README explains the responsive approach and accessibility decisions. To review the acceptance criteria, open the deployed/local page, use Tab and Space to operate the comparison control, test the page at 320px width, and inspect the table structure with accessibility/browser developer tools. Repository: https://github.com/Raunakshukla90/DevConnect Built for the Verified Frontend Internship · accessible layout
Shipped: A tool for a problem you have
I built a responsive Personal Reading List web application using React, JavaScript, CSS, and Vite. Users can add articles/resources with a title and URL, view saved items, open saved URLs, and remove items. The reading list uses browser localStorage for persistent data, so saved items remain after refreshing the page. The app also includes separate loading, error, and empty states. How can a reviewer see that the acceptance criteria are met? Loading state: Open /?state=loading to view the loading state. Error state: Open /?state=error to view the error message and Try Again action. Empty state: Open /?state=empty to see the explanation of the reading list and Add your first article action. Normal/data state: Open /, add an article with a title and URL, and verify that it appears in the reading list. Persistent data: Refresh the page after adding an article and verify that it remains saved. Remove items: Click Remove on a saved article to verify that it is removed. Responsive design: Test the application on both mobile and desktop screen sizes. Accessibility: Use keyboard Tab navigation to test the form and buttons. Visible focus states are provided. Documentation: The README contains instructions for testing all required states without making code changes. Repository: https://github.com/Raunakshukla90/DevConnect FinalProject Built for the Verified Frontend Internship · Final project
Shipped: Personal reading list
I built a responsive Personal Reading List web application using React, JavaScript, CSS, and Vite. Users can add articles/resources with a title and URL, view saved items, open saved URLs, and remove items. The reading list uses browser localStorage for persistent data, so saved items remain after refreshing the page. The app also includes separate loading, error, and empty states. How can a reviewer see that the acceptance criteria are met? Loading state: Open /?state=loading to view the loading state. Error state: Open /?state=error to view the error message and Try Again action. Empty state: Open /?state=empty to see the explanation of the reading list and Add your first article action. Normal/data state: Open /, add an article with a title and URL, and verify that it appears in the reading list. Persistent data: Refresh the page after adding an article and verify that it remains saved. Remove items: Click Remove on a saved article to verify that it is removed. Responsive design: Test the application on both mobile and desktop screen sizes. Accessibility: Use keyboard Tab navigation to test the form and buttons. Visible focus states are provided. Documentation: The README contains instructions for testing all required states without making code changes. Repository: https://github.com/Raunakshukla90/DevConnect FinalProject Repository: https://github.com/Raunakshukla90/DevConnect FinalProject Live: https://frontendsaveitreadit.netlify.app/ Built for the Verified Frontend Internship · state and data
Shipped: Comparison table for three plans
1. What was built Wheelhouse Clay Studio — Membership Comparison Page (built for Brief C: "Comparison table for three plans"). Overview: A responsive, accessible membership comparison interface comparing three studio tiers (Drop-in, Regular, and Resident) across 15 distinct features. Tech Stack: Pure semantic HTML5, modern CSS, and vanilla JavaScript (zero dependencies, no build step, light/dark mode support, Atkinson Hyperlegible typeface). Key Features: Plan Cards: Top-level overview cards displaying monthly pricing and selection action buttons. Comprehensive Comparison Table: A complete feature matrix categorized across studio access, clay allowances, firing, and storage. "Highlight Differences" Control: An accessible toggle button that dynamically identifies and highlights rows that differ between plans while keeping identical rows understandable and legible. Per-Feature Mobile Reflow: On screens below 640px (down to 320px), rows reflow so all three plan values for a given feature sit side-by-side with localized plan labels, eliminating the need to scroll horizontally or memorize values between stacked cards. 2. How a reviewer can see that acceptance criteria are met A reviewer can run and test the application directly by opening index.html in any browser (or serving with npx serve .). Here is how each acceptance criterion can be verified step-by-step: A. Operable end-to-end via keyboard in visual order How to verify: Press Tab starting from the top of the page. First Tab reveals the Skip Link ("Skip to the comparison"). Pressing Enter jumps directly to compare-heading. Continue tabbing: the focus moves naturally to the three plan selection buttons ("Choose Drop-in", "Choose Regular", "Choose Resident"), followed by the "Highlight differences" toggle. Activate any button or toggle using Enter or Space. Verification: DOM order strictly matches visual order with no artificial tabindex 0 or CSS order disruptions. B. Clear visible focus indicators How to verify: Tab through interactive elements in both Light and Dark mode (or using system dark mode preference). Verification: Every interactive element shows an unmistakable 3px cobalt outline with an offset (:focus-visible), exceeding WCAG 3:1 contrast against both backgrounds. C. Fully responsive with no horizontal scrolling at 320px How to verify: Open DevTools (F12), toggle Device Toolbar, and set viewport width to 320px (as well as 375px and 1280px). Run in the console: javascript document.documentElement.scrollWidth === document.documentElement.clientWidth Verification: Evaluates to true (no horizontal scrollbar). Long strings wrap cleanly, and each feature cleanly displays the feature title above the three plan values side-by-side with small localized labels (Drop-in, Regular, Resident). D. Semantic table structure conveyed to Assistive Technology How to verify: Inspect the table elements in browser DevTools (Accessibility tree): Uses native <table , <caption , <thead scope="col" , and <th scope="row" headers. Carries explicit ARIA roles (role="table", role="row", role="columnheader", role="rowheader", role="cell") to ensure screen readers (such as VoiceOver/Safari or NVDA) do not drop table semantics when CSS display: block / grid is applied on mobile widths. Mobile labels inside cells use aria-hidden="true" to prevent screen readers from repeating column headers twice. E. "Highlight differences" functionality & accessibility How to verify: Click or press Space/Enter on the "Highlight differences" button. Visual cue: Rows with differences receive a tinted background, a solid cobalt border on the left, and a "Differs" tag. Rows with identical values show a "Same on every plan" badge. Color-independence: Highlighting does not rely on color alone; text remains above 4.5:1 contrast, and tags remain clear in Windows High Contrast / Forced Colors mode. Screen Reader announcements: The toggle has aria-pressed="true|false". An aria-live="polite" status region announces the outcome (e.g., "10 of 15 features differ between plans."). Because tags are inside <th scope="row" , assistive technology reads the feature name alongside its comparison state (e.g., "Clay included, Differs"). Repository: https://github.com/aleewains/plan-comparison Live: https://plan-comparison-jet.vercel.app/ Built for the Verified Frontend Internship · accessible layout
Shipped: Personal reading list
What I built: A Personal Reading List app (React + TypeScript + Vite) backed by persistent localStorage that supports adding, removing, and tracking books across reading statuses (Want to Read, Currently Reading, Completed). How a reviewer can verify the acceptance criteria: Distinct States: Loading: Shows skeleton cards and explicitly states data is unmeasured pending retrieval (not zero). Error: Explains what failed, provides a working "Try Again" retry button, and states when retrying will not help (e.g., server maintenance). Empty: Explains what the reading list is for and offers the first action ("+ Add Your First Book"). Demonstrable without code changes: URL Parameters: Append ?state=loading, ?state=error, or ?state=empty directly in the browser address bar. Reviewer Toolbar: Use the top in-app switcher buttons to toggle any state or adjust latency instantly. Automated Tests: Run npm test to see 9/9 automated tests verifying all states and URL parameters. Repository: https://github.com/aleewains/personal-reading-list Live: https://personal-reading-list-ruddy.vercel.app/ Built for the Verified Frontend Internship · state and data
Shipped: A tool for a problem you have
What Was Built CommandVault — A keyboard-first developer command cheatsheet and snippet vault (React 19 + TypeScript + Vite) featuring: Dual Workspaces: Zed / Helix Terminal TUI (dense monospaced aesthetic, status line, instant prompt). Linear Precision 3-Pane (categories sidebar → command stream → inspector pane). Craft Light & Dark Themes: High-contrast light theme with dedicated tag badges, legible macOS-style scrollbars, and instant switching. Global Portal Tooltips & Inline Popovers: Root-level floating tooltips (position: fixed, z-index 999,999) immune to overflow clipping, plus non-intrusive inline delete confirmation bubbles. 100% Viewport-Fit Architecture: Full outer frame fits within the visible screen (100dvh) without page scrolling, while snippet streams and inspector panes scroll independently with custom slim scrollbars. How a Reviewer Can Verify Acceptance Criteria Verify Viewport Lock & Inner Scrolling: Open the app: the entire outer window fits on screen without any vertical browser/body scrollbar. Scroll the snippet list or inspector pane: verify each pane scrolls smoothly on its own slim rounded scrollbar. Check the bottom edge: confirm the drop shadow diffuses softly without being clipped. Verify Dual Workspaces & Switcher: Press ⌘ + M (or Ctrl + M) or click the masthead mode buttons to toggle between Zed TUI and Linear 3-Pane. Refresh the page to verify your selected workspace persists in localStorage. Verify Light Theme & Visible Scrollbars/Tags: Press ⌘ + T (or Ctrl + T) or click the Sun/Moon icon in the header. Verify the scrollbar thumb is clearly visible with dark translucent contrast against light backgrounds. Check category tags (Docker, Git, Bash, SQL, etc.): verify they render with clean light pastel tints and legible text instead of dark charcoal boxes. Verify Tooltip & Delete Popover: Hover over the Copy button on any snippet: verify the tooltip appears cleanly below the button with its arrow pointing directly to the button center, without clipping behind any headers. Click the Trash icon on a snippet: verify the inline "Delete snippet?" confirmation bubble pops up anchored to the button (with Cancel and Delete actions). Verify Favorite Filtering in Zed TUI: In Zed TUI, click [★ FAVS] in the filter bar or press ⌘ + P on a command: verify the list instantly filters down to pinned favorites. Repository: https://github.com/aleewains/dev-snippets Live: https://commandvault-tau.vercel.app/ Built for the Verified Frontend Internship · Final project
Shipped: A guide for the next contributor
What I Built CommandVault — A keyboard-first developer snippet and command cheat sheet (React 19 + TypeScript + Vite) with: Dual Workspaces: Zed/Helix Terminal TUI and Linear 3-Pane (toggleable via ⌘M). Craft Light & Dark Themes: High-contrast light mode with visible macOS-style scrollbars and pastel tags (toggleable via ⌘T). Live Placeholder Substitution: Real-time argument editing for commands containing variables like <container or <port . Zero-Clipping Global Tooltips & Popovers: Portal-rendered tooltips and micro inline delete confirmation bubbles. 100% Viewport-Fit UI: The outer frame stays locked to the visible screen (100dvh) without page scrolling, while lists and inspector panes scroll independently. How a Reviewer Can Verify Acceptance Criteria Outer Viewport & Inner Scrollbars: Open the app—the outer window fits on screen with zero whole-page scroll. Scroll the snippet list or inspector to verify smooth inner scrollbars and an unclipped bottom shadow. Dual Workspaces: Press ⌘M (or click header tabs) to switch between Zed TUI and Linear 3-Pane. Refresh the page to verify it persists. Light Theme: Press ⌘T (or click Sun/Moon icon) to verify high-contrast light surfaces, visible dark scrollbars, and colored category tags. Tooltips & Delete Popover: Hover over the Copy button to verify the tooltip floats cleanly below with its arrow centered. Click the Trash icon to verify the inline "Delete snippet?" bubble pops up. Favorites Filter in Zed TUI: Press ⌘P on a snippet to star it, then click [★ FAVS] in the category bar to filter pinned commands. Code & Build Checks: Run npm run build in terminal to confirm a passing build with 0 TypeScript errors. Check CONTRIBUTING.md and README.md for full architecture and usage guides. Repository: https://github.com/aleewains/dev-snippets Live: https://commandvault-tau.vercel.app/ Built for the Verified Frontend Internship · Documentation
Shipped: A README for a stranger
Repository: https://github.com/Raunakshukla90/DevConnect FinalProject Built for the Verified Frontend Internship · Documentation
Shipped: Three decisions, written down
Documentation for Climate Days: a README with run instructions, usage and data limits, plus a decision record covering three key decisions (data source, single large request, localStorage cache) with alternatives and costs. Repository: https://github.com/e-dedaj/climate-days Live: https://climate-days.vercel.app/ Built for the Verified Frontend Internship · Documentation
Shipped: A view onto a public dataset
Clinical Trial Finder is a web app built with React and Vite, where you can search registered clinical studies from the ClinicalTrials.gov API by condition, filter them by recruitment status, and click through to the original record. It handles loading, empty and error states, and requests time out after 10 seconds instead of hanging. The README covers how to run it locally, what the data can’t tell you, and what I left out. Repository: https://github.com/marthahere/clinical-trial-finder Live: https://marthahere.github.io/clinical-trial-finder/ Built for the Verified Frontend Internship · Final project
Shipped: Three decisions, written down
I documented Clinical Trial Finder with a README (how to run it, how to use it, what the data can’t tell you) and a DECISIONS.md that explains three choices: calling the API live from the browser, cleaning up each record before showing it, and letting the API handle search and filtering. Each one lists the alternatives I weighed and the costs. Repository: https://github.com/marthahere/clinical-trial-finder Live: https://marthahere.github.io/clinical-trial-finder/ Built for the Verified Frontend Internship · Documentation
Shipped: Short link service
Repository: https://github.com/saikatdas47/short-link-service Built for the Verified Backend Internship · an API that survives bad input
Shipped: Ticket sales
Repository: https://github.com/saikatdas47/ticket-sales Built for the Verified Backend Internship · a data model and the queries on it
Shipped: A service somebody else could run
Repository: https://github.com/saikatdas47/expense-tracker Live: https://expense-tracker-88pa.onrender.com/ Built for the Verified Backend Internship · Final project
Shipped: A README a reviewer can follow
Repository: https://github.com/saikatdas47/expense-tracker Built for the Verified Backend Internship · Documentation
Shipped: A service somebody else could run
An Event booking service with ASP.NET as backend and Postgres as db. Organizers publish events with a limited capacity, attendees register for them. Everything except public event reads requires a JWT. Missing or malformed tokens return 401. Registration is idempotent: a repeat returns the original registration and consumes no extra seat. Repository: https://github.com/Abadli-Badro/EventHub Live: https://eventhub-ly9o.onrender.com/ Built for the Verified Backend Internship · Final project
Shipped: Recipe with adjustable servings
I built a responsive recipe website featuring a Tomato and Basil Pasta recipe, an ingredient list with adjustable quantities, and step-by-step cooking instructions. The website includes plus and minus buttons to change the number of servings, and the ingredient quantities update automatically. I also implemented accessibility features such as keyboard navigation, visible focus indicators, a skip link, and screen-reader announcements when servings change. The layout is designed to adapt to smaller screens, including a 320px viewport, without horizontal scrolling. The project contains index.html for the structure and recipe content, styles.css for styling and responsiveness, script.js for serving calculations, and README.md explaining the design and testing process. A reviewer can verify the acceptance criteria by opening the website in a browser, changing the servings to confirm that ingredient quantities recalculate correctly, navigating the page using only the keyboard, and checking that the focused element has a visible outline. They can also set the browser viewport to 320px to check for horizontal scrolling, inspect the live status element for screen-reader support, and read the README to understand how the layout behaves on narrow screens. These features have been implemented, but browser and screen-reader testing still needs to be performed to confirm that every criterion passes. The project is available as a ZIP file, but it has not yet been published to GitHub, so a repository URL still needs to be created and verified before submission. Repository: https://github.com/AMAN-AJWA-FATIMA/DevConnect-Internship Live: http://0.0.0.0:8000/ Built for the Verified Frontend Internship · accessible layout
Shipped: Ticket sales
Built a Ticket Sales API — my internship project I just wrapped up a backend project that simulates real ticket reservation: events, seats, and the race-condition problem that shows up the moment two people try to buy the same seat at the same time. Stack: FastAPI · SQLAlchemy · PostgreSQL · Alembic · Docker · pytest What I built: Three related tables (events, seats, orders) with foreign keys and constraints enforced at the database level — not just in application code 12,000 seeded seats across 4 events for realistic performance benchmarking A free-seat listing endpoint, returning in under 200 ms A reservation endpoint that is safe under concurrency 16 automated tests covering endpoints, side effects, and concurrency at both the DB and HTTP layers The two problems that taught me the most: 1. Indexing is not about "adding an index" — it's about making the filter selective. The free-seat query filters on event id and status = 'free'. My first index only covered event id, so PostgreSQL still had to fetch every row and check status on the heap. Adding a composite index on (event id, status) moved both conditions into the index. Heap reads dropped from 23 blocks to 3, and the median query time went from 0.778 ms to 0.159 ms — a 4.9× improvement. But here's the honest part: the endpoint latency barely changed. The database was never the bottleneck — JSON serialization and HTTP overhead dominate the endpoint. Documenting that honestly was more valuable than pretending the index solved everything. 2. Concurrency is a database problem, not an application problem. The naive flow — SELECT → check status == 'free' → UPDATE — allows two requests to both read free before either one writes reserved. Both "win." I fixed it by combining the check and the write into one atomic SQL statement: sql UPDATE seats SET status = 'reserved' WHERE id = :seat id AND event id = :event id AND status = 'free'; PostgreSQL guarantees at most one concurrent transaction can match that WHERE clause. The loser sees rowcount = 0 and returns 409 Conflict. Proved it with two simultaneous HTTP requests. Exactly one 201, exactly one 409, exactly one order in the database. Reproduced on three different seats. I also hit a Windows socket abort under concurrent load — a real infrastructure issue, not a logic bug — and diagnosed it to the SQLAlchemy connection pool. Fixing that with pool pre ping=True was a lesson in production hardening. What I'd take away: The project brief asked for endpoints, an index, and a concurrency-safe reservation. What I actually learned was: How to measure before optimizing Why the database should enforce invariants, not the application How to write evidence, not claims — every number in the README comes from a real captured run The difference between "it works" and "here's proof it works under load" backend fastapi postgresql python concurrency Repository: https://github.com/Ramsha-Anwar/ticket-sales-api Built for the Verified Backend Internship · a data model and the queries on it
Shipped: Short link service
What I built: I built a short link service in Node.js. You send it a long URL and it gives back a short code. When someone opens the short code, it sends them to the original URL and counts that visit. It has three endpoints: - POST /links creates a short link. - GET /:code follows the short link. - GET /links/:code/stats shows how many times it was followed. How to check it: Start the server with npm start. In a second terminal, run npm run demo. The script runs every check below and prints the status code next to each one. You can also run npm test to see all 32 tests pass. 1. Creating, following and counting each work. The demo creates a link and gets 201. It follows the link twice, then checks the stats and sees a count of 2. 2. 301 or 302 is chosen on purpose. I used 302. Browsers remember a 301, so repeat visits would skip my server and never be counted. A 301 also can’t be undone once a browser has saved it. The reason is written in the README under “302, not 301”. 3. An unknown code returns 404. The demo opens a code that doesn’t exist and gets a 404 with an error message, not an empty 200. 4. A malformed URL is rejected with 400 before storage. The demo sends “not a url” and a javascript: link. Both get a 400 and the message names the field, for example {"error": "url must use http or https", "field": "url"}. The checks run before anything is saved, and a test confirms nothing was stored. Broken JSON also gets a 400, not a 500. 5. The same URL submitted twice does not create two codes. The demo sends the same URL twice. The first time gets 201 and the second gets 200 with the same code. A test also sends 20 identical requests at once and checks that only one link is stored. The README has the full list of endpoints, the error codes and the known limits.