Forem: Atul Srivastava

Building BloomNest: A Full-Stack Childcare Management Platform with Angular 18 & Appwrite

Atul Srivastava — Mon, 06 Apr 2026 12:19:18 +0000

Childcare centers run on spreadsheets, WhatsApp messages, and paper forms. I wanted to see if I could replace all of that with a single web app. The result is BloomNest — a full-stack management platform for nurseries and kindergartens.

🔗 Live demo: https://bloomnest-mu.vercel.app/
📦 GitHub: https://github.com/atul0016/BloomNest

What it does

BloomNest handles everything a childcare facility needs day-to-day:

Child enrollment — profiles, groups, allergies, parent linkage
Staff management — roles, status tracking, CRUD operations
Smart scheduling — weekly grid, shift blueprints, conflict detection
Time tracking — clock in/out, daily logs, monthly summaries
Absence management — request/approve workflow with calendar view
Analytics dashboard — charts for attendance trends and staff coverage
Parent portal — view-only access to their own child's data
Push notifications — real-time alerts via Firebase Cloud Messaging
Dark mode — because obviously

Five distinct role dashboards: Admin, Board, Manager, Educator, and Parent — each seeing only what they need.

Tech stack

Layer	Choice	Why
Frontend	Angular 18 (standalone components)	Strong typing, scalable architecture
UI	Bootstrap 5.3 + Bootstrap Icons	Fast, consistent layout
Charts	Chart.js 4.4	Lightweight, flexible
Database + Auth storage	Appwrite Cloud	Real-time subscriptions, file storage, easy SDK
Authentication	Firebase Auth	Reliable, free tier, easy social login
Push notifications	Firebase Cloud Messaging	Battle-tested for web push
Hosting	Vercel	Zero-config Angular deploys

Angular 18's standalone components (no NgModule) made the folder structure much cleaner. Lazy loading each feature module kept the initial bundle small.

The interesting architectural decisions

1. Splitting auth between Firebase and Appwrite

Firebase handles identity (sign-in, password reset, token). Appwrite handles everything else — user profiles, role assignments, all app data. The two talk through a thin service layer that keeps the rest of the app unaware of which provider does what.

This sounds like it adds complexity, but in practice it meant I could swap either provider independently. Firebase Auth's email verification flow is excellent; Appwrite's database permissions model is excellent. Both together = best of both worlds.

2. Role-based routing without a library

Rather than pulling in a full RBAC library, I implemented guard-based routing using Angular's CanActivate. Each route declares which roles can access it. A RoleGuard checks the current user's role from a service and redirects if unauthorized.

Simple, type-safe, zero extra dependencies.

3. Shift blueprints for scheduling efficiency

Managers spend a lot of time building the same weekly schedule. I added "shift blueprints" — reusable shift templates that can be applied to any week with one click. It stores the pattern, not the instances, so changing a blueprint does not retroactively alter past schedules.

4. Real-time updates without polling

Appwrite's real-time subscriptions push changes instantly to connected clients. When an admin approves an absence request, the educator's view updates without a page refresh. The subscription teardown on ngOnDestroy prevents memory leaks.

Challenges

