Mita School Student Innovation Lab
Mita School Tools / Submission Guide

Prepare your project properly before you submit.

This guide explains exactly what to send, how to package your source code, how to handle passwords and API keys, and what happens after the Student Innovation Lab receives your project.

Short version: GitHub is preferred. ZIP is accepted. Never submit real passwords, private API keys or a real .env file. Use placeholders such as .env.example.

1. The submission flow

Build → Test → Prepare source → Submit → Review → Approve → Deploy → Publish

Your project does not appear publicly just because you submit it. It is reviewed first. Only a project marked Published with a valid live URL appears automatically on the Mita School Tools homepage.

2. GitHub is the preferred way to submit source code

If possible, create a GitHub repository and submit the repository URL. This gives you a more professional development workflow and makes future updates easier.

Your repository should contain the project source, a useful README, and any example configuration files needed to understand how the project works.

3. If you upload a ZIP, keep it clean

A simple frontend project could look like this:

qr-code-scanner/ ├── index.html ├── css/ ├── js/ ├── assets/ ├── README.md └── .env.example ← only if configuration is needed

A backend project might look like this:

project-name/ ├── frontend/ ├── backend/ ├── database/ ├── README.md ├── requirements.txt / package.json └── .env.example

Do not include unnecessary generated folders

Do not upload folders such as node_modules. They make the ZIP unnecessarily large and can be recreated from package.json.

4. Why you must not submit a real .env file

A real .env file often contains credentials that can unlock databases, email accounts, paid APIs, payment systems or other private services. Those values should never be passed around in a project ZIP or committed to GitHub.

Do not submit this:
OPENAI_API_KEY=sk-real-secret-key DB_PASSWORD=myRealDatabasePassword SMTP_PASSWORD=myRealEmailPassword PAYMENT_SECRET_KEY=live_secret_value

Instead, create an example configuration file that contains variable names and placeholders:

This is the correct approach:
# .env.example OPENAI_API_KEY=YOUR_OPENAI_API_KEY DB_PASSWORD=YOUR_DATABASE_PASSWORD SMTP_PASSWORD=YOUR_SMTP_PASSWORD PAYMENT_SECRET_KEY=YOUR_PAYMENT_SECRET_KEY

The deployment administrator creates the real .env privately on the server. Your application reads those server-side values when it runs.

Other secret files to remove

  • Private SSH keys such as id_rsa or id_dsa.
  • Service-account credential files and private credential JSON files.
  • Real database backups containing private customer or student information.
  • Passwords pasted directly inside PHP, JavaScript, Python or configuration files.

5. Projects using APIs, databases or external services

Tell the review team what service is required and how it should be configured. Do not paste the secret itself into the submission form.

For example:

Uses OpenAI API. Required environment variable: OPENAI_API_KEY Backend: PHP Database: MySQL Database schema: database/schema.sql Setup steps are in README.md

If a frontend service uses a browser-visible configuration value, explain what it is and what restrictions or security rules should be applied during deployment.

6. Write a useful README

Your README should answer these questions:

  1. What does the project do?
  2. What technologies does it use?
  3. How do we install or run it?
  4. Does it require a database?
  5. Does it require an external API?
  6. Which environment variables are required?
  7. Are there any special deployment steps?

7. Test before submitting

✓ The main feature works.
✓ The project works on the devices or screen sizes that matter.
✓ Broken links and obvious console/server errors have been fixed.
✓ No real credentials or private data are included.
✓ Images and assets used in the project may legally be published.
✓ The README and run instructions are clear.

8. Screenshots and demo links

Upload clear screenshots that show the finished product. If you have a live demo, YouTube walkthrough, Loom video or public Google Drive video, include the URL.

9. Team projects

List every team member who should receive creator credit. Include Mita School profile or portfolio links where available. Do not submit the project under only one person's name if several people contributed substantially.

10. What happens after submission?

You receive a submission ID immediately. Keep it. You can use the tracking page rather than messaging management directly.

Submitted → Under Review → Changes Requested / Approved → Deployment → Published

When the final status becomes Published and the live URL has been entered by the review team, the project is automatically reflected on the main Mita School Tools page.

11. Creator credit and ownership

Mita School may host, showcase and promote approved work through the Student Innovation Lab. The creator or team remains publicly credited. Where supplied, creator profile and portfolio links can also be displayed with the published project.

12. Final checklist

✓ I tested the project.
✓ I removed real secrets and credentials.
✓ I used .env.example if configuration is required.
✓ I removed unnecessary folders such as node_modules.
✓ I included clear run/setup instructions.
✓ I listed every creator/team member who deserves credit.