DEV Community: MEHRAAN AMIN

HackDesk: My Passion for Hackathons, Powered by Google AI

MEHRAAN AMIN — Fri, 10 Jul 2026 09:55:53 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

My biggest passion is the developer community and hackathons. I love seeing students build amazing things, but I’ve also seen the struggles: organizers stress over check-ins, and beginners freeze when they can't think of a good project idea.

Fueled by this passion to help my community, I built HackDesk - Passion Edition. It is an intelligent, high-performance event management system designed for large-scale hackathons. It features a robust attendee registration system and an AI-powered Hackathon Idea Generator that instantly provides customized, beginner-friendly project ideas to students so they can start building immediately.

Demo

Live Vercel Deployment: HackDesk Passion Edition

(Feel free to try the Idea Generator to see the Google AI fallback in action!)

Code

CodeWithMehru / HackDesk-Passion-Edition

🚀 HackDesk - Passion Edition

An Intelligent, Concurrency-Proof Hackathon Management Platform

HackDesk is a high-performance event management system designed to seamlessly handle large-scale hackathons. It features a robust registration and check-in system, alongside a unique AI-powered Hackathon Idea Generator equipped with atomic locking to prevent race conditions during high-traffic claim events.

Built with modern web technologies to ensure low latency, high availability, and a premium user experience.

✨ Key Features

👥 Smart Registration & Attendance: Bulk-import participants via CSV parsing Manually add late or on-the-spot attendees seamlessly. Active Session tracking (e.g., "Day 1", "Day 2") for accurate multi-day check-ins.

🧠 AI-Powered Idea Pool (Pre-generation & Smart Fallback Architecture): Organizers can generate batches of beginner-friendly project ideas based on specific themes using the Google Gemini AI API Pre-generating ideas prevents API rate limits and keeps the end-user experience lightning fast. If the pool runs empty, the system uses Google AI as…

View on GitHub

How I Built It

I built HackDesk using Next.js 16 (App Router), TypeScript, Tailwind CSS, and Supabase (PostgreSQL).

Managing a hackathon means dealing with high traffic (e.g., 200 students clicking "Generate Idea" at the exact same millisecond). To solve this, I engineered a Concurrency-Proof Idea Claiming system. The backend uses strict isolation and atomic row-level locking in PostgreSQL so that no two students ever get the same idea.

The Smart Fallback Architecture:
To ensure the system never crashes or runs out of ideas, I implemented a two-tier architecture:

It first tries to fetch a pre-generated idea from the Supabase pool.
If the pool is completely empty, instead of throwing an error, the system seamlessly falls back to Google Gemini AI 1.5 Flash. The AI generates a fresh, structured JSON idea on the spot, saves it to the database, and assigns it to the student instantly.

Prize Categories

I am submitting this project for the Best use of Google AI prize category.

I utilized the @google/generative-ai SDK (Gemini 1.5 Flash model) to create the live fallback mechanism. This ensures that the hackathon's idea generation never hits a dead end, combining database reliability with the dynamic generative power of Google AI.

How we built KoshurLock Holmes: an AI detective for cyber attacks, and the night it almost broke me

MEHRAAN AMIN — Sun, 05 Jul 2026 06:54:50 +0000

The problem with a data breach is not finding evidence. It is connecting it.

But let me start where I actually was: 4 AM, last day of the hackathon, staring at this in my terminal.

RateLimitError: GroqException - Rate limit reached for model
`llama-3.3-70b-versatile` on tokens per day (TPD):
Limit 100000, Used 99787, Requested 1616.
Please try again in 20m12s.

Used 99,787 out of 100,000. My deployment was half done, my demo graph was empty on the server, and the free tier had 213 tokens left. The submission deadline was hours away. I had not slept. I had not eaten. My friends were asleep and I was swapping API keys like a gambler swapping chips.

This post is the story of how we got there, and how it ended at 7 in the morning with the best sigh of relief I have ever taken.

First, some honesty about how I got here

When I joined my first WeMakeDevs hackathon, I did not believe in it. I thought it was one of those ordinary online events. Fake prizes, no follow-through, what would I even get out of it. I joined anyway, mostly out of boredom, got into the Discord, talked to people, made a few connections.

