5 Full-Stack Projects with Real Business Problems That Stand Out in Interviews

Every university graduate has a student management project, a weather app, and a clone of something that already exists. Recruiters have seen thousands of them. They scroll past without a second thought.

What makes a recruiter stop and pay attention is a project that shows you understand a real business problem, made real engineering decisions to solve it, and built something that could actually run in production.

That is a completely different bar. And it is achievable.

The projects below are not invented for the sake of complexity. Each one is rooted in a genuine operational pain point that businesses in distribution, legal, education, transportation, and hospitality face every single day. Industries where spreadsheets are still the system of record. Where WhatsApp is the integration layer. Where money is being lost not because the problem is unsolvable, but because nobody has built the right tool yet.

These are not tutorial projects. They will push you into territory that most junior developers never touch: distributed lock management, immutable financial ledgers, real-time multi-session sync, offline-first mobile architecture, cryptographically signed documents, and background job lifecycle management. You will need to understand the domain before you can design the system. That is intentional. Knowing why a garment factory measures efficiency in SAM, or why a payment record must never be edited, is what separates a developer who can follow instructions from one who can solve problems.

When you sit across from a recruiter at WSO2, Dialog, or any product company worth joining, they will not ask you to explain your todo app. They will ask you what hard problem you solved, what broke, and what you did about it. These five projects give you a real answer to that question.

Pick one. Go deep. Build it like it is going to production.

FMCG Distributor: Field Sales Order with Live Stock Lock

The Problem

A sales rep visits a shop, takes an order for 50 units of a product, and sends it via WhatsApp to the warehouse. By the time it reaches the warehouse, that stock was already committed to three other reps taking orders in the field at the same time. The warehouse oversells, deliveries fail, and shops lose trust in the distributor. This happens every single day across hundreds of FMCG distributors with no real-time stock visibility.

What You're Building

A mobile app for sales reps in the field to capture orders, and a web app for warehouse managers to see live stock levels, manage inventory, and process confirmed orders.

When a rep opens an order form for a shop, the available quantities they see are soft-locked in real time. If rep A is actively building an order for 30 units of SKU X, those 30 units are temporarily held and rep B sees reduced availability immediately. The lock expires automatically if the rep does not confirm within a set time window, releasing the stock back. When the rep confirms, the order is hard-allocated and no other rep can sell against that stock.

The warehouse manager sees a live three-way stock view at all times: physical stock, hard-allocated stock committed to confirmed orders, and soft-locked stock currently held by reps in active sessions. Delivery scheduling, order status updates, and daily sales reports are all managed from the web dashboard.

The system also works in low-connectivity field conditions. If a rep loses signal while building an order, the app queues the order locally and syncs when connectivity returns, with conflict resolution if the stock situation changed while they were offline.

Phase 1: Mobile app for sales reps. Web app for warehouse managers.

The Ideal Tech Stack

The Challenging Technical Problems

1. Soft Lock Architecture with Redis TTL: When a rep opens an order form, a soft lock entry is written to Redis with a TTL of say 10 minutes per SKU quantity being held. Redis TTL handles automatic expiry without any cron job. But the challenge is partial locks. A rep is ordering 5 different SKUs. Some locks expire, some do not. The system must reconcile the lock state across all SKUs in the order continuously and alert the rep if any held quantity has been released due to timeout. This is not a single lock. It is a per-SKU lock pool per active session.

2. Race Condition Between Soft Lock Expiry and Confirmation: The rep's 10-minute soft lock expires at exactly the moment they hit confirm. Another rep claimed that stock 50 milliseconds earlier. The first rep's confirmation must fail gracefully with a clear message about which SKUs are no longer available, and the order must be partially reconstructable with the remaining available stock. Handling this edge case cleanly requires atomic Redis operations combined with a PostgreSQL transaction, not just one or the other.

