To kick off the new year, CreoWis organized another volume of its internal hackathon, Hatch-and-Hype (HnH) Vol - 2, an initiative built to encourage innovation and hands-on learning across the team.
The hackathon ran from 15th December to 15th January 2026, and this time the central theme was Artificial Intelligence.
The first volume of HnH was an incredible learning experience for me, where I explored backend development and webhook-based integrations. I'm also pleased to share that I was one of the winners of the first HnH hackathon.
This year, instead of starting from scratch, I decided to take that project to the next level and evolve it into a more complete product. My goal was to release at least an MVP (Minimum Viable Product) so that people could try it out, share feedback, and help shape future improvements.
In this blog, I’ll share the complete journey of this project.. from how the idea started, to the architecture and technical decisions, the challenges I faced, the features I built, and what I learned along the way.
If you’re interested in building real-world AI-powered systems that integrate across platforms, this blog is for you. Let’s get started.
How the Idea Took Shape
At CreoWis, Discord is our primary platform for team communication, and most of our development work happens on GitHub. Along with that, we also use tools like Jira, GitLab, and our in-house product Cirrina for project management and internal workflows.
For founders and project managers, constantly switching between so many platforms to track sprint progress, pull requests, issues, assignments, and reminders becomes both time-consuming and mentally exhausting.
Important information gets scattered, and getting a quick, high-level understanding of what’s happening across projects is not always easy.
This friction triggered the core idea: what if project managers and team members could monitor and interact with their projects from a single place, without jumping between multiple tools?
Since the hackathon theme was AI, building a natural language interface powered by an LLM felt like the right approach. Instead of learning new dashboards or commands, users could simply ask questions in plain English.
For the MVP, I deliberately limited the scope to Discord and GitHub. Discord is already where teams collaborate daily, and GitHub is where most engineering activity happens.
Starting with these two platforms made the problem focused and achievable within the hackathon timeline, while keeping the architecture open for future integrations.
The long-term vision is simple: stay inside Discord and still be able to ask questions like:
What PRs are pending?
Which issues are assigned to me?
Why did the last build fail?
Without opening multiple tabs. While the product is still evolving, the system is designed to stay flexible so features can grow based on real usage and feedback.
Architecture of the Product
To support smooth interaction between multiple platforms, the system is designed with clearly separated layers, each responsible for a specific part of the workflow. This separation helps keep the product maintainable and easier to extend in future iterations.
At a high level, the system consists of a landing page, a web dashboard, a backend service, a database, and an LLM layer.
The landing page acts as the entry point, where users can learn about the product and sign in. After authentication, users are redirected to the dashboard, which is mainly used by project admins and team leads to configure integrations, select repositories, and connect the Discord bot to their workspace.
The backend acts as the central coordinator. It exposes REST APIs for the dashboard, listens to Discord bot events, communicates with GitHub APIs and webhooks, and manages synchronization across services. Any action, whether triggered from the dashboard or from Discord… flows through this backend layer.
The database stores persistent application state such as user profiles, linked GitHub and Discord identities, active repositories, and session data. This ensures that system state is never tied to memory and always survives restarts. In practice, this makes the database the single source of truth for the entire product.
Finally, the LLM layer is responsible for converting natural language into structured system actions. Instead of relying on fixed commands, user messages are analyzed to detect intent and then mapped to backend functions, making the interaction feel more conversational and flexible.
Implementation Overview
From a technical perspective, both the web dashboard and the Discord bot communicate with the same backend and database, which helps avoid state mismatches.
The dashboard is built using React and communicates with the backend using REST APIs and Server-Sent Events (SSE) for live updates. The backend is built with Node.js and Express, handling API requests, Discord bot logic, authentication, and GitHub integrations. The bot itself is implemented using Discord.js for message handling and command parsing.
For data storage, PostgreSQL is used along with Prisma as the ORM. Instead of writing raw SQL, all services interact with the database through Prisma models, which provides type safety and keeps schema changes manageable.
Once the database is updated, synchronization events are triggered so that all connected clients can refresh their state. To keep the dashboard in sync with actions happening in Discord, the system uses a hybrid strategy.
When possible, updates are pushed instantly using SSE. If the SSE connection drops due to browser or network issues, the dashboard falls back to polling the backend every few seconds to check for state changes. This ensures that the UI remains consistent even when real-time connections fail.
On the AI side, user messages from Discord are sent to the local LLM, which classifies intent and maps it to specific backend functions. Only when the confidence threshold is high enough does the system proceed with executing actions. Otherwise, the bot responds with safe guidance instead of performing uncertain operations.
Challenges while building this project
One of the earliest challenges was user identity across platforms. Users could interact through Discord or log in via GitHub OAuth on the dashboard, which initially created duplicate user records.
To solve this, I introduced a unified user model where both Discord and GitHub identities are linked to the same account, along with an identity mapping table that allows future platform expansion.
Another major issue was in-memory state management. Early versions of the bot stored user context in memory, while the API relied on database state. This caused mismatches and state loss after restarts. The fix was to move all identity and configuration storage into PostgreSQL and remove memory-based context entirely, forcing every service to read from the same source.
Authentication also became complex due to multiple flows: GitHub OAuth, Discord identity, and dashboard sessions. Centralizing session storage in the database and using shared authentication middleware simplified this and reduced many edge cases.
Real-time synchronization introduced its own reliability challenges. SSE connections can drop silently, and browsers have limitations around headers and reconnect behavior. To avoid stale dashboards, polling was added as a fallback mechanism, ensuring eventual consistency even when real-time updates fail.
Finally, LLM intent detection required careful handling. Natural language is ambiguous, and incorrect classification, especially for write operations can be dangerous. To mitigate this, strict confidence thresholds, deterministic settings, and fallback responses were implemented before executing any critical action.
Features of the Project (Current Capabilities)
At the current MVP stage, the product focuses mainly on read-only actions, allowing users to safely query project information directly inside Discord, where teams already collaborate.
Users can ask for repository information such as open pull requests, open issues, combined views of issues and PRs, CI workflow status, and high-level repository summaries. This helps both developers and project managers quickly understand project health without opening GitHub.
Once a user links their GitHub account, the system also supports personal task tracking, including pull requests waiting for review and issues assigned to the user. This makes it easier to stay on top of responsibilities directly from chat.
Basic setup actions can also be triggered via Discord, such as checking authentication status, setting the active repository for the workspace, and linking GitHub identities.
This reduces dependency on the dashboard for daily usage and keeps most interactions inside a single platform.
Future Scope & Enhancements
While the current MVP focuses mainly on safe read-only actions, the next phase will be about improving stability, expanding features, and moving toward real-world usage.
In the short term, I plan to add more read commands, improve error handling, and host the system in a proper production environment with logging and monitoring.
Once the system is stable, the next milestone will be introducing controlled write actions such as creating issues, assigning tasks, and triggering workflows, with strong validation and confirmation flows.
In the longer term, I plan to integrate more platforms like GitLab, Jira, and internal tools, so teams can manage most of their project workflows from a single conversational interface.
Learnings & Conclusion
This project pushed me to think beyond just building features and focus more on system design, reliability, and real product workflows.
Treating the database as the single source of truth made synchronization much easier, and designing real-time systems with fallback mechanisms proved critical for real-world usage.
Identity and authentication flows also turned out to be something that must be planned early when multiple platforms are involved.
Working with LLM-based intent detection highlighted the importance of strong guardrails before enabling write actions. Setting confidence thresholds and structured validations made the system far more predictable and safe. Overall, this project reinforced the value of building a focused MVP first, validating the core workflow, and then expanding gradually.
A huge thanks to our founders Tapas,Koustav, andNirmal for giving us a platform like Hatch-and-Hype to experiment, learn, and showcase our work publicly.
We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.
This article is crafted by Ajay Yadav, a passionate developer at CreoWis. You can reach out to him on X/Twitter, LinkedIn, and follow his work on GitHub.
