DEV Community: Siva Teja

CrisisLens: Compressing Disaster Scenes into 200-Byte Emergency Payloads with Gemma 4

Siva Teja — Sun, 24 May 2026 17:45:17 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

A while back I was watching a documentary about disaster response teams during a major earthquake. What struck me wasn't only the destruction — it was also the communication breakdown. Cell networks were gone. And while voice radios were still working, they weren't enough.

Here's the thing about voice radio in a large-scale disaster: it works, until it doesn't. Twenty field teams radioing in simultaneously saturate the channel. Critical details get lost — wrong street names, garbled injury counts, conflicting reports about the same location. Every message requires a human on the other end to listen, interpret, and manually log what was said. And none of it can be automatically parsed, prioritized, or routed to the right team. A coordinator drowning in voice traffic can't act fast enough.

There's also a harder problem: some of the most capable mesh networks used in disaster response — LoRa and Meshtastic — are data-only. They don't carry voice at all. They exist specifically to move small packets of structured data across long distances with minimal power. They're incredibly robust in disaster conditions. But they cap at around 228 bytes per packet. You can't send an image over them. You can barely send a sentence.

That's where the real gap is. A responder standing in front of a collapsed building has critical visual information — how many people, what type of structural failure, what equipment is needed — that voice can't convey accurately under stress, and that existing data networks physically cannot carry as an image.

That planted a question I couldn't shake: what if a responder could photograph what they're seeing, and have AI distill it into something small enough to actually transmit?

CrisisLens is my answer to that.

It runs entirely on the phone in your pocket — no servers, no internet, no infrastructure of any kind. A responder photographs what they're facing: a blocked road, a structural collapse, an injured person. CrisisLens reads the device's live GPS coordinates, feeds the image to Gemma 4 running on-device, and distills everything into a structured JSON payload of 200 bytes or less — ready to broadcast over any LoRa or Bluetooth mesh network available.

The result looks like this:

{"loc":"12.8406,77.6784","type":"flood","sev":"crit","inj":2,"desc":"Road submerged 3ft","act":"avoid south entry","conf":"high"}

107 bytes. Precise GPS coordinates, incident type, severity, injury count, a scene description, a recommended action, and the model's own confidence in what it saw. Ready to travel over infrastructure that was built for the 1990s.

Stack: Gemma 4 E2B · LiteRT-LM · Kotlin · Jetpack Compose · Fully on-device · No internet required

But Why Can't a Human Just Do This?

A trained responder can fill a structured form manually — protocols like METHANE exist precisely for this reason. So it's a fair question.

The answer isn't that humans can't. It's that humans under acute stress don't. Standing in front of a burning building with people screaming is cognitively brutal. Fields get skipped. Street names get garbled. Injury counts come in as "maybe three or four." And structured reporting protocols only work if every responder has been trained on them.

CrisisLens exists for everyone else — the volunteer, the civilian, the off-duty nurse who happened to be there first. One photo. No training required. Consistent, parseable output every time. And the camera sees what stress makes you miss: a human might report one visible casualty; the model looking at the photo might catch two more people partially obscured in the debris.

There's also something the model does that no voice protocol can: it produces machine-readable output. A coordinator receiving 20 structured payloads can sort by severity in a spreadsheet. A coordinator receiving 20 voice messages is just drowning.

Demo

Video walkthrough →

Code

GitHub Repo →

How I Used Gemma 4

Why E2B

The model choice here wasn't a preference — it was a hard constraint that made everything else follow logically.

CrisisLens has to work when the internet doesn't. That eliminates every cloud API. The model has to run on the device a responder is already carrying. That eliminates every model too large for a phone. And it has to work for any responder, not just the ones with a $1200 flagship device.

The Gemma 4 E2B — a 2B effective parameter model built specifically for ultra-mobile and edge deployment — is the only model in the Gemma 4 family that satisfies all three constraints simultaneously. The 31B Dense model requires server-grade hardware. The E4B needs 8GB+ RAM, limiting it to flagship phones. The E2B runs on mid-range Android devices with 4GB+ RAM, and even on hardware as lean as a Raspberry Pi 5.

A rescue worker shouldn't need a $1200 phone to use this tool. E2B makes that true.