I landed in the top 50. A few days later an email showed up: a free Claude Max subscription as a gift. I read it twice. I genuinely could not believe a hackathon had actually delivered something.

So when this hackathon opened, I did not hesitate. I messaged my friends and said we are joining as a team this time. Three of us: me (Mehraan), Aqib, and Ubaid.

The spark

We spent the first evening in our group chat throwing ideas around and shooting most of them down. Then one of my friends dropped a thought that stuck: what happens after a company gets hacked?

I started digging into it. The answer is honestly depressing. After a breach, the evidence is everywhere. VPN records. File access logs. The email gateway. Badge readers at the office doors. CCTV. HR notes. Anonymous tips. Each system tells one small piece of the story, and a human analyst has to stitch all of it together by hand.

That stitching takes days. Sometimes weeks. It is exactly the kind of digital forensics work that companies like Palantir charge enormous money for. And here is the ugly part: read each log alone and the logs will lie to you. If an attacker steals an employee's password, every log points at the employee. The truth only appears when you connect the same person, account, device, IP, and file across every source at once.

So that became the project. An AI investigator that reads all the scattered logs, builds one connected knowledge graph out of them, and answers plain English questions with cited, multi-hop reasoning.

Why the name KoshurLock Holmes

Koshur is what we call the Kashmiri language back home. So the name is exactly what it sounds like: Sherlock Holmes, but ours. A detective from Kashmir.

And the Holmes part is not decoration. The whole product behaves like a detective. It remembers evidence. It recalls answers with citations. You can teach it a confirmed finding. And, this is the part I am most proud of, you can make it forget a planted false clue, and watch the wrong conclusion collapse.

What it actually does

You upload evidence files (CSV, TXT, PDF, DOCX). The backend parses each one, wraps it with a provenance header, and feeds it through Cognee, which extracts entities and relationships and builds a typed knowledge graph. The same person appearing in the VPN log and the badge log resolves to one shared node.

On top of that graph sit four operations that map to Cognee's memory lifecycle:

Remember: ingest each source and build the graph
Recall: ask a question in plain English, get a cited multi-hop answer
Improve: teach it a confirmed analyst finding so the graph reweights
Forget: surgically remove a discredited source

The UI is a security operations console: a full interactive Cytoscape knowledge graph where entity types have their own shapes and colors, a dense filterable timeline built from the log timestamps, an investigation console with expandable raw log citations, and a before-and-after view we call The Turn.

The demo case: a man who was framed

To show what the system can do, we wrote a full fictional incident: the Northgate Financial case.

An employee named Rahul Sharma is framed. On the night of 30 June, someone logs into his account from a foreign IP, 41.220.13.7, out of Lagos. That session downloads the customer database and a PII export and emails them to an external Gmail address. An anonymous tip lands the same week, accusing Rahul directly.

Every log says Rahul did it. Except two: the badge reader and the CCTV both place him physically inside the office at the exact time of the 2 AM foreign login. And a few days earlier, his credentials were phished.

Here is The Turn, live in the app:

Ask "who is responsible?" With all evidence present, including the planted tip, the answer implicates Rahul.
Teach the confirmed SOC finding: the foreign IP is a known attacker, the credentials were phished, this was an account takeover.
Forget the anonymous tip.
Ask again. The conclusion re-derives. Rahul is exonerated, and the system names the external attacker at 41.220.13.7, because the takeover explanation plus the physical alibi make his guilt impossible.

Watching a wrong verdict flip to the right one in front of you never gets old. We also validated the same pipeline on a separate uploaded case, where it correctly identified the true insider and cleared a wrongly accused employee who was on leave.

The architecture decision that shaped everything

Before writing application code we faced a fork in the road.

Option A: the default AI stack. OpenAI for the LLM, a hosted vector database, a separate graph database, paid embeddings. Three or four services, three or four bills, and your evidence leaves your machine.

Option B: make the entire thing free and self-hosted. Groq's free tier for the LLM, embeddings computed locally with FastEmbed, and every kind of storage crammed into one PostgreSQL instance.

We picked B, and it turned out Cognee has a mode built for exactly this. One env var:

USE_UNIFIED_PROVIDER=pghybrid

That puts the relational data, the pgvector index, and the knowledge graph in the same Postgres. One service to run. One pg_dump backs up the entire memory of the investigator. This single decision saved us later in a way I could not have predicted (more on that in the deployment war story).