3. Offline Order Queue with Sync Conflict Resolution A rep in a rural area loses connectivity for 20 minutes while visiting three shops and capturing three orders. When connectivity returns, the app attempts to sync all three orders. By then, stock levels may have changed. Order one goes through. Order two has one SKU that is now out of stock. Order three is fully available. The system needs a conflict resolution strategy: auto-confirm what is available, flag what is not, and notify the rep of exceptions without silently dropping items. The offline queue must be ordered, idempotent, and resilient to partial sync failures.

4. Three-Way Stock View Consistency Physical stock minus hard allocations minus soft locks equals available stock. This calculation is live and must be consistent across the warehouse dashboard and all rep mobile sessions simultaneously. The problem is that soft locks live in Redis and hard allocations live in PostgreSQL. Joining across these two systems to produce a single consistent stock figure requires a carefully designed aggregation layer in the service level that cannot be a simple database query.

5. Barcode-Driven SKU Selection in the Field Sales reps should not be searching through a 200-item product list to build an order. They scan the barcode on a shelf or product sample and the SKU populates instantly. This requires integrating Expo's barcode scanner into the order flow, mapping scanned barcodes to internal SKU identifiers, and handling the case where a barcode is not in the system yet. In field conditions, the camera must initialise quickly and the scan-to-populate flow must feel instant.

How Your STEM Link Bootcamp Prepares You For This

Real-time communication with Socket.io is central to this product. Every stock movement, lock acquisition, and order confirmation must propagate instantly to all connected warehouse and rep sessions. The bootcamp's real-time patterns give students the foundation, but this project pushes it further by requiring targeted broadcasts based on SKU and warehouse context rather than simple room-based updates.

Offline-first architecture and sync patterns from the mobile track are tested to their limit here. The AsyncStorage caching, network status detection, and sync-on-reconnect patterns taught in the bootcamp are the exact toolkit for the field order queue. The bootcamp builds the skill, this project builds the judgment for handling sync conflicts properly.

Relational database engineering and transactional writes handle the hard allocation layer. The booking overlap check from NestBoard is conceptually identical to the stock over-commitment problem here. ACID transactions, SELECT FOR UPDATE, and service layer atomicity are all directly applicable.

Device integration from the mobile track covers barcode scanning through the camera API. The bootcamp teaches QR code scanning for property lookup in NestBoard. The same Expo camera integration extends naturally to barcode scanning for SKU selection in a field sales context.

Firebase auth and role-based access control enforce the boundary between what a field rep can do versus what a warehouse manager controls. Reps can create and view their own orders. Managers can adjust stock, process deliveries, and see the full picture. Same RBAC patterns, more operationally critical consequences if they are wrong.

Third-party API integration through the WhatsApp Business API sends order confirmation summaries to shop owners the moment an order is confirmed, giving the shop a record without the rep needing to manually communicate anything. The integration model is the same as taught through Stripe in the bootcamp.

Legal Document Assembly: Template Engine with Variable Contracts

The Problem

Every time a lawyer or legal team needs to draft a client agreement, NDA, or engagement letter, they open an old document, copy it, and manually replace names, dates, and clauses. Wrong details slip through. Outdated clauses get carried forward. There is no version history. One wrong copy-paste in a contract can create serious legal exposure, and it happens constantly in small and mid-size legal firms.

What You're Building

A web app where legal teams define reusable document templates with typed variable placeholders like client name, engagement date, fee amount, and governing law. Templates also support conditional clauses, where certain sections only appear based on the type of matter being created.

When a new client matter is opened, a lawyer fills a structured form. The system assembles the complete document instantly, correctly, using the template. Every generated document is locked to the exact version of the template it came from, so future template edits never corrupt old documents.

The app also maintains a clause library where standard legal blocks like confidentiality terms, payment conditions, and jurisdiction clauses are stored, versioned, and reused across multiple templates independently.

Phase 1: Web app only.

The Ideal Tech Stack

The Challenging Technical Problems