And crucially — the vision task here isn't complex reasoning. It's constrained categorization: classify a scene into one of six incident types, assign a severity level, count visible casualties, write a 60-character description. A well-prompted 2B model with a rigid schema handles this reliably. The constraint is the point — by removing open-ended generation and forcing the model into a fixed vocabulary, accuracy becomes a function of prompt engineering, not raw parameter count.

The model isn't a chatbot here. It's a translator — converting heavy visual data into lightweight, actionable intelligence that can physically travel over primitive radio networks.

The Problems I Actually Had to Solve

Building this exposed four problems that were harder than they looked.

Problem 1: Location Was Useless When Generated by the Model

The first version of CrisisLens asked the model to describe the location from the image. The outputs were accurate but useless in context: "urban ruins," "flooded street," "collapsed structure." In a disaster zone, everywhere looks like that. No responder can act on "urban ruins."

The fix was to remove location from the model's responsibilities entirely. The app reads live GPS coordinates from the device at the moment of capture and injects them directly into the payload — the model never touches the loc field. Coordinates like 12.8406,77.6784 are 15 characters, globally unambiguous, and work even when the entire scene looks like rubble. If GPS is unavailable after 10 seconds, the app falls back to "loc":"GPS unavailable" and still processes the image — the analysis is never blocked waiting for a signal.

Problem 2: Getting Gemma 4 to Output Consistent JSON

Gemma 4 is a generative model — it wants to explain, elaborate, and hedge. Ask it to analyze a disaster photo and it might produce a well-written paragraph. Ask it for JSON and it might return JSON wrapped in markdown code fences, or JSON preceded by a sentence, or subtly malformed JSON that breaks the parser downstream.

I solved this in two layers. The system prompt became a formal specification — not "return JSON" but a complete field-by-field schema with types, allowed values, character budgets, and an embedded example of correct output. Second, I added a validation-and-retry loop: if the response doesn't parse cleanly, the app retries up to three times with an increasingly constrained prompt before returning a fallback error state. In practice, the retry loop almost never fires — the schema prompt alone reduced malformed outputs to near zero.

Problem 3: Enforcing 200 Bytes Without Corrupting the Payload

Even with a tight schema prompt, the model occasionally produces valid JSON that runs slightly over 200 bytes. Naive truncation at byte 200 breaks the JSON structure entirely — which is worse than being slightly over limit.

I stopped treating this as a model problem and moved it to post-processing. The schema defines a hard character budget for every field. Critical fields — type, sev, inj, conf — are constrained to enums and integers, so they can never grow. Only desc and act are variable-length. If the total payload exceeds 200 bytes after generation, the app trims desc first, then act, always cutting at word boundaries to keep the text readable. The JSON structure is never touched. The result is always valid, always parseable, always under the limit.

Problem 4: Prompt Engineering for Disaster Scenarios

A generic prompt produces generic output. The first useful breakthrough came from realizing the model needed a closed vocabulary, not open-ended instructions.

Rather than asking Gemma 4 to describe what it sees freely, I gave it a constrained set of incident types (flood, fire, injury, blockage, structural, hazmat) and severity levels (low, med, high, crit). This forced the model to map visual input onto a vocabulary that receiving systems can act on directly — no interpretation needed on the other end. The conf field came from the same principle: if the model is uncertain about what it's seeing, the payload should say so explicitly, so responders can decide whether to verify before acting.

The difference between an open prompt and a constrained one was dramatic. Open prompts produced outputs that were accurate but unpredictable in structure. Constrained prompts produced outputs that were slightly less nuanced but completely reliable — and in an emergency, reliability beats nuance.

The Ultimate Weekend Planner

Siva Teja — Sun, 08 Jun 2025 10:38:11 +0000

This is a submission for the Runner H "AI Agent Prompting" Challenge

What I Built

The "Weekend Navigator": Your Personal AI Concierge for Perfect Plans

I built an autonomous AI agent using Runner H that eliminates the stress and endless scrolling associated with planning a weekend. The "Weekend Navigator" solves the common problem of "decision fatigue" by taking a single, simple prompt—like a city and a general vibe (e.g., "family-friendly")—and transforms it into a fully-fledged, shareable itinerary. It intelligently sources and vets local events, finds highly-rated nearby restaurants, and compiles everything into a clean, collaborative document, freeing up users to spend less time planning and more time enjoying their time off.

Demo

It will output a Google doc like this

How I Used Runner H

Runner H agent orchestrates a four-step workflow to act as a personal concierge, blending web research with practical, real-world outputs.