We were so serious about the no-OpenAI promise that the backend refuses to boot if it detects any path that could route there:

if os.environ.get("OPENAI_API_KEY", "").strip():
    problems.append(
        "OPENAI_API_KEY is present in the environment - unset it so "
        "Cognee cannot fall back to OpenAI"
    )

A hard fail at startup. Paranoid? Yes. Justified? Also yes, as you are about to see.

The quirks that ate my nights

Every tool has sharp edges you only find at 1 AM. Here are the ones that got me, written down so they do not get you.

The silent OpenAI fallback. If you use local FastEmbed embeddings with Cognee, you must set the dimensions explicitly:

EMBEDDING_PROVIDER=fastembed
EMBEDDING_MODEL=sentence-transformers/all-MiniLM-L6-v2
EMBEDDING_DIMENSIONS=384

Leave EMBEDDING_DIMENSIONS unset and Cognee quietly defaults to 3072, which is an OpenAI dimension, and quietly tries to go there. No error. Just wrong behavior you discover much later. This one line is why our startup guard exists.

json_mode, not json_schema. Groq's Llama models mangle the structured tool-call path, and cognify aborts halfway with confusing errors. Plain LLM_INSTRUCTOR_MODE=json_mode works. Hours of my life are in that one setting.

Access control that empties your graph. Cognee's multi-user access control partitions the graph per tenant. Sounds fine, until your node counts read zero and cross-source reasoning falls apart because everything landed in different partitions. For a single-analyst tool: ENABLE_BACKEND_ACCESS_CONTROL=false.

The 100,000 token wall. Groq's free tier gives you 100k tokens per day, and a full ingest of our eight evidence files eats almost exactly that. Run the seed twice in a day and the second run dies mid-graph. Our fix became a core feature: seed once, then pg_dump the whole built graph into a snapshot. Every boot after that restores warm, with zero LLM calls. The demo never spends tokens again.

Deployment day, or, the longest night of my life

Everything worked locally. Then I tried to put it on the internet, and the internet fought back.

Railway does not run a docker-compose file, so the one-command stack became three separate services wired together by hand. The frontend crashed on arrival:

nginx: [emerg] host not found in upstream "backend"

Locally, nginx proxies to a container literally named backend. On Railway there is no such name. And here is the trap: hardcode the Railway internal hostname and your local setup breaks instead. The same config file cannot serve both. The fix was turning nginx.conf into a template that reads the upstream from an environment variable at container start:

location /api/ {
    proxy_pass ${BACKEND_ORIGIN}/;
}

Locally it defaults to http://backend:8000. On Railway a service variable points it at the internal address. One image, both worlds.

Then came the domain confusion that nearly finished me. Railway generated koshurlockholmes.up.railway.app for the backend and koshurlock-holmes.up.railway.app for the frontend. One hyphen apart. At 5 AM, running on no sleep, I pointed the frontend at itself and spent an hour debugging a loop of my own making. If you take one thing from this post: name your services something you cannot confuse at 5 AM.

And the best trick of the night, the one that saved the demo: the server graph was empty and I had no quota left to re-seed it. But remember, the entire memory lives in one Postgres. So I took the snapshot from my laptop and restored it straight into Railway's database over the public connection:

pg_restore --clean --if-exists --no-owner \
  -d "$RAILWAY_DATABASE_URL" \
  scripts/snapshots/cognee_db.dump

Ninety five nodes and 279 edges appeared on the server in about ten seconds. Zero tokens spent. That is the one-Postgres decision from day one paying for itself at the worst possible hour. I nearly cried.

One last bug: every backend restart reset the demo state, so the case kept showing "snapshot not found" after each redeploy. The fix was making the backend restore the snapshot on every startup instead of only on a cold, empty graph. A few lines in the FastAPI lifespan, and restarts stopped being scary.

At 7 AM the full flow finally ran clean on the live link. Demo case loads warm. The Turn flips the verdict. Uploads ingest. I sat back in my chair and just breathed. I had not eaten since the previous afternoon. I did not care.

What I actually learned

I keep coming back to one thought.

A project like this, at this scope, should take three to six months. A knowledge graph engine, a live investigation console, a forensics timeline, a retraction system, self-hosted deployment. Months. We built it in hackathon hours, and I finally understand why people keep doing these things to themselves.