Appwrite permissions model — Appwrite uses document-level permissions. Getting role-based read/write to work correctly (especially for the parent portal's read-only access to child documents) required careful collection design. I ended up using server-side functions for anything sensitive.

Chart.js with live data — Chart.js does not automatically re-render when Angular's change detection runs. I had to call chart.update() manually after data changes, which meant tracking chart instances across components.

Angular 18 signals — I started using Angular signals for reactive state in a few components. The mental model is cleaner than RxJS for simple derived values (computed()), but integrating signals with Appwrite's observable SDK took some bridging work.

Demo accounts

You can log in and explore any role:

Role	Email	Password
Admin	aria.thornewood@bloomnest.app	admin123
Manager	caspian.drake@bloomnest.app	manager123
Educator	elara.finch@bloomnest.app	educator123
Parent	diana.whitmore@bloomnest.app	parent123

What's next

Export reports to PDF/Excel
Mobile app (Ionic + Capacitor, same Angular codebase)
Multi-facility support (one account, multiple locations)

If you're building with Angular 18 or Appwrite and have questions about any of the patterns above, drop them in the comments. Happy to go deeper on any section.

Building an Offline-First Multi-Tenant SaaS with React 19 and Dexie.js

Atul Srivastava — Sat, 04 Apr 2026 15:40:40 +0000

When I set out to build ParkManager — a multi-tenant parking management SaaS — I knew "works offline" wasn't optional. Parking lots don't shut down when the internet goes out.

Here's how I architected an offline-first, multi-tenant application using React 19, Dexie.js (IndexedDB wrapper), and Appwrite as the cloud backend.

The Problem

Most SaaS apps assume always-on connectivity. But in the real world:

Internet can be spotty at parking lots
Attendants need to issue tickets regardless of connection
Payment records can't be lost
Multi-tenant data must stay isolated

The Architecture

Stack Overview

Layer	Technology
Frontend	React 19 + Vite
Local DB	Dexie.js (IndexedDB)
Cloud Backend	Appwrite
Desktop	Electron
PWA	Service Workers
Auth	Role-Based Access Control (5 roles)

Offline-First with Dexie.js

The core idea: write locally first, sync to cloud when available.

// Dexie database schema
const db = new Dexie('ParkManagerDB');
db.version(1).stores({
  tickets: '++id, vehicleNumber, entryTime, exitTime, status, tenantId, synced',
  payments: '++id, ticketId, amount, method, tenantId, synced',
  users: '++id, email, role, tenantId'
});

Every record gets a synced flag. When online, a background sync job pushes unsynced records to Appwrite:

async function syncToCloud() {
  const unsynced = await db.tickets
    .where('synced').equals(0)
    .toArray();

  for (const ticket of unsynced) {
    try {
      await appwrite.databases.createDocument(
        DB_ID, TICKETS_COLLECTION, ticket.id, ticket
      );
      await db.tickets.update(ticket.id, { synced: 1 });
    } catch (err) {
      console.log('Will retry on next sync cycle');
    }
  }
}

// Run sync every 30 seconds when online
setInterval(() => {
  if (navigator.onLine) syncToCloud();
}, 30000);

Multi-Tenancy

Each record includes a tenantId. The Dexie queries always filter by tenant:

async function getTickets(tenantId) {
  return db.tickets
    .where('tenantId').equals(tenantId)
    .reverse()
    .sortBy('entryTime');
}

On the Appwrite side, collection-level permissions ensure tenants can only access their own data.

5 RBAC Roles

ParkManager supports 5 distinct roles with different permissions:

Owner — Full system access, can manage tenants
Admin — Manage parking lots, users, and reports
Operator — Day-to-day operations, view reports
Attendant — Issue/close tickets, collect payments
Accountant — View-only access to financial reports

const PERMISSIONS = {
  owner: ['*'],
  admin: ['manage_lots', 'manage_users', 'view_reports', 'manage_tickets'],
  operator: ['manage_tickets', 'view_reports'],
  attendant: ['create_ticket', 'close_ticket', 'collect_payment'],
  accountant: ['view_reports', 'view_payments']
};

function hasPermission(user, action) {
  const perms = PERMISSIONS[user.role];
  return perms.includes('*') || perms.includes(action);
}

PWA + Electron = Everywhere

The same React codebase runs as:

PWA — installable on any device with a browser
Electron app — native desktop experience with system tray, auto-updates
Web app — standard browser access

The Electron wrapper is thin:

const { app, BrowserWindow } = require('electron');

function createWindow() {
  const win = new BrowserWindow({
    width: 1200,
    height: 800,
    webPreferences: {
      nodeIntegration: false,
      contextIsolation: true
    }
  });

  // In production, load the built React app
  win.loadFile('dist/index.html');
}

app.whenReady().then(createWindow);

Key Takeaways

Offline-first isn't hard — Dexie.js makes IndexedDB pleasant to work with
Sync conflicts are the real challenge — use timestamps and "last write wins" for simple cases
Multi-tenancy at the data layer — tenant isolation should be enforced at every query
RBAC from day one — retrofitting permissions is painful
React 19 + Vite — blazing fast dev experience with HMR

Try It

Live Demo: park-my-vehicle.vercel.app
GitHub: github.com/atul0016/park-manager

If you're building SaaS products that need to work in unreliable network conditions, offline-first architecture is worth the investment. The user experience improvement is dramatic.

What offline-first patterns have you used in your projects? Drop a comment below!

How I Built a Full-Scale ERP System as a Solo Developer

Atul Srivastava — Fri, 03 Apr 2026 08:30:22 +0000

Most developers avoid ERP. It's complex, boring, and usually built by teams of 20+. I built one alone.

Why?

Indian small businesses run on disconnected spreadsheets, Tally, and WhatsApp. I wanted to build one clean desktop app that handles everything — finance, inventory, sales, purchase, GST, manufacturing, HRM, and reporting.

The Stack

Electron — Desktop delivery (Windows)
React + TypeScript — UI layer
SQLite — Local-first data storage
Node.js — IPC handlers and service layer

Why desktop + SQLite instead of a web app? Indian SMEs often have unreliable internet. A local-first app that just works, every time, was the right call.

What's Inside — 8 Modules

Finance: Chart of accounts, journal entries, general ledger, trial balance, P&L, balance sheet. Double-entry accounting built from scratch.

Inventory: Item master, warehouse structure, stock movement, valuations, low-stock alerts.

Sales: Customer management, sales orders, GST-compliant invoicing, receipt tracking, aging analysis.

Purchase: Vendor management, purchase orders, goods receipt, purchase invoicing, payment tracking.

Manufacturing: Bill of materials, work centers, production orders, MRP planning, job work, quality control.

HRM: Employee records, attendance, leave management, payroll, tax declarations.

GST & Compliance: E-invoice, e-way bill, GSTR reports, ITC reconciliation, HSN summaries. Built for Indian tax workflows.

Reports: Financial, sales, purchase, inventory, and GST reports with export options.

The Hard Parts

1. Domain modeling

ERP isn't one problem, it's 15 interconnected problems. A stock movement affects inventory valuations, which affects financial reports, which affects GST filings.

2. Double-entry accounting

Getting the chart of accounts, journal entries, and ledger posting right took longer than any UI work.

3. GST compliance

Indian GST rules change constantly. Building a flexible structure that handles e-invoicing, reverse charges, and ITC was the most research-heavy part.

4. Keeping it simple

The biggest temptation in ERP is feature creep. I forced myself to keep the UI clean: clear navigation, card-based actions, search-first header.

What I Learned

Build the data model first. If your chart of accounts is wrong, everything downstream breaks.
SQLite is underrated. For local-first business software, it's fast, reliable, and zero-config.
ERP is a product exercise, not just a coding exercise. You need to understand business operations, not just API design.
Ship module by module. I built Finance first, then Inventory, then Sales — each one tested before moving on.

Try It

Live demo: sa-erp.netlify.app
Source code: github.com/atul0016/sa-erp
Portfolio: beimatulportfolio.tech

If you're thinking about building business software as a solo developer — do it. The domain complexity is what makes it valuable, both as a product and on your portfolio.

I'm Atul Srivastava, a full-stack developer building ERP systems, SaaS platforms, and Chrome extensions. Open to freelance and remote work. Reach me at imatulsrivas@gmail.com.