1. Conditional Block Rendering Logic: A template is not a flat text file. Certain clauses only appear under specific conditions. If the engagement type is litigation, include clause 7. If the fee structure is retainer-based, show the retainer replenishment clause instead of the hourly billing clause. This conditional logic needs to be stored as structured data inside the template, not hardcoded. Handlebars.js handles the rendering, but you need to design the schema that stores these conditions in a way that is both flexible and queryable.

2. Template Versioning Without Breaking Existing Documents: A lawyer edits a template to update the jurisdiction clause. Every document generated before that edit must remain exactly as it was at generation time. This means you cannot store a reference to the current template and re-render on demand. You must snapshot the complete template state at the moment of document generation and store that snapshot immutably. This is a real data architecture decision, not a simple CRUD operation.

3. Clause Library with Independent Versioning: A clause can exist in multiple templates. When the standard confidentiality clause is updated, you need to know which templates use it, which documents were generated with the old version, and give lawyers the choice to propagate the update or keep existing templates pinned. This is a many-to-many relationship between clauses and templates, with version state on each edge of that relationship.

4. Generating Production-Quality PDFs: Puppeteer renders HTML to PDF via a headless Chrome instance. Getting the output to look like an actual legal document, with correct page breaks that do not split a clause mid-sentence, consistent header and footer on every page, proper indentation, and numbered sections, requires careful HTML and CSS design. Legal professionals will reject output that looks like a webpage printed to PDF.

5. Form Schema Derived from Template Structure: When a lawyer opens a template to generate a document, the input form must be automatically constructed from the template's variable definitions. If the template defines fee amount as a currency field and engagement date as a date field, the form must render those exact controls with the right validation. The form is not hand-coded. It is generated dynamically from the template schema stored in the database.

How Your STEM Link Bootcamp Prepares You For This

TypeScript interface design and schema modeling are critical here. The template, its variables, its conditional blocks, and the clause library all need to be modeled as strict typed structures before any rendering logic works correctly. The contract-first thinking taught in the bootcamp directly shapes how cleanly this system gets built.

Relational database engineering and normalization handle the most complex part of this project. The relationship between templates, clauses, versions, and generated documents requires properly normalized tables with clear foreign key design. Getting this wrong means data inconsistency that corrupts legal documents.

Service layer architecture and transactional writes ensure that generating a document, snapshotting the template version, saving the output file reference, and creating the matter record all happen atomically. If the PDF generation fails, nothing should be committed to the database.

Zod validation and form handling from the bootcamp map directly to the dynamic form generation challenge. Generating a Zod schema programmatically from template variable definitions and wiring it to React Hook Form is a genuinely advanced pattern that interviewers notice.

Role-based access control and middleware separate what a senior partner can do versus what a clerk can do. Partners create and publish templates. Associates generate documents from them. Clerks only view completed documents. This is the same RBAC pattern from the bootcamp applied to a more nuanced permission hierarchy.

File upload and storage patterns from the production readiness lessons apply directly to storing generated PDFs and retrieving them securely per client matter.

Bus Arrival Prediction via Passive GPS Crowdsourcing

The Problem

Sri Lanka has no real-time bus tracking. Passengers stand at stops with zero information, no idea if the bus is 2 minutes away or 20. They miss buses, make wrong decisions, and waste hours every week. The data to fix this exists, but it's sitting in every passenger's pocket, but no system collects or uses it.

What You're Building

A mobile app for passengers that runs silently in the background while they ride a bus. The app detects that the user is on a bus automatically, using speed patterns and movement behavior from the phone's GPS and accelerometer, without the user doing anything manually. It contributes their location anonymously to a live pool of bus positions.

On the other side, any passenger waiting at a stop opens the app, selects their route, and sees live bus positions on a map with an estimated arrival time calculated from how the bus has been moving over the last few minutes.

A lightweight web dashboard for transit researchers or operators shows aggregated route coverage, data contribution density, and average travel times by route and time of day.

Phase 1: Mobile app for passengers. Web dashboard for operators.

