First Pindo post

Conversation engine

As of now, the frontend team manages one active product, SMS under Pindo.io, with a second service, Pindo.ai, currently in development—and more coming soon.

As the Lead Frontend Engineer, my responsibility is to ensure that the frontend architecture scales efficiently as we continue to expand into a multi-service platform.

✅ Strategic Moves So Far

1. Migration to Next.js App Router
   We moved from a traditional React.js setup to Next.js with the App Router, unlocking server components, layout nesting, route groups, and improved routing flexibility.

2. Styling: From styled-components to Tailwind CSS
   We adopted Tailwind CSS to boost DX and UI consistency while eliminating runtime CSS parsing.

3. Rethinking Monorepo
   Initially, we explored monorepo architecture to manage services independently. However, due to the tight coupling of services under one user domain (a single Pindo organization), this was reconsidered. The services behave more like modules of one unified platform, not standalone products.

🧠 Product Philosophy

• All services are under one Pindo umbrella.

• A user must belong to a Pindo organization to access any service.

• Services are modular—users can opt-in or out depending on their needs.

• Based on this, we decided to keep all services in a single Next.js application, leveraging the App Router's modular routing.

🏗️ Proposed Folder Structure

Here's the updated app structure for clarity:

src/
├── app/
│   ├── layout.tsx             # Root layout
│   ├── page.tsx               # Root landing page
│   ├── sms/                   # Service 1
│   │   ├── page.tsx
│   │   ├── layout.tsx
│   │   └── components/
│   ├── ai/                    # Service 2 (e.g., Pindo.ai)
│   │   ├── page.tsx
│   │   └── components/
│   ├── telephony/             # Service 3
│   └── settings/              # Org-wide settings
├── shared-ui/                 # Common UI components
├── shared-utils/              # Reusable helpers and utilities
├── middleware.ts              # Route protection via feature flags
└── lib/                       # API clients, auth utils, etc.

🥉 Dynamic Feature Access via Feature Flags

We will use feature flags (e.g., via @vercel/flags) to:

• Dynamically show/hide pages and components

• Restrict access to service routes (e.g., /telephony) based on user permissions

• Inject flags at the middleware level using secure server-side checks based on the JWT/session

This keeps unauthorized users from accessing features they aren’t subscribed to, both visually and programmatically.

📐 App Layout Representation

[Pindo Platform]
    |
    ├── Home (/) ──▶ Shared Dashboard
    ├── /sms ──────▶ SMS Service
    ├── /ai ───────▶ AI Assistant (Pindo.ai)
    ├── /telephony ──▶ Telephony Service
    ├── /settings ──▶ Org/User Settings
    └── Middleware → Checks Auth + Feature Flags

🌍 High-Level Architecture

+---------------------------+
|         Browser           |
+------------+--------------+
             |
             v
+---------------------------+
|      Next.js Frontend     |
|  - App Router             |
|  - TailwindCSS            |
|  - Middleware (flags)     |
|  - Modular Services       |
+------------+--------------+
             |
             v
+---------------------------+
|         API Layer         |
|   - Auth (JWT/session)    |
|   - User Profile          |
|   - Feature Flags         |
|   - Service Data          |
+------------+--------------+
             |
             v
+---------------------------+
|         Backend           |
|  - Auth DB                |
|  - Services Logic         |
|  - Feature Control        |
|  - Billing                |
+---------------------------+

📂 High-Level Diagram: Frontend Folder Structure

src/
├── app/                          # Next.js App Router base
│   ├── layout.tsx                # Root layout
│   ├── page.tsx                  # Root homepage/dashboard
│   │
│   ├── sms/                      # Service 1: SMS
│   │   ├── page.tsx
│   │   ├── layout.tsx
│   │   └── components/
│   │
│   ├── ai/                       # Service 2: AI Assistant (Pindo.ai)
│   │   ├── page.tsx
│   │   └── components/
│   │
│   ├── telephony/                # Service 3: Telephony
│   │   ├── page.tsx
│   │   └── components/
│   │
│   └── settings/                 # Org/user-wide settings
│       └── page.tsx
│
├── shared-ui/                   # Common UI components across all services
├── shared-utils/                # Shared utility functions
├── lib/                         # Auth, API clients, constants, helpers
├── middleware.ts                # Route protection + dynamic flag checking
└── types/                       # Global TypeScript types/interfaces

⚠️ Notes & Considerations

• Scalability: Keeping services in one app but isolated by folders and flags allows faster onboarding, testing, and deployments.

• Security: Feature flags must be enforced both client-side (UX) and server-side (middleware + backend authorization).

• Performance: Ensure only the needed service code is loaded (optimize with dynamic imports or route groups).