DEV Community

Tejas H
Tejas H

Posted on

Solo Build Challenge: How I Built Beacon AI for HACKHAZARDS '26

When preparing for placements and technical interviews, most students face a major roadblock: generic AI tools give flat advice, and mock interviews with real people are hard to schedule.
To solve this, I decided to join HACKHAZARDS '26 as a solo developer and build Beacon AIβ€”a complete, full-stack AI career ecosystem designed to help students bridge the gap between college and their dream tech roles.

πŸš€ The Core Features I Shipped
Instead of creating a simple chatbot wrapper, I engineered three distinct functional modules entirely on my own:

Interactive AI Interview Coach: A real-time simulator where users answer technical questions and get instant, structured feedback on their performance.
Skill Gap Analytics Dashboard: A visual interface that tracks user progress, highlights weak areas, and points out missing skills for specific industry roles.
Automated Resume Builder: A structured tool that helps users organize their professional details and checks if their background matches current market standards.

πŸ› οΈ My Technology Stack
To ensure the application runs fast and manages user data properly, I chose a decoupled, full-stack architecture:
Frontend & Server Layers: Built with Next.js (App Router) and styled using Tailwind CSS and Shadcn UI for a clean, professional user experience.
Database Persistence: I integrated Prisma ORM connected to a relational database to keep user metrics, scores, and historical profiles completely active.
AI Microservice Backend: A dedicated FastAPI (Python) server running LangChain and the Google Gemini API to handle structured prompt processing and smooth token generation.

πŸ“‚ Project Architecture
To keep the codebase clean and ready for judge code reviews, I organized the repository into explicit folders:
β”œβ”€β”€ /app # Next.js frontend pages and layouts
β”œβ”€β”€ /actions # Server actions for database operations
β”œβ”€β”€ /python-backend # FastAPI server for LangChain & Gemini AI
β”œβ”€β”€ /components # Reusable UI elements via Shadcn UI
β”œβ”€β”€ /data # Static data configurations (FAQs, guides)
└── /lib # Prisma Client setup and utilities

⚑ Challenges I Faced & My Solo Fixes

  1. Managing the Dual-Service Pipeline Alone Building both a JavaScript frontend framework and a Python backend microservice simultaneously during a hackathon can get messy quickly. The Fix: I carefully isolated the AI logic inside FastAPI. This allowed me to manage API requests efficiently and pass structured data back to the Next.js client using server actions without locking up the client interface.
  2. Ensuring Data Integrity Across Sessions I wanted to ensure this felt like a real SaaS product, meaning data could not just vanish on a page refresh. The Fix: I set up Prisma ORM early in the development cycle. Every mock interview score and skill assessment is written securely to the database, ensuring a user's progress history is completely saved. ** 🏁 Conclusion** Taking on HACKHAZARDS '26 as a single solo developer was a massive challenge, but it pushed me to move away from simple prototypes and master a true production-ready stack. The application is fully live and ready to run!

Check out the project here:

πŸ”— Live Application: https://beacon-ai-blitz.vercel.app/
πŸ’» GitHub Repository: https://github.com/Tejas-h-blitz/Beacon-AI

Built with ❀️ by a solo hacker for the Namespace Community.

Top comments (2)

Collapse
 
julianneagu profile image
Julian Neagu

Solid split between Next.js + FastAPI. That’s usually where most hackathon builds get messy, but isolating the AI layer is the right call.
Curious how you’re handling latency between server actions and Python service under load.

Collapse
 
tejas_h_blitz profile image
Tejas H

Great question! Latency was definitely something I had to think about. Since this was a hackathon build, I kept it simple β€” Next.js server actions call the FastAPI endpoint directly, and I relied on Vercel's edge network to keep that round-trip tight.

Under real load, the bottleneck would likely be the Gemini API response time rather than the service-to-service hop itself. For a production version, I'd look at streaming tokens back via SSE instead of waiting for the full response, and possibly a queue (like BullMQ) to handle concurrent interview sessions without cold-start spikes on the Python service.

For the hackathon scope it held up well, but you've pointed out exactly the next thing I'd tackle scaling it. Appreciate the feedback!