DEV Community: Usman Murtaza

How I Built Maniesta Career OS: An AI-Powered Resume Builder and Job Matching Platform

Usman Murtaza — Fri, 02 Oct 2026 23:43:54 +0000

Maniesta Career OS — Dev.to Article + LinkedIn + Twitter

Yeh sab ready hai. Pehle Dev.to article publish karo, phir LinkedIn aur Twitter pe share karo (URL ke saath).

1️⃣ Dev.to Article — Complete Content

Copy karo, apne naam se publish karo. Yeh placeholders nahi hain, full content hai.

# How I Built Maniesta Career OS: An AI-Powered Resume Builder and Job Matching Platform

Job hunting is broken. You spend hours crafting a resume, submit it to dozens of listings, and never hear back. Most of the time, an Applicant Tracking System (ATS) rejects your application before a human ever sees it.

I wanted to fix that. So I built **Maniesta Career OS** — an AI-powered career platform that generates ATS-optimised resumes, matches you with relevant jobs daily, and gives admins a full dashboard to manage it all.

🔗 **Live Demo:** [maniesta-career.netlify.app](https://maniesta-career.netlify.app/)

This post walks through how I designed the system, the technical decisions behind the AI integration, and the parts that were harder than expected.

---

## The Problem

Three problems, one platform:

1. **Resumes fail ATS filters.** Most job seekers write resumes without knowing how ATS parsers read them. Keywords matter, structure matters, and formatting can make or break a submission.
2. **Job matching is manual.** People scroll through dozens of job boards, hoping something sticks. There's no intelligent filtering — just endless lists.
3. **Career tools are fragmented.** Resume builders, job boards, application trackers, and career dashboards all live in different apps. Users context-switch constantly.

Maniesta Career OS combines all three into one product.

---

## Tech Stack Decisions

Here's what I picked and why:

- **React** — component-driven UI, easy to iterate on the AI dashboard and admin views
- **TypeScript** — non-negotiable for a project with this many data shapes (users, resumes, jobs, applications, admin sessions)
- **Vite** — fast dev server, instant HMR, cleaner build output than CRA
- **Firebase** — authentication, Firestore database, and cloud functions in one SDK; also easy to deploy
- **Tailwind CSS** — for rapid UI on the admin dashboard and resume editor
- **Gemini AI** — for resume content generation, ATS-optimisation suggestions, and job matching signals

The combination of Firebase + Gemini means I could ship an MVP quickly without running my own backend infrastructure.

---

## Architecture Overview

┌──────────────────┐
│ React Client │
│ (User + Admin) │
└────────┬─────────┘
│ HTTPS + Firebase Auth
▼
┌──────────────────┐
│ Firebase │
│ - Auth │
│ - Firestore │
│ - Cloud Fn │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Gemini AI API │
│ (Resume + Jobs) │
└──────────────────┘


Two distinct user journeys live in the same app:
- **Job seekers** build resumes, view matched jobs, and track applications.
- **Admins** manage users, monitor AI usage, and review the pipeline.

Both share the same Firebase backend, but the UI diverges sharply — which is why TypeScript saved me here.

---

## The Core: AI Resume Generation

When a user creates a resume, they provide raw details — job history, education, skills. The AI layer does three things:

1. **Rewrites bullet points** into achievement-focused language that ATS parsers read well.
2. **Suggests missing keywords** based on the target job title.
3. **Scores the resume** against ATS best practices.

The prompt engineering mattered more than the API call itself. Here's the shape of the function that generates suggestions:

typescript
// services/ai.ts
import { getGenerativeModel } from 'firebase/ai';

const model = getGenerativeModel(ai, { model: 'gemini-pro' });

export const generateResumeSuggestions = async (input: ResumeInput) => {
const prompt = `
You are an ATS optimisation assistant. Rewrite the following bullet
points into achievement-focused language. Preserve all facts.

Rules:
- Start each bullet with a strong action verb
- Quantify impact where numbers are given
- Keep each bullet under 20 words
- Do not invent metrics or experiences

Bullet points:
${input.bullets.map((b, i) => `${i + 1}. ${b}`).join('\n')}

Return a JSON array of the rewritten bullets in the same order.

const result = await model.generateContent(prompt);
return JSON.parse(result.response.text());
};


The key constraint I enforced: **the AI never invents facts.** It rewrites, reorganises, and suggests keywords — but it does not fabricate experiences or metrics. This was important for user trust.

---

## Daily Job Matching

Once a resume is saved, Maniesta Career OS runs a daily job match:

1. A scheduled Cloud Function runs every 24 hours.
2. For each user with an active resume, it fetches fresh job listings.
3. It computes a match score using the resume's keywords, the user's preferred location, and past applications.
4. It stores the top matches in Firestore.
5. The user sees them the next time they open the app.

The scoring is simple but effective — a weighted keyword overlap:

typescript
const computeMatchScore = (resume: Resume, job: Job): number => {
const resumeKeywords = new Set(resume.keywords.map(k => k.toLowerCase()));
const jobKeywords = job.tags.map(t => t.toLowerCase());

const overlap = jobKeywords.filter(k => resumeKeywords.has(k)).length;
const keywordScore = overlap / Math.max(jobKeywords.length, 1);

const locationScore = job.location === resume.preferredLocation ? 1 : 0.4;
const recencyScore = Math.max(0, 1 - job.ageInDays / 30);

return keywordScore * 0.6 + locationScore * 0.25 + recencyScore * 0.15;
};




Not fancy, but the weighting reflects real user behaviour — keywords matter most, then location, then freshness.

---

## The Admin Dashboard

Admins get a glassmorphism-styled dashboard with:

- **User management** — search, filter, deactivate accounts
- **Usage analytics** — daily AI calls, match rates, resume completion rates
- **Job pipeline** — how many jobs are being matched, which ones convert
- **System health** — Firebase usage, function invocations, error rates

The glassmorphism UI was a deliberate choice. It reads well on dark backgrounds and makes dense dashboards feel less clinical.

---

## Challenges I Didn't Expect

**1. TypeScript with Firestore generics.**
Firestore's type system is flexible but easy to loosen too much. I ended up defining strict schema types and a `withConverter` helper for every collection. Retrofitting this halfway through was painful.

**2. Prompt injection in resume content.**
Users can write anything in their resume bullets. A malicious user could try to make the AI produce unrelated content. I sanitise all user input before it hits the prompt — strip markdown, cap length, reject control characters.

**3. Firebase read costs.**
The daily job matching creates a lot of reads. I ended up using Firestore's batch writes and index tuning to keep reads under control. Real cost optimisation, not just code cleanliness.

---

## What I Learned

- **AI is a feature, not the product.** The value is in the workflow around the AI, not the AI itself.
- **TypeScript pays off at scale.** At 3 files you don't need it. At 60 files with 15 data shapes, it saves hours.
- **Prompt engineering is real engineering.** Bad prompts produce confidently wrong output.
- **Firebase is fast to start and slow to optimise.** Plan for cost from day one.
- **Glassmorphism looks good on dashboards** — it reduces visual fatigue in dense data views.

---

## Try It Out

- 🔗 **Live Demo:** [maniesta-career.netlify.app](https://maniesta-career.netlify.app/)
- 💻 **Source Code:** [github.com/usmannmurtazaa/Maniesta-careeros](https://github.com/usmannmurtazaa/Maniesta-careeros)

You can create a resume, see the AI suggestions, and view matched jobs. The admin side is behind authentication but the workflow is visible from the user side.

---

## What's Next

A few features in progress:

- **Application tracking** — a Kanban-style board for submitted applications
- **Interview prep** — AI-generated mock questions based on matched jobs
- **Resume versioning** — A/B test different resume versions against the same job set
- **Multi-language support** — resume generation in Urdu, Arabic, and Spanish

---

## About the Author

I'm **Usman Murtaza**, a Full Stack Developer based in Karachi, Pakistan. I build modern web applications with React, TypeScript, Node.js, and Firebase, and I'm the creator of the **Maniesta ecosystem** — a collection of web products and utilities.

**Maniesta Career OS** is one of those products. Others include Maniesta Campus, Maniesta Suite, Maniesta Veyra, and the Maniesta brand platform.

- 🌐 **Portfolio:** [usmanmurtaza.netlify.app](https://usmanmurtaza.netlify.app)
- 💻 **GitHub:** [github.com/Usmannmurtazaa](https://github.com/Usmannmurtazaa)
- 💼 **LinkedIn:** [linkedin.com/in/Usmannmurtazaa](https://www.linkedin.com/in/Usmannmurtazaa/)
- 🐦 **Twitter/X:** [@usman_murtazaa](https://twitter.com/usman_murtazaa)

If you found this useful, follow me here on Dev.to — I write about full-stack development, AI-assisted applications, and building products from scratch.

*Built by Usman Murtaza — see more projects at [usmanmurtaza.netlify.app](https://usmanmurtaza.netlify.app)*

Maniesta: Building a 12-Product Web Ecosystem Solo with React, Node.js, and TypeScript

Usman Murtaza — Sat, 26 Sep 2026 01:50:09 +0000

Every developer I know has a folder on their laptop called "ideas" that never gets built.

Two years ago, mine had about 40 entries. Today, 12 of them are live products that real people use, all sitting under one brand: Maniesta.

This isn't a "how I got rich" post. It's a breakdown of what it actually looks like to ship a whole product ecosystem alone — the technical decisions, the trade-offs, and the things nobody warns you about when you decide to build 12 things instead of polishing 1.

🌐 Ecosystem: maniesta.netlify.app
👤 Portfolio: usmanmurtaza.netlify.app

What Is Maniesta?

Maniesta is a web product ecosystem — a collection of tools, apps, and platforms that share a design language, a code philosophy, and a single creator (me).

The products fall into three loose categories:

Education & Productivity

Maniesta Campus — role-based campus management system
Maniesta School ERP — multi-portal school dashboard with attendance, fees, notices
Maniesta Notes — real-time notes app with auth, tags, and archive
Maniesta Suite — GPA, CGPA, and scientific calculator platform

Creative & Consumer

Maniesta Play — music discovery and listening app
Maniesta Weather — real-time weather dashboard
Maniesta Label — fashion e-commerce storefront
Maniesta Veyra — clothing e-commerce + custom print studio

Business & AI

Maniesta ResumeAI — AI-powered resume builder with ATS optimisation
ResumeAI Pro — standalone resume builder SaaS
Maniesta AI Travel Planner — Gemini-powered itinerary generator
Maniesta Digital — the agency site that ties it all together

Each one is live. Each one is used by someone. None of them are perfect.

The Architecture Decision That Changed Everything

The first two products I built had completely separate codebases. Different auth systems. Different design tokens. Different deployment pipelines. Different bugs.

By product three, I was maintaining three versions of the same login component.

So I made a decision that I still debate to this day: do I unify the ecosystem, or keep the products independent?

I chose a middle path — shared conventions, separate deployments.

The rules:

One design language — same colour tokens, same spacing scale, same glassmorphism treatment. Not enforced through a shared library, just through discipline.
Same tech stack where it makes sense — React for interactive apps, Vanilla JS for lightweight tools, Next.js when SEO mattered more than app-feel.
Independent deployments — every product is its own Netlify site. No monorepo, no shared runtime, no cascading failures.
Cross-linking over shared state — Maniesta products link to each other through footers and headers, but they don't share sessions or data.

This worked. If Maniesta Play goes down, Maniesta Campus keeps running. If I want to rewrite Maniesta Notes in a different framework, no other product is affected.

But there's a cost: every project repeats some boilerplate. Auth setup, deploy config, design tokens. It's the tax you pay for independence.

For a solo developer, I think it's the right tax.

The Stack — What I Actually Use

Across the ecosystem:

Frontend

React for interactive apps (Campus, ResumeAI, School ERP)
Next.js when I needed SSR and SEO (Veyra, AI Travel Planner)
Vanilla JS for lightweight utilities (Notes, Weather, Play)
TypeScript on newer projects, JavaScript on the earlier ones

Styling

Tailwind CSS for most new work
styled-components on the older React apps
Plain CSS on the utility tools

Backend

Node.js + Express for custom APIs
Firebase for auth, database, and real-time features
PostgreSQL + Prisma when the data model was relational
MongoDB when the schema was evolving fast

OpenAI API for ResumeAI Pro
Gemini AI for the Travel Planner
Both integrated through simple server-side proxies, never exposed to the client

Deploy

Netlify for everything. All 12 products run on the free tier.

What "Solo" Actually Means

When people hear "solo developer," they imagine one person doing the work of five.

The reality is different. Solo means:

You are the product manager. Decisions that would normally be argued out in meetings are made by you, alone, at 2 AM, with incomplete information.
You are the designer. Every spacing value, every colour, every animation curve — yours.
You are the QA team. Bugs ship more often than they should.
You are the DevOps engineer. Deploy fails at 11 PM? That's your Friday night.
You are customer support. Users email you directly. You reply from your phone.

The upside is total control. The downside is that everything you don't do doesn't get done.

Some Maniesta products have a README. Some don't. Some have tests. Most don't. There is no engineering manager to say "you should write docs for this." There's only me, and I'd rather ship the next feature than write the docs for the last one.

This is a real trade-off. I'm not proud of it. But it's honest.

The RBAC Problem — Solved Once, Reused Everywhere

Multiple Maniesta products needed role-based access control. Campus has admin/faculty/student. School ERP has admin/teacher/parent. ResumeAI has user/admin.

I learned early that RBAC bolted on later is RBAC that leaks.

So the first time I built it, I built it properly. A single pattern:

// 1. Verify the JWT, attach the user to the request
const authenticate = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'No token' });
  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET);
    next();
  } catch {
    res.status(401).json({ error: 'Invalid token' });
  }
};

// 2. Restrict the route to specific roles
const requireRole = (...roles) => (req, res, next) => {
  if (!roles.includes(req.user.role)) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  next();
};

// 3. Compose them in routes
router.delete(
  '/students/:id',
  authenticate,
  requireRole('admin'),
  deleteStudent
);

Every Maniesta product that needed RBAC copied this pattern. Not the code — just the pattern. It's small enough that repeating it is fine, and it's isolated enough that changing it in one place doesn't break others.

The lesson: patterns scale better than packages.

How I Handle the Ecosystem Branding

Every Maniesta product needs to feel like part of the same family, without feeling like the same app.

The formula I settled on:

Same visual DNA — dark background (#0c0c1d), aurora gradient accents, glassmorphism surfaces, one primary purple accent, one cyan accent for emphasis.
Different personality — Campus is dense and functional. Play is playful and spacious. Notes is minimal. Weather is dashboard-like.
Same footer pattern — every product's footer says:

<p>
  <strong>Maniesta Campus</strong> — a project by
  <a href="https://usmanmurtaza.netlify.app">Usman Murtaza</a>
</p>
<p>
  Part of the
  <a href="https://maniesta.netlify.app">Maniesta ecosystem</a>
</p>

This footer is doing two jobs:

For users: letting them discover the other products
For Google: connecting every product to one creator and one brand

Both matter.

The Mistakes I Made (and Still Make)

Mistake 1: Building too many things at once.

For a while I was working on Campus, ResumeAI, and Play simultaneously. None of them got the attention they needed. When I focused on one product at a time and shipped it fully, the quality jumped.

Mistake 2: Skipping documentation.

Six months later I can't remember why I structured a specific module the way I did. A 3-line comment would have saved hours.

Mistake 3: Not versioning the design system early.

I changed the accent colour halfway through the ecosystem. Rebuilding the older products to match took an entire weekend. If I'd written down the design tokens from day one, that weekend would have been one hour.

Mistake 4: Assuming people would find the products.

Shipping is 10% of the work. Distribution is the other 90%. Dev.to articles, LinkedIn posts, GitHub descriptions — none of that happens automatically. I had to build the habit.

What I'd Tell Someone Starting Today

If you're thinking about building your own product ecosystem — even a small one — here's what I've learned:

Ship the first product before you design the brand. Brand comes from shipping, not the other way around.
Solve one pattern really well, then reuse it. Auth, RBAC, deployment config, error handling. These repeat.
Keep products independent. A monorepo saves you 5 minutes of typing and costs you a weekend of debugging.
Write in public. Every product I've written about has found users. Every silent product hasn't.
Match the tech to the product, not the other way around. React for interactivity, Next.js for SEO, Vanilla JS for simplicity. Don't force one tool everywhere.

What's Next

A few things on the roadmap:

Maniesta One — a unified entry point that lets users jump between products from one place
Cross-product auth — optional single sign-on for users who want it
Open-sourcing a few of the utility tools — Notes, Weather, and Play are candidates
More writing — this is the first of several articles about building the ecosystem

If you're building something similar — a family of small products instead of one big one — I'd love to hear about it. Drop a comment or reach out.

Try Maniesta

🌐 Ecosystem hub: maniesta.netlify.app
🎓 Maniesta Campus: maniestacampus.netlify.app
📝 Maniesta Notes: maniestanotes.netlify.app
🌤️ Maniesta Weather: maniestaweather.netlify.app
🎵 Maniesta Play: maniestaplay.netlify.app

About the Author

I'm Usman Murtaza, a Full Stack Developer based in Karachi, Pakistan. I build modern web applications with React, Node.js, TypeScript, and Firebase — and I'm the creator of the Maniesta ecosystem.

🌐 Portfolio: usmanmurtaza.netlify.app
💻 GitHub: github.com/Usmannmurtazaa
💼 LinkedIn: linkedin.com/in/Usmannmurtazaa
🐦 Twitter/X: @usman_murtazaa

If you enjoyed this, follow me here on Dev.to — I'll be writing more about the Maniesta ecosystem, the technical decisions behind each product, and the realities of building alone.

Written by Usman Murtaza — see the full ecosystem at maniesta.netlify.app

How I Built Maniesta Campus OS: A Multi-Tenant Student Management SaaS with React and Firebase

Usman Murtaza — Sat, 26 Sep 2026 00:40:14 +0000

Educational institutions run on spreadsheets. Student records in one file, attendance in another, grades somewhere else, and course schedules — usually — in someone's head.

I built Maniesta Campus OS to fix that. It is a multi-tenant student management platform where an institute can manage students, courses, attendance, and marks through a single dashboard with role-based access.

🔗 Live Demo: maniestacampus.netlify.app

This post walks through the architecture, the multi-tenancy model, the RBAC system, and the parts that were harder than expected.

The Problem

Before writing any code, I mapped what an actual institute needs:

Admins manage students, courses, faculty, and enrollments
Teachers mark attendance, upload grades, and see their class rosters
Students check schedules, grades, and enrolled courses
Multiple institutes should be able to use the same platform without seeing each other's data

That last requirement is what makes this a SaaS problem rather than just a CRUD app. Real institutional software is multi-tenant by default — and multi-tenancy is where most of the design effort goes.

Tech Stack Decisions

Layer	Choice	Why
Frontend	React 18, React Router 6	Component-based UI with route-level separation for admin, teacher, student views
Styling	Tailwind CSS	Fast iteration across three different dashboard layouts
Backend	Firebase (Auth, Firestore, Storage)	No servers to manage, real-time by default, scales to zero cost on free tier
Auth	Firebase Authentication	Email/Password + Google sign-in out of the box
Database	Cloud Firestore	Document store fits hierarchical campus data; flexible schema per role
Charts	Recharts	Lightweight, composable, works well with Firestore data
Animations	Framer Motion	Spring-based transitions that feel native
Deployment	Netlify	Zero-config CI/CD from Git, edge CDN built in

No backend server. The client talks directly to Firebase, guarded by Firestore Security Rules. For a project at this scale that is a feature, not a limitation — it keeps the operational surface area near zero.

Architecture Overview

┌────────────────────────────┐
│     React SPA (Netlify)    │
│  - Auth pages              │
│  - Org-scoped portal       │
│  - Admin console           │
└───────────┬────────────────┘
            │ HTTPS + Firebase SDK
┌───────────▼────────────────┐
│       Firebase Cloud       │
│  - Authentication          │
│  - Firestore Database      │
│  - Storage (optional)      │
│  - Security Rules          │
└────────────────────────────┘

Every Firestore document carries an orgId field. Every query filters by orgId. Every security rule checks orgId against the authenticated user's profile. This is the entire multi-tenancy model in one sentence.

The Hard Part: Multi-Tenancy + RBAC

Two things had to work together from day one:

Multi-tenancy — an institute called "Springfield Academy" must never see data belonging to "Riverside College".
Role-based access — a student should not see admin controls; a teacher should not be able to edit another teacher's course.

I made three decisions upfront that kept the rest of the project sane.

Decision 1 — Single `users` collection with a role field

Rather than separate collections for admins, teachers, and students, I used one collection:

// users/{uid}
{
  email: 'ali@springfield.edu',
  displayName: 'Ali Khan',
  role: 'admin',          // 'admin' | 'teacher' | 'student'
  orgId: 'springfield',   // which institute this user belongs to
  createdAt: <timestamp>,
}

One auth flow. One user profile fetch. If a student is later promoted to a teacher, I update one field — no data migration.

Decision 2 — `orgId` on every document

Every course, student, mark, and attendance record has an orgId. This makes isolation explicit and enforceable at the database level:

// courses/{courseId}
{
  orgId: 'springfield',
  code: 'CS-400',
  name: 'Software Engineering',
  instructor: 'Prof. Fatima Rizvi',
  fees: 40000,
  totalStudents: 24,
  createdAt: <timestamp>,
}

Decision 3 — Enforce isolation in Security Rules, not just in code

Client-side filters are a convenience. The real guard is the security rule:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    function userOrgId() {
      return get(/databases/$(database)/documents/users/$(request.auth.uid)).data.orgId;
    }

    match /courses/{courseId} {
      allow read: if request.auth != null
                  && userOrgId() == resource.data.orgId;
      allow write: if request.auth != null
                   && userOrgId() == request.data.orgId;
    }

    match /students/{studentId} {
      allow read: if request.auth != null
                  && userOrgId() == resource.data.orgId;
      allow write: if request.auth != null
                   && userOrgId() == request.data.orgId;
    }

    // ... same pattern for marks, attendance
  }
}

Even if a client-side bug accidentally queries the wrong orgId, Firestore refuses to return or write data outside the caller's organization. Multi-tenancy becomes a database guarantee, not just a frontend convention.

Frontend: One App, Three Dashboards

The React shell renders three completely different dashboards based on the user's role:

const Dashboard = () => {
  const { user } = useAuth();

  switch (user.role) {
    case 'admin':
      return <AdminDashboard />;
    case 'teacher':
      return <TeacherDashboard />;
    case 'student':
      return <StudentDashboard />;
    default:
      return <Navigate to="/login" />;
  }
};

Each dashboard imports its own components. The shared shell — navbar, sidebar, header, footer — lives outside and is reused across all three.

A small ProtectedRoute wrapper handles the auth check on the way in:

const ProtectedRoute = ({ allowedRoles, children }) => {
  const { user } = useAuth();
  if (!user) return <Navigate to="/login" />;
  if (allowedRoles && !allowedRoles.includes(user.role)) {
    return <Navigate to="/unauthorized" />;
  }
  return children;
};

Adding a new admin-only page is now a single line:

<ProtectedRoute allowedRoles={['admin']}>
  <ManageFaculty />
</ProtectedRoute>

Real-Time Attendance

Attendance is where Firestore shines. Instead of a traditional "save then refresh" flow, attendance is written as individual documents:

// attendance/{attendanceId}
{
  orgId: 'springfield',
  courseId: 'cs-400',
  courseName: 'Software Engineering',
  studentId: 'ali-khan',
  studentName: 'Ali Khan',
  date: '2026-09-26',
  status: 'present',      // 'present' | 'absent'
  recordedBy: 'admin-uid',
  timestamp: <server timestamp>,
}

The teacher's view subscribes to today's records filtered by courseId. When a teacher marks someone present, the chart on the admin dashboard updates instantly — no polling, no refresh button, no manual consolidation step.

The weekly attendance trend on the dashboard is derived by querying the last seven days and counting present vs. absent. It sounds trivial, but the fact that data is already normalized makes the aggregation a 20-line function instead of a data pipeline.

Smart Marksheets

Marks follow the same pattern. Each mark is a document with the obtained score, the total, the computed percentage, and the letter grade:

// marks/{markId}
{
  orgId: 'springfield',
  studentId: 'ali-khan',
  studentName: 'Ali Khan',
  courseId: 'cs-400',
  courseName: 'Software Engineering',
  examType: 'Mid-term',
  obtainedMarks: 85,
  totalMarks: 100,
  percentage: 85,
  grade: 'A',
  recordedBy: 'admin-uid',
  createdAt: <server timestamp>,
}

Grades are computed at write time with a simple scale:

function gradeFromMarks(marks) {
  if (marks >= 90) return 'A+';
  if (marks >= 80) return 'A';
  if (marks >= 70) return 'B';
  if (marks >= 60) return 'C';
  if (marks >= 50) return 'D';
  if (marks >= 40) return 'E';
  return 'F';
}

I deliberately kept grading logic on the client for now. If institutes ever need custom scales, the field would move to a per-organization settings document and the function would read it at write time — but I did not want to solve that problem before a customer actually asked for it.

Firestore Indexes — the Part Nobody Warns You About

This one cost me an afternoon. Firestore requires a composite index whenever you combine a where filter with an orderBy on different fields:

query(
  collection(db, 'marks'),
  where('orgId', '==', orgId),
  where('courseId', '==', courseId),
  orderBy('createdAt', 'desc')
)

Firestore will refuse to run this query until a (orgId, courseId, createdAt) index exists. The error message includes a direct link to create it, but on a fresh project this throws immediately in development and looks like a bug in your code.

The fix is to declare indexes in a version-controlled file so they deploy with the rest of the project:

// firestore.indexes.json
{
  "indexes": [
    {
      "collectionGroup": "marks",
      "queryScope": "COLLECTION",
      "fields": [
        { "fieldPath": "orgId", "order": "ASCENDING" },
        { "fieldPath": "courseId", "order": "ASCENDING" },
        { "fieldPath": "createdAt", "order": "DESCENDING" }
      ]
    },
    {
      "collectionGroup": "attendance",
      "queryScope": "COLLECTION",
      "fields": [
        { "fieldPath": "orgId", "order": "ASCENDING" },
        { "fieldPath": "date", "order": "ASCENDING" }
      ]
    }
    // ...
  ]
}

Then:

npx firebase deploy --only firestore:indexes

Now every environment has the same indexes. No more "works on my machine".

What I Learned

Design multi-tenancy before writing features. Retrofitting orgId into a live app is brutal. Getting it right upfront made everything else easier.
Enforce isolation at the database, not the client. Security rules are not optional — they are the whole point of building a multi-tenant product.
Firestore composite indexes are a real constraint. They should live in version control alongside the schema, not be created ad-hoc from error messages.
Component composition in React scales beautifully for dashboards. Three completely different UIs coexisting in one app turned out to be cleaner than I expected.
No backend is a real architecture, not a shortcut. Removing the server did not remove the design work — it just moved it to security rules, client-side access patterns, and index declarations.

Try It Out

🔗 Live Demo: maniestacampus.netlify.app
💻 Source Code: github.com/usmannmurtazaa/maniesta-campus-os

The RBAC behavior is the most interesting part to explore — sign in with different roles and watch the navigation and available actions change.

What's Next

Some features I am working on:

Email notifications for password reset and announcements
Invite-based organization joining
Student and parent portal with grade history
File uploads for marksheets and documents
Subscription plans and billing integration
Enhanced analytics with exportable reports

About the Author

I am Usman Murtaza, a Full Stack Developer based in Karachi, Pakistan. I build modern web applications with React, Node.js, and Firebase, and I am the creator of the Maniesta ecosystem — a collection of web products and utilities.

Maniesta Campus OS is one of those products. Others include Maniesta Resume AI, Maniesta Suite, and the Maniesta brand platform itself.

🌐 Portfolio: usmanmurtaza.netlify.app
💻 GitHub: github.com/Usmannmurtazaa
💼 LinkedIn: linkedin.com/in/Usmannmurtazaa
🐦 Twitter/X: @usman_murtazaa
📝 Dev.to: dev.to/usmanmurtaza

If you found this useful, follow me here on Dev.to — I write about full-stack development, React patterns, and building products from scratch.

Built by Usman Murtaza — see more projects at usmanmurtaza.netlify.app

How I Built Maniesta Campus: A Campus Management System with React and Node.js

Usman Murtaza — Thu, 24 Sep 2026 11:50:51 +0000

Educational institutions run on paperwork and spreadsheets. Student records live in one file, attendance in another, grades somewhere else, and schedules — usually — in someone's head.

I kept hearing the same complaint from small colleges and coaching centers: "We need something simple that just works." So I built Maniesta Campus — a role-based campus management system with separate dashboards for admins, faculty, and students.

🔗 Live Demo: maniestacampus.netlify.app

This post walks through how I designed the system, the technical decisions I made, and the parts that were harder than expected.

The Problem

Before writing a single line of code, I mapped out what an actual campus needs:

Admins need to manage students, faculty, courses, and enrollments from one place
Faculty need to mark attendance, upload grades, and view their class rosters
Students need to see their schedule, grades, and enrolled courses without asking anyone

The core challenge was role-based access — one login system that serves three completely different user journeys. A student should never see admin controls, and a faculty member shouldn't be able to edit another faculty member's course.

Traditional CRUD apps don't handle this well. You end up with if (user.role === 'admin') scattered everywhere. I wanted something cleaner.

Tech Stack Decisions

Here's what I picked and why:

React — the UI needed to render completely different dashboards based on role. Component composition made this natural.
Node.js + Express — a straightforward REST API that I could iterate on quickly. No need for anything heavier.
MongoDB — campus data is hierarchical and evolves fast. Student records have different fields than faculty records, and course structures change per institution. Flexible schemas saved me from constant migrations.
JWT — stateless authentication means the API doesn't need session storage. Scales horizontally, and the frontend can hold the token with the user's role embedded in it.
Tailwind CSS — for fast UI iteration. When you're building three dashboards, you don't want to write custom CSS for every component.

Architecture Overview


┌──────────────────┐
│   React Client   │
│  (3 dashboards)  │
└────────┬─────────┘
│  HTTP + JWT
▼
┌──────────────────┐
│  Express API     │
│  - Auth routes   │
│  - RBAC middleware│
│  - Resource routes│
└────────┬─────────┘
│
▼
┌──────────────────┐
│    MongoDB       │
│  users, courses, │
│  grades, etc.    │
└──────────────────┘

Every request flows through an authentication middleware first, then a role-check middleware, then the actual route handler. Nothing reaches the database without passing the role gate.

The Core: Role-Based Access Control

The RBAC system is where most of the design effort went. Here's the middleware that powers it:

// middleware/auth.js
const jwt = require('jsonwebtoken');

// Verify the JWT and attach the user to the request
const authenticate = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) {
    return res.status(401).json({ error: 'No token provided' });
  }
  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded; // { id, role }
    next();
  } catch (err) {
    return res.status(401).json({ error: 'Invalid token' });
  }
};

// Only allow specific roles to proceed
const requireRole = (...roles) => (req, res, next) => {
  if (!roles.includes(req.user.role)) {
    return res.status(403).json({ error: 'Access denied' });
  }
  next();
};

module.exports = { authenticate, requireRole };

Now any route can declare its own access rules cleanly:

// routes/courses.js
const { authenticate, requireRole } = require('../middleware/auth');

// Anyone logged in can view courses
router.get('/courses', authenticate, listCourses);

// Only admins can create courses
router.post('/courses', 
  authenticate, 
  requireRole('admin'), 
  createCourse
);

// Faculty can update grades for their own courses
router.patch('/courses/:id/grades',
  authenticate,
  requireRole('faculty'),
  updateGrades
);

This pattern scales. If I ever add a "teaching assistant" role, I just pass it into requireRole — no other code changes.

Frontend: One App, Three Dashboards

On the frontend, I used a simple pattern — the auth context holds the user, and the dashboard component switches on the role:

const Dashboard = () => {
  const { user } = useAuth();

  switch (user.role) {
    case 'admin':
      return <AdminDashboard />;
    case 'faculty':
      return <FacultyDashboard />;
    case 'student':
      return <StudentDashboard />;
    default:
      return <Navigate to="/login" />;
  }
};

Each dashboard imports its own set of components. The shared pieces — navbar, notifications, profile, logout — live outside and are reused across all three.

A protected route wrapper handles the auth check on the way in:

const ProtectedRoute = ({ allowedRoles, children }) => {
  const { user } = useAuth();
  if (!user) return <Navigate to="/login" />;
  if (allowedRoles && !allowedRoles.includes(user.role)) {
    return <Navigate to="/unauthorized" />;
  }
  return children;
};

With this in place, adding a new admin-only page is a single line:

<ProtectedRoute allowedRoles={['admin']}>
  <ManageFaculty />
</ProtectedRoute>

Challenges I Didn't Expect

Schema design for multiple user types.
At first I considered separate collections for students, faculty, and admins. That meant three login flows and three auth systems. Then I realized a single users collection with a role field plus role-specific optional fields is much simpler. When a student is also a teaching assistant, I just update the role — no data duplication.
Keeping the JWT payload small.
I only embed { id, role } in the token. Everything else — name, email, permissions — is fetched on demand. Bigger tokens are slower to verify, and they become stale as soon as a user updates their profile.
Grade calculation edge cases.
What counts as an "A"? Every institution has its own grading scale. I ended up making the scale configurable per institution and storing it in the database, so the grading logic stays data-driven rather than hardcoded.

What I Learned

· Design RBAC before writing features. Retrofitting access control into an existing app is brutal. Getting it right upfront made everything else easier.
· Keep JWTs thin. Only store what the token actually needs to prove identity. Fetch the rest.
· Data-driven grading beats code-driven grading. When in doubt, make it configurable.
· Component composition in React scales beautifully for dashboards. Three completely different UIs coexisting in one app turned out to be much cleaner than I expected.

Try It Out

· 🔗 Live Demo: maniestacampus.netlify.app
· 💻 Source Code: github.com/usmannmurtazaa/maniesta-campus-os

You can log in as different roles to see how the dashboards change. The RBAC behaviour is the most interesting part to explore.

What's Next

A few features I'm planning:

· Real-time notifications with Socket.io for grade updates and enrollment changes
· An analytics dashboard for admins (enrollment trends, popular courses)
· A mobile app built with React Native that shares the same API
· Bulk import from Excel so institutions can migrate their existing records

About the Author

I'm Usman Murtaza, a Full Stack Developer based in Karachi, Pakistan. I build modern web applications with React, Node.js, and MongoDB, and I'm the creator of the Maniesta ecosystem — a collection of web products and utilities.

Maniesta Campus is one of those products. Others include Maniesta Resume AI, Maniesta Suite, and the Maniesta brand platform itself.

· 🌐 Portfolio: usmanmurtaza.netlify.app
· 💻 GitHub: github.com/Usmannmurtazaa
· 💼 LinkedIn: linkedin.com/in/Usmannmurtazaa
· 🐦 Twitter/X: @usman_murtazaa

If you found this useful, follow me here on Dev.to — I write about full-stack development, React patterns, and building products from scratch.

Built by Usman Murtaza - see more projects at usmanmurtaza.netlify.app

DEV Community: Usman Murtaza

How I Built Maniesta Career OS: An AI-Powered Resume Builder and Job Matching Platform

Maniesta Career OS — Dev.to Article + LinkedIn + Twitter

1️⃣ Dev.to Article — Complete Content

Maniesta: Building a 12-Product Web Ecosystem Solo with React, Node.js, and TypeScript

What Is Maniesta?

The Architecture Decision That Changed Everything

The Stack — What I Actually Use

What "Solo" Actually Means

The RBAC Problem — Solved Once, Reused Everywhere

How I Handle the Ecosystem Branding

The Mistakes I Made (and Still Make)

What I'd Tell Someone Starting Today

What's Next

Try Maniesta

About the Author

How I Built Maniesta Campus OS: A Multi-Tenant Student Management SaaS with React and Firebase

The Problem

Tech Stack Decisions

Architecture Overview

The Hard Part: Multi-Tenancy + RBAC

Decision 1 — Single users collection with a role field

Decision 2 — orgId on every document

Decision 3 — Enforce isolation in Security Rules, not just in code

Frontend: One App, Three Dashboards

Real-Time Attendance

Smart Marksheets

Firestore Indexes — the Part Nobody Warns You About

What I Learned

Try It Out

What's Next

About the Author

How I Built Maniesta Campus: A Campus Management System with React and Node.js

The Problem

Tech Stack Decisions

Architecture Overview

The Core: Role-Based Access Control

Decision 1 — Single `users` collection with a role field

Decision 2 — `orgId` on every document