The hackathon effect is real. The pressure, the curiosity, the excitement compress months of work into days, and you come out the other side a different engineer than you went in.

I learned more about Postgres, nginx, LLM rate limits, and my own stubbornness in one sleepless night than in weeks of normal work.

Huge thanks to WeMakeDevs for running this. After two of their hackathons, one skeptical entry and one free Claude Max subscription later, I can say it plainly: these are the best hackathons I have taken part in, and they actually deliver.

KoshurLock Holmes is open source under MIT. The repo has the full docs, the Northgate case spec, and everything you need to run it with one docker compose command and a free Groq key. If you try it, break it, or want to talk about the architecture, find me on GitHub.

The evidence was always there. We just built the detective.

Team: Mehraan Amin (Mehru), Aqib Javid Bhat, Ubaid Mushtaq. Built with Cognee, Groq, FastEmbed, PostgreSQL + pgvector, FastAPI, React, and Cytoscape.js.

How I Built CoralSec Copilot: A Unified Enterprise SOC with Coral & Next.js in 4 Days

MEHRAAN AMIN — Sat, 30 May 2026 06:10:46 +0000

The tech industry is currently in a frenzy. Everyone is rushing to build the next big AI application, slapping a chatbot interface onto a database and calling it a day. But in this gold rush, we are leaving something critical behind: Enterprise Security.

Living in a Kali Linux environment and spending time hunting vulnerabilities teaches you one fundamental truth: security is entirely about context. Hardcoded API keys, undocumented access escalations, and compliance blind spots remain the number one cause of major data breaches. Security teams don’t just need a chatbot that can answer questions; they need a single pane of glass. They need a Security Operations Center (SOC).

For the Pirates of the Coral-Bean Hackathon (hosted by Coral and WeMakeDevs), I decided to tackle this massive industry problem. Over the course of 4 sleepless nights, I built CoralSec Copilot—an AI-powered, unified Enterprise SOC platform.

Here is the complete Captain's Log of my entire journey, the architecture, the roadblocks, and a reproducible guide so you can build and run it yourself.

Day 1: The Brainstorm, Grok, and Cursor AI

When the hackathon was announced, my initial thought was basic: "I'll build a CLI agent that scans code." I fired up my IDE, opened Cursor, and started bouncing ideas around. I even looked into some AI models like Grok to understand how they process vast amounts of real-time data.

But while brainstorming the architecture, I hit a wall. Scanning a GitHub commit for a leaked AWS key is great, but what if the AI also knew whether the developer who pushed that commit had recently escalated their admin privileges? What if it knew the exact SOC2 compliance policy from our company’s Notion workspace?

To do this traditionally, I would have to write dozens of messy REST API integrations. I'd have to handle rate limits, write custom Python scripts for GitHub, another set for Slack, another for Notion, and then build fragile ETL (Extract, Transform, Load) pipelines to bring all that data together.

It sounded like an absolute nightmare for a 4-day sprint. I needed a way to unify data without writing thousands of lines of glue code.

Day 2: The Magic of Coral MCP & Cross-Source SQL

This is where the Coral Protocol stepped in and completely changed my development trajectory.

Coral Protocol is not just a database wrapper; it is a unified data intelligence hub. It allowed me to replace all that custom glue code with read-only, cross-source SQL. By integrating the Coral Model Context Protocol (MCP), I gave my AI agent the ability to write a single query with LEFT JOIN semantics across entirely different platforms.

Instead of writing five different Python scripts to fetch data, my agent can now execute something conceptually like this under the hood:

[[Note for Mehru: Use the code block button in Dev.to for the SQL below]

`SELECT
github.cve_id,
slack.incident_channel,
notion.compliance_policy
FROM github_dependabot AS github
LEFT JOIN slack_channels AS slack ON slack.topic = github.cve_id
LEFT JOIN notion_pages AS notion ON notion.tags = 'SOC2'
WHERE github.state = 'open';`

[End Note]]

As a first-time Coral user, shifting my mindset from writing complex backend logic to simply leveraging Coral’s SQL interface for cross-platform joins was mind-blowing. It completely eliminated the data silos. My AI agent could now correlate a GitHub Dependabot vulnerability, an active Slack security channel, and an internal Notion compliance policy in a single execution path.