The Ideal Tech Stack

The Challenging Technical Problems

1. Passive Trip Detection Without User Input: The app can't ask "are you on a bus?" every time. It needs to figure this out from sensor data alone. Speed consistently above 20kmh but below 60kmh, with periodic stops matching known stop dwell times, indicates a bus. Walking is slow and continuous. A vehicle is fast but doesn't stop at regular intervals. You need to build a state machine, idle, possibly on bus, confirmed on bus, exited; driven by accelerometer and GPS signals, running in the background without draining the battery.

2. Background Location on Mobile: iOS and Android aggressively kill background processes to save battery. Getting reliable location pings every 10–15 seconds while the app is in the background requires specific permission handling, a foreground service on Android, and careful use of Expo's background location task API. Most developers don't encounter this until production and it behaves differently across OS versions and device manufacturers.

3. Route Matching from Raw GPS: A passenger's raw GPS trace is noisy, the phone thinks you're 30 meters off the road sometimes. You need to snap observed positions to the nearest known route geometry using map-matching logic. Turf.js handles the geospatial math, nearest point on a linestring, bearing calculation, distance thresholds but building the route matching pipeline cleanly is a real engineering task.

4. Arrival Estimation from Sparse Crowdsourced Data: You don't have a bus with a GPS device. You have 3 passengers on that bus contributing pings every 15 seconds. The bus position is an inference from those pings, not a direct reading. When the bus is between two contributor pings, you interpolate. When there are no contributors on a bus for 2 minutes, you have to decide, is the data stale, or did all contributors exit? The arrival estimate must degrade gracefully and show confidence levels rather than false precision.

5. Cold Start Problem: When no one is actively riding route 138 right now, there's no live data. The app must fall back to historical average travel times by time-of-day and day-of-week, clearly labeled as an estimate based on past data, not pretend live data doesn't exist. Building this two-mode system, live when data exists, historical fallback when it doesn't, requires careful data pipeline design.

How Your STEM Link Bootcamp Prepares You For This

Geolocation and device sensor integration from the mobile track is the foundation of the entire product. Background location, GPS coordinates, and map rendering with React Native Maps are all skills built directly in the bootcamp, here you push them further by combining GPS with accelerometer data to infer behavior rather than just record position.

Real-time communication with Socket.io powers the live bus position updates. Every ping from a contributor needs to reach waiting passengers within seconds. The WebSocket patterns you learn apply directly, but here the broadcast logic is more complex because you're routing updates by bus route, not just by room.

Relational database design and indexed queries matter significantly when you're storing thousands of location pings per hour. Designing the schema so you can efficiently query "all pings on route 138 in the last 5 minutes" requires proper indexing strategy, exactly what the database engineering lessons cover.

Offline-first architecture and AsyncStorage from the mobile track handle the scenario where a passenger opens the app underground or in a low-signal area. Cached route data and last-known positions keep the app useful even without live connectivity.

React dashboard with charting libraries from the web track builds the operator view, route coverage heatmaps, peak hour contribution graphs, average arrival accuracy over time. The data visualization skills from NestBoard's analytics dashboard apply directly here.

#3 Court / Field Booking with Live Waitlist Engine

The Problem

When someone books a badminton court or futsal field and cancels last minute, that slot just dies. Nobody knows it's free. Meanwhile 10 people who wanted that exact slot had no way to get it. Courts stay empty, players stay frustrated, and the facility loses revenue and all because there's no smart system to redistribute cancelled slots in real time.

What You're Building

A web app for facility managers to list their courts and manage bookings, and a mobile app for players to book slots and join waitlists.

When a player cancels, the system doesn't just free the slot, it immediately fires a timed offer to the next person on the waitlist. That person gets a push notification and has 5 minutes to confirm. If they don't respond, the offer cascades to the next person automatically. The slot only goes back to public availability if the entire waitlist exhausts without a claim.

