## Logistikore — One operating system for a fleet you own and carriers you broker to.

- URL: https://www.naveentehrpariya.dev/projects/logistikore
- Industry: Logistics SaaS
- Client type: Product Company
- Country: United States
- Role: Full Stack Product Engineer
- Duration: Ongoing
- Status: Live
- Live: https://logistikore.com
- Year: 2026

A multi-tenant TMS for freight companies that both run their own trucks and broker loads to outside carriers. Dispatch, fleet, carrier brokerage, accounting and billing sit in one platform, and each tenant's subscription decides which modules unlock.

### Problem

Most freight software assumes a company is either an asset-based carrier or a broker. Firms that do both end up running two systems and reconciling between them by hand, so a load brokered out and a load run on own equipment never appear in the same profit picture.

### Objectives

- Run an owned fleet and a carrier brokerage from one order pipeline
- Generate driver pay from dispatch data instead of spreadsheets
- Isolate every company's data while one team supports all of them
- Price orders in three currencies without corrupting the reporting totals

### Solution

A Next.js front end over a Node service on PostgreSQL, split into a Regular module for owned equipment and an Outsourcing module for brokerage, sharing one order pipeline so margin is computed the same way on both. Stripe carries plan subscriptions, cycle discounts and usage limits. Python services handle the AI assistance and the scheduled FX-rate jobs. Pusher and Socket.io drive live counters, and every action lands in an audit trail.

### Features

- Dual modules: owned fleet (trucks, trailers, drivers, owner-operators) and carrier brokerage
- Order and load management with trip planning and BOL, POD and rate-confirmation documents
- Payslips auto-generated from solo miles, team miles or city hours, exportable to PDF
- Multi-tenant isolation with per-company subdomains, data, subscription and limits
- Role-based access with 12+ granular permissions on top of Admin, Accountant, Staff and Driver
- Stripe subscriptions with monthly, quarterly and yearly cycles, usage bars and purchase history

### Stack

  - Frontend: Next.js, React, Tailwind CSS
  - Backend: Node.js, Python
  - Database: PostgreSQL, Redis
  - Cloud: Pusher, Socket.io
  - Integrations: Stripe, AI assistance, FX rate jobs

### Engineering challenges

### Three currencies, one set of totals

Problem: Orders are priced in USD, CAD or INR. Converting on the way in loses what the customer was actually quoted, and converting on the way out means a report changes every time an exchange rate moves.

Approach: Each order stores the amount exactly as typed plus a normalized USD value and the FX rate that produced it. Reporting aggregates the base value, so totals stay stable and the original figure is never lost. Scheduled jobs keep the rates current.

### Support that needs to see a tenant without becoming one

Problem: A super admin has to reproduce a problem inside a customer's environment, and a tenant admin has to do the same for their own staff. Sharing credentials for that is how support access quietly turns into a permanent back door.

Approach: Emulation issues a short-lived token scoped to the target account rather than switching credentials, so the session expires by itself and the whole thing is written to the activity log under the real operator's identity.

### Outcome

- Brokered loads and owned-equipment loads report profit through the same pipeline
- Driver pay comes out of dispatch data rather than a spreadsheet
- New companies onboard onto isolated subdomains without a deployment

### What it taught

Multi-tenancy is mostly a permissions problem wearing a database costume. The isolation was the easy half; deciding what a dispatcher can see about a customer they were not assigned took longer than the schema.

Case study: https://www.naveentehrpariya.dev/projects/logistikore
More work: https://www.naveentehrpariya.dev/llms.txt