Day 3: Giving the AI Brain a Body (Next.js Dashboard)

An AI brain is incredibly powerful, but IT admins and security operators need a visual dashboard to monitor threats continuously. They can't just type prompts all day. I spent the third day wrapping my Coral-powered engine into a persistent Enterprise UI.

Using Next.js 15, Tailwind CSS, and shadcn/ui, I built a 4-module dashboard to act as a single pane of glass:

Global Risk Dashboard
This isn't just a static page. It calculates a dynamic risk score based on aggregated posture signals pulled live from the APIs. It gives security teams a bird's-eye view of their infrastructure's health.
Secret Scanner
Visualizes leaked Personal Access Tokens (PATs) and AWS keys from commit pipelines. It flags critical misconfigurations the moment they happen.
Vulnerability Intelligence
An interactive tracker for OSV and CVE data aligned with Dependabot. It breaks down threats by severity, highlighting things like OpenSSL buffer over-reads or prototype pollution in lodash.
Compliance Monitor
A live ledger that directly compares GitHub admin access against Notion SOC2 policy pages. If someone gets unauthorized admin access on GitHub, the dashboard flags it against the company policy instantly.

Day 4: Resiliency, Python Fallbacks, and The Cybersecurity Mindset

What happens if the cloud alert tables are entirely empty? A security tool cannot just fail silently. I needed this platform to be bulletproof.

To achieve this, I built a resilient Python and LangChain scanner as a fallback. If the primary cloud scans return empty, the system triggers zero-day commit parsing. It uses structured tool calls to parse local commit diffs and surface historical leak patterns before they hit production.

I also engineered bulletproof API pushdowns. I structured the SQL so that queries like Dependabot use exact states (e.g., state = 'open' OR state IS NULL). This ensures that if a third-party API returns a null severity, my dashboard doesn't accidentally drop a valid open alert.

The Sandbox Deployment Decision

When it came time to deploy, I faced a serious dilemma. I wanted the hackathon judges and the community to experience the beautiful Next.js UI. However, as a cybersecurity researcher, I strictly follow security best practices.

Exposing my active Personal Access Tokens (GitHub, Slack, Notion) on a public Vercel domain was an absolute no-go. It defeats the entire purpose of building a security tool.

So, I deployed the live link as an interactive Sandbox / Demo Mode. By adding a simple environment variable, the app renders a safe UI where anyone can explore the UX and the AI agent's frontend flow safely without exposing real company data. But to experience the real-time scanning engine, developers must clone the repo and run it locally with their own keys.

Charting the Course: Build Your Own CoralSec Copilot

If you want to run this Enterprise SOC on your own company's repositories, here is the exact reproducible route to get the real-time scanning engine fired up on your local machine.

Prerequisites:
You will need two terminal windows to run the Next.js UI and the Coral MCP Engine simultaneously.

Step 1: Setup Environment
Clone the repository and set up your environment variables.

[Note for Mehru: Use the code block button in Dev.to for the bash commands below]
git clone https://github.com/CodeWithMehru/coral-security-copilot.git
cd coral-security-copilot
cp .env.example .env
[End Note]

Open the .env file and insert your GitHub, Notion, and Slack tokens. Make sure to set CORALSEC_USE_DEMO=false so you exit the Sandbox and run the live engine!

Step 2: Start Coral Engine
Open your first terminal in the root directory and start the Coral Studio:

[Note for Mehru: Use the code block button in Dev.to for the bash command below] coral mcp studio [End Note]

Step 3: Start the Next.js Frontend
Open a second terminal, install the dependencies, and start the development server:

[Note for Mehru: Use the code block button in Dev.to for the bash command below]
cd frontend
npm install
npm run dev
[End Note]

Open localhost:3000 in your browser to view the live dashboard. You now have a fully functional, AI-powered Enterprise Security Operations Center running on your local machine!
Final Thoughts

Building CoralSec Copilot was an absolute masterclass in data correlation. Coral eliminated the most painful parts of API integration and allowed me to focus entirely on building a robust, intelligent security product.

A massive thank you to Coral and WeMakeDevs for hosting this hackathon. It challenged me to push my boundaries as a full-stack developer and a security researcher. The voyage was long, the code was complex, but the final plunder was absolutely worth it!