-
Week 1
2–8 November
Both interns together
Research and environment: Firebase, Rules, Functions, Cloudflare, R2, GitHub. Plus 3 project ideas each.
-
Week 2
9–15 November
Separate work
App: a small app with dynamic features. Dashboard: a super admin dashboard.
-
Week 3
16–22 November
Together, jointly
Connect the app and the dashboard. At the end of the week, each intern makes a separate submission.
-
Week 4
23–29 November
Flexible week
Finish remaining work, fixes, 1:1 feedback and the final demo. No major new tasks.
Rules for the Month
This month the interns will learn the full loop of our tech stack hands-on. Amal's real code and production systems will not be given to interns. They will learn Amal's structure and patterns in small, separate projects.
Red lines
If any one of these happens, the rating for that week is capped at “Needs improvement”.
- Committing an API key, a secret or a .env file, or sharing one in chat or in any public place.
- Accessing production Firebase or Cloudflare, or any company data, without the supervisor's permission.
- Pushing to the main branch without a review.
- Submitting code that you cannot explain yourself. AI tools may be used, but the intern is responsible for the submitted code and must be able to explain it.
No AI in descriptive writing
- AI must not be used to write descriptive text. Write it yourself, in your own words, with understanding.
- AI may be used to research and learn. But if you copy and paste AI-written text directly, marks may be deducted.
- The writing in this section will be scanned with an AI detector.
Research and Environment (both interns)
Goal: understand the tools by running them yourself, and write notes. For every topic, do not only read: complete a small hands-on exercise as well.
| Topic | Research topics | Hands-on practice | Deliverable |
|---|---|---|---|
| Environment setup | Editor for both: VS Code. App: Flutter and Dart extensions in VS Code, Flutter SDK, Android SDK (build tools), JDK, Git, Node.js, Firebase CLI, FlutterFire CLI. Dashboard: Node.js LTS, VS Code (ESLint and Prettier extensions), Git, Firebase CLI, Wrangler. | App: run flutter doctor in the terminal and get a green tick on every item. Then create an empty app with flutter create and run it from VS Code on a phone or an emulator.Dashboard: create a React + TypeScript project with npm create vite@latest and open it in the browser with npm run dev. | |
| Git and GitHub | clone, branch, commit, push, PR, merge conflict. The .gitignore and .env rules: why a secret can never be committed. | Open your own repository and merge one PR; resolve a deliberate conflict. |
Repository link + 1 merged PR + Git report
|
| Firebase project | A sandbox project, Auth (Email/Password), Firestore, and how the project configuration is connected to the app. | Sign-up and login, create the users/{uid} document, and read it in real time. |
Project ID + Firebase report (with screenshots and notes)
|
| Firestore Rules | Structure of rules, auth checks, blocking everything except the user's own data, role-based rules, validation, the Emulator Suite. | Block client writes to fields such as a balance. Make every Emulator test pass and add at least 2 tests of your own. |
Rules file + test output + Rules report (with attack table)
|
| Storage Rules | File size and type limits, writing only to your own folder, public versus private. | Limit image uploads to 2 MB or less and to jpg/png, and block wrong files. Make every Storage test in the Emulator pass and add at least 2 tests of your own. |
Rules file + test output + Storage report (with attack table)
|
| Cloud Functions | TypeScript functions, callable versus trigger, auth checks, error handling, debugging from logs. Why values such as a balance are changed by a Function and not by the client. | Write a callable that verifies login and adds points, and a Firestore trigger; make the unit tests pass; run it in the Emulator. Deploy to your own sandbox if you have Blaze (optional, needs a card). |
Function code + test output + Functions report (with safeguard table)
|
| Cloudflare | Account, Workers, Pages, environment variables and secrets, and why a Worker is the place to keep secrets. | Write a Worker that verifies the signature and claims of a Firebase ID token; use a secret without putting it in code; make all tests pass; run the Worker on your own computer and test it with curl. Deploying to Cloudflare's free plan is optional (no card needed). |
Worker code + test output + Cloudflare report (with safeguard table)
|
| Cloudflare R2 | Buckets, private access, upload URLs, size and type limits. | Store, serve and delete one picture in a private bucket through a Worker; verify the size and the real file type (by reading the first bytes); make all tests pass; run it on your own computer with a simulated bucket (no card needed). Creating a real bucket is optional and needs a payment method. |
Worker code + test output + R2 report (with safeguard table)
|
| Pushing projects to GitHub | Organise the projects, push them, write a README, and check that no secret is included. | Put all exercises into one clean repository, each with a README and a .gitignore. Run the secret scanner and show the before and after results, check the history as well, install a hook that blocks bad commits, and clone into a new folder and run the project by following the README. No card needed. |
Repository link + scanner before and after results + GitHub Push report
|
Week 1 day-by-day pace (suggestion)
The list below is a suggestion, so that everything fits into 6 working days with Friday left out. The real Storage bucket, the Cloud Functions deployment and the real R2 bucket (which need a card) are optional; this pace is possible without them.
| Day | Date | Suggestion |
|---|---|---|
| Monday | 2 November | Kickoff meeting; environment setup (VS Code, Git, Node or Flutter); download the resources |
| Tuesday | 3 November | Git and GitHub practice; your own Firebase project and Authentication |
| Wednesday | 4 November | Firestore data and real-time reads; start Firestore Rules |
| Thursday | 5 November | Finish Firestore Rules; Storage Rules |
| Friday | 6 November | Day off. No work. |
| Saturday | 7 November | Cloud Functions and the Cloudflare Worker |
| Sunday | 8 November | Cloudflare R2, pushing the projects to GitHub, the 3 ideas and all submissions. This is the last day of the week. |
Extra task: 3 project ideas
Each intern submits 3 ideas separately. The ideas should be similar to Amal in type, but not a copy of Amal. The reviewing authority will review them and say which one will be built in Week 2.
| Idea template | What to write |
|---|---|
| Name and description | The project name and, in one line, what it does. |
| Users | Who the app users are, and who the admins or super admins are. |
| Core features | 4 to 5 features. At least 2 must be dynamic, that is, changeable by the super admin (switching a feature on or off, changing content). |
| Access control | Which role can see or do what. |
| API integration | At least one API (a Cloud Function, a Worker or a public API). |
| Services | Which of Firebase, Cloudflare and R2 will be needed. |
| Scope | What is realistically possible in 2 weeks; what comes first and what comes later. |
What the reviewing authority will check
- Whether it can be built in 2 weeks.
- Whether dynamic features and access control really exist.
- Whether the App idea and the Dashboard idea can be connected in Week 3. If needed, an idea with the same theme may be approved for both interns.
- No use of any private or confidential Amal information.
Write your ideas in the document, laid out properly, then upload the file and submit it. The template has separate sections for each of the 3 ideas, with fields for dynamic features, roles and access, the data contract and the technical plan.
Evaluation
Every score needs evidence behind it (PR, repository, demo, test output). No evidence = no score. Score = weight × achievement (maximum 100%).
25 points
Quality of research notes, rules tests, the Worker, quality of the 3 ideas.
35 points
Your own project, dynamic features, code conventions, tests.
40 points
Integration, joint work, quality of the submission.
Week 4 is not for new work: it is flexible time to finish remaining work, fix issues from feedback and prepare the final demo. Regular daily updates and weekly reports are also counted in the evaluation.