Event Discovery & Vetting (Web Search & RAG)
Runner H kicks off the process by scouring the web for relevant events.

Automated Web Search: It performs targeted searches on local news sites, event listing platforms (like Eventbrite), and city guides to find events matching the user's criteria (e.g., "family-friendly events in Austin this weekend").
Data Synthesis (Google Docs & RAG): Using Retrieval Augmented Generation (RAG), the agent doesn't just copy links. It reads the source pages and extracts key details—event description, location, hours, ticket prices, and a snippet from a recent review—to build a rich summary for each event within a Google Doc.
Culinary Pairing (Google Maps & Chain-of-Thought Prompting)
Once events are found, the agent finds great places to eat nearby.

Geospatial Search (Google Maps): For each event's location, Runner H queries Google Maps for nearby restaurants.
Intelligent Filtering (Google Sheets & CoT): The agent uses Chain-of-Thought (CoT) Prompting to reason through the selection process. It logs potential restaurants in a temporary Google Sheet and follows a logical chain: "First, I will filter for restaurants with a rating of 4.3 stars or higher. Second, I will filter for those with a '$$' price range or less. From the remaining list, I will select the top three based on the number of reviews." This ensures high-quality, relevant suggestions.
Itinerary Assembly & Formatting (Google Docs & Meta Prompting)
With all the data gathered, the agent creates the final deliverable.

Document Generation (Google Docs): It compiles the vetted events and their paired restaurant options into a single, beautifully formatted Google Doc titled Weekend Plans - [City] [Date].
Collaboration & Action (Gmail & Active-Prompt)
The final step is to share the plan and make it actionable.

Automated Sharing (Gmail): Runner H drafts and sends an email containing a link to the Google Doc to the specified contact (e.g., a spouse or friend).
User-in-the-Loop (Active-Prompt): Before finishing, the agent uses Active-Prompt to offer a next step: "The Weekend Navigator plan has been created and shared. Based on the itinerary, would you like me to add a placeholder event to your Google Calendar for Saturday afternoon to block off the time?" This makes the agent interactive and even more helpful.

Use Case & Impact

Who Benefits: Busy parents, couples, groups of friends, and anyone suffering from planning burnout.

Impact: This agent saves hours of research and negotiation each week, reduces decision fatigue, and encourages people to discover new things in their city, ultimately fostering better work-life balance and more quality social time. It transforms a tedious task into a delightful, automated experience.

Full Prompt


    Runner H, execute the "Weekend Navigator" workflow. Your goal is 
to create a shareable weekend plan.

1. Event Discovery: Using web search, find 3 family-friendly events 
happening in Austin, TX this coming weekend. For each, use RAG to 
extract: a description, location, ticket price, and one recent review 

2. Restaurant Pairing: For each event, use Google Maps and Chain-of-
Thought logic to find 3 nearby restaurants that are highly-rated (4.3 
stars+) and moderately priced.

3. Itinerary Assembly: Compile all this information into a new Google 
Doc named Weekend Plans - Austin [Current Date]. Use Meta Prompting 
to create a friendly introductory paragraph. The format for each 
event should be: Event Name, Details, and then the 3 restaurant 
suggestions.

4. Sharing: Draft and send an email to [email@example.com] with 
the subject "Weekend Plans!" and a link to the Google Doc.

5. Confirmation: Use Active-Prompt to ask if I want to add a 
placeholder event to my Google Calendar for Saturday at 2 PM.

Code Archeologist: AI-Powered Git Repository Analysis with PostgreSQL

Siva Teja — Mon, 11 Nov 2024 07:11:55 +0000

This is a submission for the Open Source AI Challenge with pgai and Ollama

What I Built

Code Archeologist is an AI-powered application that analyzes Git repository histories to identify patterns in code evolution. It creates a "genetic tree" of your code's ancestry, provides refactoring suggestions, generates a codebase heatmap, commit activity timeline, contributor statistics, dependency graph, file change frequency, and integrates with issue tracking. Leveraging PostgreSQL extensions pgvector and pgvectorscale, along with Ollama for text embeddings, the application performs high-performance similarity searches and advanced AI-driven insights without the need for external vector databases.

Demo

MS-Teja / code-archeologist

Code Archeologist analyzes your Git repository history to identify patterns in code evolution.

Code Archeologist

