DEV Community

Usman Murtaza
Usman Murtaza

Posted on

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

#buildinpublic #node #react #typescript

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:

  1. One design language — same colour tokens, same spacing scale, same glassmorphism treatment. Not enforced through a shared library, just through discipline.
  2. 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.
  3. Independent deployments — every product is its own Netlify site. No monorepo, no shared runtime, no cascading failures.
  4. 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

AI

  • 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
);
Enter fullscreen mode Exit fullscreen mode

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:

  1. Same visual DNA — dark background (#0c0c1d), aurora gradient accents, glassmorphism surfaces, one primary purple accent, one cyan accent for emphasis.
  2. Different personality — Campus is dense and functional. Play is playful and spacious. Notes is minimal. Weather is dashboard-like.
  3. 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>
Enter fullscreen mode Exit fullscreen mode

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:

  1. Ship the first product before you design the brand. Brand comes from shipping, not the other way around.
  2. Solve one pattern really well, then reuse it. Auth, RBAC, deployment config, error handling. These repeat.
  3. Keep products independent. A monorepo saves you 5 minutes of typing and costs you a weekend of debugging.
  4. Write in public. Every product I've written about has found users. Every silent product hasn't.
  5. 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

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.

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

Top comments (0)