Building an AI-assisted learning platform
for students in Nepal.
Bringing learning material, question search, community discussion, and an AI assistant into one place, with mathematical content in mind throughout.
Find. Study. Ask.
Braimy served students in grades 10–12 in Nepal, bringing learning resources, question search, AI assistance, and community support into one place.
A student could look for an existing explanation, work through a course, ask in the forum, or continue a conversation with Big-B. Mathematics made each of those harder: an equation could arrive as typed notation, formatted editor content, or a photograph, and a system that handled ordinary paragraphs well could still lose the expression or miss the right lesson.
As a Full-stack Developer, I built the initial web application, admin tools, editors, and backend, and contributed to interface design. Other developers later joined and contributed to those areas.
I kept direct responsibility for Big-B and the knowledge-base service, semantic and image search, community real-time features, and infrastructure. Product design, educational material, community development, and the company’s growth depended on other contributors.
From finding material to asking for help.
Product composition · Select to enlarge.
Students could search lessons, courses, and discussions without knowing where content lived, with subject, grade, and other metadata adding context. They could also photograph a question: its text was extracted and used for search.
My contributionI built and managed semantic search and image-to-question search, which used Mathpix OCR and Cloudinary uploads.
Courses organized lessons into chapters, structured around questions and answers. Enrollment, progress tracking, and discovery based on a student’s selected interests sat alongside streaks and points.
My contributionI built the initial courses, progress, personalization, streaks, and points functionality; later development was shared with teammates.
Big-B appeared as a dedicated chat, as AI responses alongside search, and as automatic answers to forum questions. Students could also join community discussions and receive notifications.
My contributionI built and managed the Big-B integration and knowledge-base service, plus forums, notifications, and real-time updates.
Screens come from a historical feature presentation with sample content and marketing framing. They illustrate the product, not response quality or speed, and the phone framing doesn’t imply native mobile work.
Complex expressions didn’t always edit or render reliably, so authors sometimes uploaded equations as images instead.
Students, teachers, and content staff used the editor for equations, images, tables, code, and mixed rich text. I built the Lexical-based editing experience and worked on equation editing, rendering, and compatibility, so an expression stayed understandable when someone else opened the lesson or answer.
Equation authoring became easier, based on my recollection of the workflow. I don’t have a measured reduction in editing time or equation-related failures.
An image could display an expression, but changing it meant replacing the image rather than editing the equation. The lasting lesson: mathematical content needs explicit attention throughout an authoring system, from creating and revising it to saving and reading it.
Search could find ordinary text while ranking generic keyword matches above the lesson containing the relevant equation.
Content mixed natural language with notation in several formats. I worked on a normalized search representation stored alongside the original: the original stays for display, while normalized text and equation-related information serve retrieval, instead of the editor’s presentation markup alone.
Helped prioritize content explicitly about the requested topic.
Added educational context beyond the body text.
Reduced sensitivity to supported notation and formatting differences.
Kept useful matches within explanations and answers, using the database’s text relevance score.
A separate representation is more data to maintain, and custom ranking needs application logic and tuning instead of the database’s default order. In my recollection, technical content became easier to find; I didn’t keep a precision or recall benchmark.
I also built semantic search with Gemini query embeddings and MongoDB Atlas Vector Search over lessons, courses, and forums. Both were part of my search work, but I describe them as distinct pieces rather than one hybrid scoring formula. Photographed questions went through Mathpix OCR, and the extracted text was used for search.
Normalization covered supported representations. It is not a symbolic algebra system that can prove arbitrary equations equivalent.
Big-B needed to answer using relevant educational material. Connecting a model API was only one part of that.
I built and managed both the knowledge-base service and its application integration. Source material came from admin uploads and content collected from the web.
Admin-uploaded and web-collected learning content.
Remove duplicates and split documents into passages.
Store the prepared material in vector storage so relevant passages can be found for a question.
Retrieve the passages relevant to the user’s question.
Supply the retrieved passages to Gemini for answer generation.
Deliver the answer through chat, search, or the forum workflow.
Generating an answer takes longer than retrieving existing content, so it ran outside the immediate action. After a forum question was posted, a background job called the knowledge-base service, saved the response, and used real-time messaging to deliver it. Search could return results first and deliver a queued AI answer separately.
The interface had to distinguish an accepted action from an available answer, and the backend had to connect delayed results to their originating question or user.
Admins could review answers, flag incorrect ones, and exclude them until a corrected answer was provided. That did not mean every generated response was verified before a student saw it, and retrieved context doesn’t guarantee correctness. The benefit was a way to find problematic answers and remove them from use.
Braimy’s description of Big-B as “trained” on a large question dataset referred to using that dataset in the learning system. The work described here is retrieval, not fine-tuning a foundation model.
I built a NestJS backend on Fastify that worked alongside the existing Express API, sharing its MongoDB database and keeping authentication compatible with the legacy application. The two coexisted; it was not a completed replacement of every Express feature.
The legacy application.
One shared MongoDB database.
TypeScript on Fastify, with Mongoose and Typegoose models.
Handled requests, stored AI responses, and connected them to the workflow they came from.
The knowledge-base service handled Big-B’s retrieval and answer generation.
Bull queues for background jobs, and a Socket.IO Redis adapter for distributing real-time messages.
As other developers joined the application, admin tools, and backend, I continued managing deployment, infrastructure, and monitoring. Docker and PM2 ran the backend, with GitHub Actions in the delivery setup. These are implementation choices, not evidence of a particular uptime or concurrency level.
The most useful lesson was to preserve the meaning of educational content as it moved between systems.
Notation had to stay editable and readable. Search had to account for how students expressed their questions. AI needed relevant context and a correction process.
Built the initial web application, admin tools, editors, and backend, then continued developing them with teammates.
The editor supported mathematical notation alongside code, images, tables, and text, with work on equation authoring and rendering.
Students could search, search from a photo, ask questions, and receive AI-assisted responses in chat, search, and the forum.
Admin review gave the team a way to flag problematic answers and exclude them pending correction.
Kept managing Big-B, the knowledge-base service, search, real-time features, and infrastructure as other developers joined.
Platform milestones from a company update during my involvement. They describe reach and content scale, are not independently audited, and are not growth attributable to my work alone.
Treat notation as content.
Retrieve before generating.
Give answers a correction path.
Based on my engineering notes and clarifications, the Braimy backend developer documentation, and supplied historical product images. Public context: Braimy on LinkedIn and Braimy on Facebook. The historical Braimy website is no longer available.
Release and measurement scope. User, lesson, course, and ambassador figures come from a company update and are not independently audited. No retention, academic-performance, AI-accuracy, speed, or revenue figures are claimed. Search and authoring outcomes are described qualitatively, from my recollection.
Engineering boundaries. The NestJS backend worked alongside the Express API rather than replacing all of it. I don’t claim a specific custom editor node or rendering library. Normalized search covered supported notation, not symbolic equivalence, and semantic search and custom ranking are described as distinct work. The backend documentation describes the codebase; it is not a production audit.
Visual evidence. Product images are historical captures and marketing compositions with sample content; crops remove only browser framing and empty space. Phone framing illustrates the product and does not imply native mobile work, which was outside my scope. Figures printed inside the compositions are marketing copy, not claims made here. There are no editor screenshots. My involvement ran from September 2022 to August 2024.