Code Archeologist analyzes your Git repository history to identify patterns in code evolution. It creates a "genetic tree" of your code's ancestry, provides refactoring suggestions, generates a codebase heatmap, commit activity timeline, contributor statistics, dependency graph, file change frequency, and integrates with issue tracking.

Features

Genetic Tree: Visualize the ancestry of your codebase.
Refactoring Suggestions: Receive actionable recommendations to improve your code.
Codebase Heatmap: Identify hotspots and areas with high activity.
Commit Activity Timeline: Track commit patterns over time.
Contributor Statistics: Analyze contributions from different team members.
Dependency Graph: Visualize project dependencies.
File Change Frequency: Monitor how often files are modified.
Issue Integration: Link code changes with issue tracking systems.
Semantic Search in Commits: Find similar commits based on semantic meaning using vector embeddings.
Question Answering: Ask questions about your codebase and receive AI-generated answers.
Summarization: Get concise summaries of commit messages.

Features with AI Integration

Vector Embeddings:…

View on GitHub

How the Project Works

Code Archeologist utilizes a combination of PostgreSQL extensions and open-source AI models to deliver a seamless analysis experience:

Data Ingestion
- The application connects to a GitHub repository and fetches commit history, contributors, file changes, issues, and dependencies using the GitHub API.
Embedding Generation
- Commit messages and relevant text data are processed using Ollama to generate 768-dimensional vector embeddings.
- These embeddings are stored in PostgreSQL using the pgvector extension, which allows efficient storage and retrieval of high-dimensional vectors.
Indexing and Similarity Search
- The pgvectorscale extension is employed to create a diskann index on the embedding column, enabling fast approximate nearest neighbor searches.
- This setup allows the application to perform rapid similarity searches, facilitating features like semantic commit search and question answering.
AI-Driven Features
- Refactoring Suggestions: Analyzes code evolution to recommend potential improvements.
- Summarization: Generates concise summaries of commit messages using AI models.
- Question Answering: Allows users to ask natural language questions about the codebase and receive AI-generated answers based on the commit history.
Visualization

The frontend built with Vue.js displays various visualizations such as genetic trees, heatmaps, timelines, and dependency graphs, providing users with insightful views of their codebase.

Performance and Scalability

By leveraging PostgreSQL with pgvector and pgvectorscale, the application ensures efficient storage, rapid querying, and scalability to handle large datasets without relying on external vector databases.

How the Backend Works

The backend of Code Archeologist is built using Node.js and Express.js, interfacing with a PostgreSQL database enhanced with AI-specific extensions. Here’s an overview of its functionality:

Session Management
- Utilizes express-session to handle user sessions, ensuring secure and persistent interactions.
Database Initialization
- Connects to PostgreSQL database.
- Initializes the database schema, creating tables like code_analysis and commit_embeddings.
- Ensures necessary extensions (pgvector, pgvectorscale) are installed for vector operations and AI functionalities.
Data Processing
- Fetching Data: Retrieves commits, contributors, issues, and dependencies from GitHub repositories.
- Embedding Generation: Uses Ollama to generate vector embeddings for commit messages, storing them with pgvector for efficient similarity searches.
- Indexing: Implements pgvectorscale with diskann indexing to optimize search performance.
AI Integration
- OpenAI & Ollama: Integrates OpenAI for generating completions and Ollama for creating text embeddings, facilitating features like refactoring suggestions and question answering.
Error Handling
- Implements robust error handling across all endpoints, ensuring meaningful responses and logging errors for debugging.

Technologies and Tools Used

Frontend:
- Vue.js: JavaScript framework for building user interfaces.
- Axios: Promise-based HTTP client for making API requests.
- Cytoscape.js: Library for graph theory (network) data visualization.
- Chart.js: Simple yet flexible JavaScript charting library.
- Highlight.js: Syntax highlighting for code snippets.
- QTip2: Advanced tooltips for enhanced user interactions.
- D3.js: Data-driven documents for creating dynamic visualizations.
- DOMPurify: Sanitizes HTML to prevent XSS attacks.
Backend:
- Node.js: Server-side JavaScript runtime.
- Express.js: Web framework for building API endpoints.
- PostgreSQL: Relational database system.
- vector: PostgreSQL extension for storing vector embeddings.
- vectorscale: Extension for optimized vector similarity searches.
- Octokit: GitHub API client for fetching repository data.
- dotenv: Loads environment variables from a .env file.
- express-session: Manages user sessions.
- Winston: Logging library for capturing application logs.
- Cors: Enables Cross-Origin Resource Sharing.
AI & Machine Learning:
- Ollama: Generates text embeddings using open-source models.
- OpenAI SDK: Facilitates AI-driven features like completions and question answering.
APIs
- GitHub API: Accesses repository information.
- OpenAI API: For generating summaries and answering questions.