Players can book directly if slots are open, or join a waitlist ranked by signup time. The facility manager sees a live dashboard - every court, every slot, every active waitlist in real time. No polling, no refresh. Everything updates live across all open screens the moment anything changes.

Phase 1: Web app for facility managers. Mobile app for players.

The Ideal Tech Stack

The Challenging Technical Problems

1. Concurrent Slot Claiming Two waitlisted players receive the offer simultaneously and both try to confirm at the exact same millisecond. Without proper database-level locking, both succeed and the same slot gets double-booked. You need SELECT FOR UPDATE on the slot row so only one transaction wins, the other gets a conflict error and the system moves to the next person on the waitlist.

2. Timed Offer Expiry with Cascading The offer given to person #1 must expire in exactly 5 minutes regardless of server restarts. If they don't respond, the system must automatically cascade to person #2 - not when someone manually checks, but as a scheduled background event. This requires a job queue (BullMQ + Redis) with delayed jobs that trigger the next cascade step. If the server restarts mid-countdown, the job must survive and resume.

3. Real-Time State Sync Across Roles When a slot is claimed off the waitlist, the facility manager's dashboard, the booking screen of person #1 (offer expired), and the live slot grid of 50 public users all need to update simultaneously, not on next refresh. This requires Socket.io rooms organized by facility and date, broadcasting targeted events only to relevant connected clients.

4. Waitlist Position Fairness Under Load During peak hours (Friday 6pm), 40 people join the waitlist for the same slot within seconds. The system must guarantee strict FIFO ordering under concurrent inserts, a simple created_at timestamp isn't safe because two inserts can land at the same millisecond. Needs a database sequence or atomic Redis counter to guarantee true ordering.

5. Offer State Machine Each waitlist offer isn't just "sent or not sent", it has states: pending → offered → accepted / expired / declined. If a player's app is closed when the offer fires, the notification must still land via FCM. If they open the app 3 minutes later, the offer UI must show the correct countdown remaining, not restart from 5 minutes. This requires the offer expiry time to be stored server-side, not computed client-side.

How things you learn at STEM Link Fullstack (Web + Mobile) Bootcamp can be applied

The TypeScript schema design skills you build let you model the booking domain properly, slots, offers, waitlist entries, and their state transitions as strict typed contracts before writing a single API line.

Relational database engineering is at the core of this project. The booking overlap check, ACID transactions, and row-level locking you learn are the exact mechanisms that prevent double-booking under concurrent load. This isn't a concept exercise, it breaks in production without it.

Service layer architecture and transactional writes teach you to wrap the slot lock, booking creation, and waitlist state update inside a single atomic operation. If any step fails, everything rolls back. That's the difference between a toy project and a real system.

Firebase auth, JWT middleware, and role-based access control map directly to separating facility manager permissions from player permissions both in the API and the React Native mobile app.

Stripe payment integration adds the constraint that a waitlist offer is only confirmed after payment clears, same transactional checkout flow from the bootcamp, with higher stakes logic around it.

Socket.io and real-time patterns plus BullMQ job queues are where this project goes beyond what most bootcamp graduates build. The live dashboard and timed offer cascade are the engineering problems that make this stand out in an interview.

Institute Fee Payment: Immutable Audit Trail

The Problem

A student claims they paid their installment. The admin says there is no record of it. Neither side has clean proof. The institute tracks payments in Excel, which anyone can edit, overwrite, or accidentally corrupt. There is no receipt system, no audit history, and no automated reminders. Every dispute becomes a manual investigation that damages trust between the institute and the student.

What You're Building

A web app for institute admins to manage student fee schedules and record payments, and a mobile app for students to track their payment history and receive reminders.

Every payment posted creates an append-only ledger entry. Nothing is ever edited or deleted. If a mistake is made, a reversal entry is posted against it, just like double-entry bookkeeping. The moment a payment is recorded, the system automatically generates a signed PDF receipt and delivers it to the student via email and WhatsApp. That receipt becomes the single source of truth for any dispute.

