Building CampusOne: A School Project That Got Out of Hand

The Summary: Most school projects end with a slide deck. CampusOne ended with a custom-built AI study companion that manages files, generates active-recall materials, and runs on an offline-first binary architecture.

make a mock up for a startup project

The assignment was straightforward: design a mockup for a startup. For most, that means a Figma file and some "lorem ipsum." But mockups don't solve problems. Code does.

I decided to see how far I could push a full-stack implementation in the gaps between classes. Thirty hours and a dangerous amount of caffeine later, CampusOne was born. It isn't just an app; it's a statement on how AI can be integrated as a utility rather than just a gimmick.

Core Engineering: The "Action-Oriented" Assistant

Most AI study tools are "wrappers"—they just send a prompt to ChatGPT and show you the text. CampusOne uses Function Calling (Tool Use) to give the AI agency over the application's infrastructure.

The AI "Remote Control"

Instead of just answering questions, the CampusOne assistant has access to a suite of internal tools:

• Custom Restricted Search: To prevent hallucinations, I limited the AI's web access to curated nodes like Semantic Scholar, Wikidata, and Wikipedia.
• Universal Reader: A parsing engine that converts .pdf, .docx, .pptx, and .html into a clean schema the LLM can reason about.
• Direct Mutation: The AI can actually write to the database. If you tell the agent, "I have a test on Friday, make me a quiz from my lecture notes," it:
  1. Reads the file.
  2. Generates quizzes, flashcards, summaries, callender deadlines/events and tasks.
  3. Saves it to your account.

The Technical Deep-Dive

1. Custom compressed file formats: .qone and .fone

I wanted CampusOne to feel like a "real" productivity aplication (think Microsoft 365 or Adobe), not just a website. This led to the creation of custom compressed file formats.

Why not just use a database?

• Portability: Students should own their data. You can download a .qone (Quiz One) file and move it to another device.
• Performance: I designed a Custom File Header. This acts as metadata—the app can "peek" at the file to see the title, question count, and a thumbnail without decompressing the entire study deck.
• Offline-First: These formats are the foundation for a future desktop app where data persistence shouldn't rely on a stable Wi-Fi connection.

2. The LLM Pivot: Gemini to Groq (Llama 3)

Architecture is about adapting to constraints. I initially built the system on **Gemini 2.5 & 3 **. It was brilliant at logic and had a massive context window. However, the 20-request rate limit became a brick wall during high-intensity development.

The Solution: I pivoted to Groq's Llama 3 implementation.

• The Pro: Sub-second latency. The AI felt "local."
• The Con: Llama's function calling is more temperamental than Gemini's. I had to rewrite the system prompts to be significantly more rigid, ensuring the model didn't "hallucinate" tool arguments.

3. Intentional exclusions: No Vector DB, No MCP

As an engineer, knowing what not to build is as important as knowing what to build.

• No Vector Database (RAG): While popular, adding vector database would have introduced monthly costs. By optimizing multi-keyword searches, I achieved a "good enough" accuracy for student-sized datasets without the cost overhead.
• No MCP (Model Context Protocol): I've used MCP before, but with the close deadline, the setup and configuration would have eaten 20% of my dev time. I prioritized the User Experience over Protocol Purity.

The Workflow: 10x Development with "Antigravity"

I didn't write every line of this code manually. I used Gemini Antigravity as a high-level coding partner.

This wasn't "copy-pasting from ChatGPT." It was an architectural loop:

1. Define the Goal: I’d draft the goal and the technical requirements or guide.
2. The Planning Phase: Antigravity would propose a plan.
3. The Review Phase: I’d review the plan and make sure its in line with the goal and the technical requirements i envision.
4. The Execution: Antigravity handled the implementation of the plan.
5. The Testing Phase: I’d test the implementation.

This allowed me to build multipe features at the same time sinds i more focused on the architectur than manual implementations.

To keep the code clean i gave it a architectural pattern and coding principles.

Lessons Learned

This project taught me that the gap between a "student project" and a "product" is purely a matter of ownership.

• Design Debt: Because I prioritized the "engine" (files system ,file logic and ai), the visual layer is functional but lacks a "signature" style. If i could redo this project I’d invest in a custom Tailwind theme from day one and maybe a component libary like shadcn.
• Tool Agency is the Future: Chatting is boring. Building systems where the AI manages your calendar and files is where the real value lies.

CampusOne started as a mockup assignment. It ended as a fully functional proof-of-concept for the future of AI-integrated education.

A Note: We've only scratched the surface here. Explaining every technical decision, architectural pattern, and implementation detail in full depth would require a blog post roughly 20x longer than this one.

Stack: Next.js, Supabase, Groq/Llama 3, Tailwind, Custom Binary Protocols. Total Dev Time: ~30 Hours.