Skip to content

fig. Pin-house app · 2025

Work OS A case study by Mayank Panchal

Workspace & Project Management SaaS

Enterprise-grade monorepo workspace engine featuring Next.js 15, React 19, Zustand & PWA on the frontend with a 28-module FastAPI, PostgreSQL 16 & Redis 7 backend.

Visit live All projects
Work OS - Workspace & Project Management SaaS: homepage screenshot of the in-house app platform built by Mayank Panchal
Role
System Architect & Full-Stack Developer
Client
In-House SaaS
Year
2025
Category
In-House App

Overview

Work OS is an end-to-end workspace and project management platform architected as a modular monorepo. The web client (apps/web) is built on Next.js 15, React 19, Zustand, and React Query with offline PWA support, while the high-performance backend (apps/api) runs on FastAPI (Python) across 28 decoupled domain modules backed by PostgreSQL 16 and Redis 7. It powers real-time cross-component communication, strict schema validation, distributed caching, and end-to-end agency workflow orchestration without third-party bloat.

Highlights

  1. 01

    Next.js 15 & React 19 frontend with Zustand state & React Query caching

  2. 02

    FastAPI backend architecture spanning 28 decoupled domain modules

  3. 03

    PostgreSQL 16 relational persistence & Redis 7 distributed cache layer

  4. 04

    Monorepo package boundaries with strict cross-component data flow & PWA

fig. P.2system design

How it’s built.

One deployable API split into 28 domain modules with hard boundaries, a PWA client that caches aggressively and survives offline, and Redis doing triple duty as cache, pub/sub and job broker in front of PostgreSQL.

fig. P.2 — architecture · work os
Modular monolith · FastAPI + Next.js PWA
01 · Client02 · Edge03 · Application04 · Async05 · Data06 · PlatformNext.js 15React 19 · App RouterReact Queryclient cache · SWRService workerPWA · offline shellNginxTLS · gzip · proxyFastAPIJWT · RBAC · routingDomain modules28 bounded contextsWebSocket hublive board updatesTask workersexports · notificationsPostgreSQL 16source of truthRedis 7cache · pub/sub · queueMonorepoapps/web · apps/apiGitHub Actionslint · type · testDocker imagesone per app · by shaCompose hosthealth-checked
  • Client
  • Cache
  • Edge / proxy
  • Service
  • Worker
  • Database
  • Platform
  • async

Flow · Read · cache hit

Opening a workspace: two caches stand between the click and the database.

01 / 07

Design decisions

  1. 01Monolith or microservices

    A modular monolith - 28 domain modules in one FastAPI deployable.

    Module boundaries give the separation of services without network hops, distributed transactions or N deploy pipelines for a small team.

    Trade-off · One process scales as a unit; a hot module cannot be scaled alone until it is extracted - which the boundaries make possible later.

  2. 02One Redis, three jobs

    Redis 7 as cache, pub/sub bus and task broker.

    One operationally simple component covers all three needs at this scale, with sub-millisecond latency.

    Trade-off · Pub/sub is fire-and-forget, so clients refetch on reconnect rather than trusting every push.

  3. 03Where the client keeps state

    React Query for server state, Zustand for UI state.

    Server data gets caching, deduping and optimistic updates for free; local UI state stays tiny and synchronous.

    Trade-off · Two state models to learn - the rule is simple: if the server owns it, it lives in React Query.

  4. 04Offline support

    PWA with a precached shell and queued mutations.

    Agencies work on trains and conference Wi-Fi; a project tool that blanks out loses trust.

    Trade-off · Replay needs idempotent endpoints and conflict handling when two people edited the same card.

Concepts in this system