StudyBridge

Project StudyBridge: Democratizing Socratic Tutoring via WhatsApp

What Inspired Us

In many regions, preparing for critical standardized exams requires personalized guidance that is simply out of reach due to high student-to-teacher ratios and expensive tutoring fees. However, almost every student has access to WhatsApp.

We were inspired to bridge this gap by bringing elite, personalized educational tools to the platform students already use daily. We didn't want to build a bot that simply feeds students the answers that defeats the purpose of learning. Instead, StudyBridge was conceived as a Socratic tutor: an AI that asks guiding questions, identifies knowledge gaps, and helps students arrive at the answers themselves.

How We Planned & Built It

StudyBridge was a heavily cross-functional effort that relied just as much on product strategy as it did on backend engineering.

Before a single line of code was written, our Product Manager established the strategic foundation for the platform. By developing a comprehensive product brief, mapping the student user journey, and designing the final pitch deck, the product vision remained focused on the educational experience rather than the underlying technology alone. This deliberate product scoping ensured that every feature we built directly contributed to the Socratic learning loop.

With the roadmap defined, we engineered a seamless pipeline between messaging infrastructure and large language models. The core application runs on a Node.js and Express backend, with the Meta WhatsApp Cloud API handling real-time message ingestion and delivery. When a student sends a message, the webhook validates the incoming payload, extracts the message content and sender ID, and passes the request into the reasoning pipeline.

The reasoning engine is powered by a large language model guided by strict Socratic system prompts. Rather than providing direct answers immediately, the model is instructed to guide students through questions, hints, and incremental explanations that encourage genuine understanding.

To manage conversation history efficiently without unnecessarily expanding the model’s context window, we implemented custom state-handling logic to prioritize the most relevant parts of the conversation. Recent message turns receive greater importance, while older and less relevant context is gradually deprioritized. This allows StudyBridge to maintain conversational continuity while optimizing latency, token usage, and API costs.

Conceptually, the relevance of previous conversation turns can be represented using a decay function:

W(t) = f(t)

where W(t) represents the relevance weight assigned to a message based on its distance from the current conversation turn. This ensures that immediate context is prioritized while older, less critical history is gradually given less influence.

Challenges We Faced

The most significant technical hurdle we faced was the impedance mismatch between messaging webhooks and AI inference latency.

Meta’s WhatsApp Cloud API expects a timely acknowledgment after receiving a webhook payload. However, parsing a student’s message, passing it through the LLM for Socratic reasoning, and generating a pedagogically appropriate response can take several seconds.

Initially, our webhook handlers were timing out. This caused Meta to retry payloads, which resulted in duplicate bot responses being sent to students. To solve this, we fundamentally restructured the architecture around asynchronous processing.

We decoupled the message ingestion layer from the AI processing layer. The webhook now validates the incoming payload and immediately returns an acknowledgment to Meta. The student’s message is then processed asynchronously in the background. Once the LLM completes its reasoning and generates a response, the system makes an outbound REST API call to dispatch the reply back to the student through WhatsApp.

This architectural change eliminated webhook timeouts and prevented duplicate responses while allowing the AI reasoning pipeline to operate independently of Meta’s webhook response requirements.

We also faced challenges while configuring the Meta Developer Console, particularly around temporary access tokens, webhook verification challenges, and the initial sandbox limitations. Understanding these requirements required extensive documentation review and careful configuration of our development environment to ensure that testing remained controlled and secure.

What We Learned

Building StudyBridge pushed our cross-functional skills to the next level.

On the product side, we learned the immense value of having a dedicated product strategy. Having a clear product brief and pitch deck managed the scope during tight time constraints and successfully translated complex backend guardrails into a compelling user story.

On the engineering side, it meant learning how to effectively manage asynchronous race conditions in Node.js and architecting systems resilient to latency. Furthermore, we gained deep practical experience in prompt engineering specifically, constraining a generative model so that it acts strictly as an educational facilitator rather than an answer-generator.

Ultimately, this project reinforced our passion for building impactful products: taking powerful, complex cloud technologies and packaging them into an interface as simple and accessible as a chat app.

What’s Next

•Broader subject coverage: Expand syllabus coverage and few-shot examples across more WAEC/JAMB subjects beyond our initial demo set.

•Parent visibility: Add an opt-in parent/guardian digest view alongside the student’s own.

•Regional expansion: Extend the same tutoring pattern to other West African exam systems (e.g. WASSCE, KCSE) that share the same access gap.

•Cost efficiency: Batch and cache common problem types to keep the product affordable to run at scale.

Ai Disclosure

StudyBridge’s core product functionality is built directly on Codex and GPT-5.6 this is the required sponsor technology, not an optional add-on, and it powers three distinct functions:

(1) vision-based classification of photographed homework problems into subject/topic/transcribed text.

(2) multi-turn Socratic dialogue generation constrained by a custom system prompt.

(3) weekly digest summarization from a student’s topic-performance history.

All product decisions, prompt design, architecture choices, and testing were done by the team.