Students on the mobile app see their full ledger, upcoming installment due dates, and download past receipts anytime. Admins see a dashboard of all outstanding balances, overdue accounts, and collection health across the entire student cohort. Automated reminders fire via WhatsApp and email at configured intervals before and after each due date, without any manual action from admin staff.

Phase 1: Web app for admins. Mobile app for students.

The Ideal Tech Stack

The Challenging Technical Problems

1. Enforcing True Immutability at the Database Level Saying "we will not edit records" is a policy, not a guarantee. A future developer, a bug, or an admin tool can still issue an UPDATE or DELETE against a payment row. True immutability means enforcing it at the database level using PostgreSQL row-level security policies and trigger functions that reject any UPDATE or DELETE on the ledger table entirely. The application layer should never be the only protection.

2. Double-Entry Correction Without Edits When a payment is recorded with the wrong amount, you cannot fix it by editing the row. You post a reversal entry that negates the original, then post a new correct entry. This is standard accounting practice but requires careful balance computation logic. The running balance for any student is always computed by summing the entire ledger history, not by reading a stored balance field. Storing a balance field would create a second source of truth that can drift.

3. Cryptographically Signed Receipts A receipt that can be edited in Photoshop is not evidence. The system needs to generate a hash of the receipt content, sign it with a private key stored securely on the server, and embed the signature in the PDF. A verification endpoint accepts a receipt ID and confirms whether the document is authentic and unmodified. This is what makes the receipt legally defensible rather than just a formatted PDF.

4. Reliable Scheduled Reminders Across Timezone and Calendar Logic A reminder must fire 7 days before, 3 days before, and on the day of each installment due date. When a new installment schedule is created, the system must compute all future reminder timestamps and enqueue them as delayed jobs in BullMQ. If a student pays early, the pending reminders for that installment must be cancelled from the queue. If the server restarts, jobs already enqueued in Redis must survive. Managing this job lifecycle correctly across creation, cancellation, and recovery is not trivial.

5. WhatsApp Business API Integration Unlike email, WhatsApp messages to customers must use pre-approved message templates registered with Meta. You cannot send free-form text. The reminder message, receipt notification, and overdue alert each need to be designed as template messages, submitted to Meta for approval, and then triggered via the Cloud API with the correct variable substitution. This involves working with a real third-party API with approval workflows, rate limits, and delivery status webhooks.

How Your STEM Link Bootcamp Prepares You For This

Relational database engineering and ACID properties are the backbone of this project. Understanding transactions, atomicity, and how to enforce data integrity at the database level goes far beyond what most junior developers know. The bootcamp builds this thinking directly through the NestBoard booking overlap and conflict prevention work.

Service layer architecture and transactional writes ensure that recording a payment, updating the ledger, generating the receipt PDF, uploading it to storage, and firing the WhatsApp notification all happen as a coordinated flow. If the PDF generation fails, the payment record should not be orphaned without a receipt reference.

Scheduled job queues with BullMQ extend what the bootcamp teaches about background processing. Here the challenge is not just running a job, but managing the full lifecycle of many scheduled jobs per student, including cancellation when a payment clears early.

Firebase auth and role-based access separate admin capabilities from student view access cleanly. An admin can post payments and run reports. A student can only view their own ledger. The same RBAC middleware patterns from the bootcamp apply directly.

React Native mobile development and offline persistence from the mobile track handle the student-facing app. A student should be able to view their payment history and download receipts even without connectivity, using the same AsyncStorage caching patterns taught in the bootcamp.

Third-party API integration patterns taught through Stripe in the bootcamp give students the mental model for working with any external API that has webhooks, rate limits, and authentication flows. The WhatsApp Business API follows the same integration pattern but with different domain complexity.

Checkout the Fullstack Product Developer (Web + Mobile) Bootcamp, which can make you a Career Ready developer

Checkout Here 👉https://stemlink.online/products/bootcamps/full-stack-engineering-for-developers