Final Thoughts

Building Code Archeologist was a great experience that showed me just how powerful combining PostgreSQL extensions with AI tools can be. Using pgvector, pgvectorscale, and Ollama together made it possible to create a strong, scalable app that can handle complex searches and give useful insights. This project really boosted my appreciation for using open-source tools to build smart AI applications.

Thanks for considering my submission!

Haiku Harmony: Crafting Poetry in the Cloud with Pinata

Siva Teja — Sun, 13 Oct 2024 16:57:06 +0000

This is a submission for the The Pinata Challenge

What I Built

I created Haiku Harmony, a web application that brings the art of haiku into the digital age. This platform allows users to create, share, and appreciate haikus, each accompanied by an image. Key features include:

A user-friendly interface for composing and submitting haikus
User profiles showcasing each author's haiku collection
A search feature allowing users to find haikus by tags
A "Hall of Fame" section highlighting the most popular haikus

What makes Haiku Harmony unique is its use of Pinata's decentralized storage solution. Each haiku and its associated image are stored on IPFS through Pinata, eliminating the need for a traditional database. This approach not only simplified the development process but also made me realize how easy it is to create a scalable application without the usual database hassles.

I developed this during my exams so excuse me for any bugs. I tested this as much as I could, so I hope you won't find any. But due to time constraints I haven't tested it as much as I would have liked.

Demo

You can see it in action at https://haikuharmony.netlify.app/

My Code

The source code is available on GitHub:

MS-Teja / HaikuHarmony

Haiku Harmony is a web application that celebrates the art of haiku by providing a platform for users to create, share, and appreciate these brief poetic gems.

Haiku Harmony

Haiku Harmony is a web application that celebrates the art of haiku by providing a platform for users to create, share, and appreciate these brief poetic gems. Built with Vue.js and leveraging Pinata's Files API, this project combines the simplicity of haiku with the power of decentralized storage.

Live Demo

Visit Haiku Harmony: Haiku Harmony

Features

Create and share haikus with associated images
Browse a feed of user-submitted haikus
Like and interact with others' creations
Search haikus by tags
User profiles showcasing individual collections
A "Hall of Fame" featuring top-rated haikus

Technology Stack

Frontend: Vue.js
Backend: Netlify Functions
Storage: IPFS via Pinata SDK
Authentication & Likes: Firebase
Hosting: Netlify

Thank you for providing that information. I'll update the README to reflect the correct environment variables and development process. Here's the revised section for local development:

Local Development

To run this project locally:

Clone the repository

git clone https://github.com/MS-Teja/HaikuHarmony.git

…

View on GitHub

My Journey

When I first encountered the Pinata Challenge prompt to "use Pinata" in a project, I had no idea how transformative this experience would be. As an 18-year-old student from India, I decided to create Haiku Harmony, a web application for sharing and appreciating haikus. What I discovered along the way was a revelation in web development simplicity.

The Pinata Revelation

Integrating Pinata into Haiku Harmony opened my eyes to how easy it can be to create a scalable application without the complexities of traditional databases. Here's what I learned:

Simplified Storage: Instead of setting up and managing a database, I could store haikus and images directly on IPFS through Pinata with just a few lines of code.
Effortless Retrieval: Fetching content became as simple as making API calls to Pinata's gateway. No complex queries or database management required.
Built-in Scalability: I realized that as Haiku Harmony grows, I won't need to worry about database scaling. Pinata's decentralized storage can handle increased load without additional configuration.
Reduced Backend Complexity: Without a traditional database, my backend became significantly simpler, focusing mainly on interacting with Pinata's API.

The Implementation

Using Pinata was surprisingly straightforward. For example, uploading a haiku was as simple as:

const result = await pinata.pinJSONToIPFS(haikuData, pinataOptions);

And retrieving it was equally uncomplicated:

const response = await axios.get(`https://${pinataGateway}/ipfs/${id}`);

This simplicity allowed me to focus more on creating features and improving user experience, rather than getting bogged down in database management.

Reflections

Developing Haiku Harmony during my exams was challenging, but Pinata's ease of use made it possible. I was amazed at how I could create a potentially scalable application without the need for complex database setups or management.

This experience has shown me that for content-centric applications, solutions like Pinata can offer a compelling alternative to traditional databases, simplifying both development and scaling processes significantly.

Conclusion

The ease of using Pinata has been a game-changer in my understanding of web development. It's shown me that creating scalable applications doesn't always require complex infrastructure.

I'm eager to hear thoughts and feedback from the community. If you think I did something wrong or have suggestions to improve Haiku Harmony, I'd be grateful for your input. Your insights will help me grow as a developer and enhance this project further.

This challenge has not only resulted in a production level application but also opened my eyes to new possibilities in web development. It's exciting to think about how tools like Pinata can shape the future of content-driven applications.

Cosmic Web: A Student's Journey Through Space and Code

Siva Teja — Thu, 12 Sep 2024 14:21:35 +0000

Frontend Challenge v24.09.04 Submission: Explore the Cosmos

This is a submission for Frontend Challenge v24.09.04, Glam Up My Markup: Space

What I Built

I created "Explore the Cosmos," an immersive and educational landing page that takes visitors on a journey through our solar system. The goal was to design an engaging, visually appealing, and informative website that sparks curiosity about space and celestial bodies.

Key features of the landing page include:

A captivating header with a space background and animated scroll arrow
Comprehensive overview of our solar system
Detailed information about each planet, including key facts and images
Sections dedicated to notable moons and other celestial objects
Interactive elements that link to NASA's science pages for further exploration

The design aims to balance aesthetics with educational content, creating an experience that's both visually stunning and intellectually stimulating.

Demo

[Github Repository]

You can view the live demo of the project at:

explorecosmos.web.app

Journey

As a student, this is my first time participating in an event like this, and I'm excited to share my journey! Creating "Explore the Cosmos" was not only an exciting adventure that allowed me to combine my passion for web development with my fascination for space, but also a significant learning experience for me.

First-Time Experience: Being my first time entering such an event, I was both nervous and thrilled. This challenge pushed me out of my comfort zone and encouraged me to apply my skills in a real-world scenario.
Planning and Research: I started by researching space-related content and deciding on the key elements to include. This helped me structure the information in a logical and engaging way.
Design: I chose a dark color scheme to emulate the vastness of space, using stark whites and subtle animations to create visual interest. The font choices (Space Grotesk and Space Mono) were selected to enhance the space theme. This was my first time focusing so intensely on design aspects, and it taught me a lot about user experience and visual communication.
Development:
- HTML: I focused on semantic markup to ensure accessibility and SEO-friendliness. This project helped me understand the importance of well-structured HTML.
- CSS: I used modern CSS techniques like Grid and Flexbox for layout. The animated background and scroll arrow were challenging but rewarding to implement.
- JavaScript: I added interactivity by making each celestial body clickable, linking to NASA's science pages for more in-depth information.
Challenges:
- Balancing visual appeal with performance, especially with the background animation
- Ensuring responsiveness across different screen sizes while maintaining the visual integrity of planet images and layouts
- As a student, time management was a challenge, balancing this project with my other academic responsibilities
Learnings:
- Improved my skills in creating immersive web experiences
- Gained deeper understanding of CSS animations and their impact on performance
- Learned more about our solar system while curating the content
- Developed project management skills and learned how to work under the constraints of a challenge
- Gained confidence in my abilities as a web developer

I'm particularly proud of the seamless integration of educational content with an engaging design. The way each planet card transforms on hover, inviting users to explore further, is a detail I really enjoy. As a student, seeing my vision come to life was incredibly rewarding and has motivated me to continue exploring web development.

Next Steps

This experience has ignited a passion for web development and space education. Moving forward, I'd love to expand this project by:

Adding more interactive elements, perhaps a 3D model of the solar system
Implementing a quiz feature to test users' knowledge about space
Creating individual pages for each celestial body with more detailed information

Participating in this challenge has been a fantastic opportunity to combine creativity with technical skills, and I'm excited to continue refining and expanding my project. As a student, this experience has been invaluable, providing me with practical skills, boosting my confidence, and giving me a taste of real-world web development challenges. I'm looking forward to participating in more events like this in the future!

See you later.
Thank You!