WisePerformer case
ENRU
WisePerformer
Own product · SaaS ERP
Case study - my own product in progress

Shop-floor ERP.
Every hour of work is visible and priced.

WisePerformer is a multi-tenant SaaS ERP for small-batch manufacturing: tech cards, QR-tracked baskets, an operation timer, per-operation payroll, product costing and stock forecasting. The idea was proven by three prototypes in July 2024; the 2026 product is built solo, with a disciplined engineering method. The engineering bar: 272 backend + 11 frontend automated tests, all green.

Django 5.2 + DRFPostgreSQL 16 · schema-per-tenantReact 19 + Ant Design 6 GrafanaTraefik v3pytest · Vitest + MSW
8 / 45+
Django apps / database models
~110
API operations behind a React SPA
10
SPA screens, from shop floor to payroll
~40K
lines of code: ~25K Python + ~15K TS
3
prototypes in July 2024 proved the idea
272 + 11
backend + frontend tests, all green
01 Lineage 2024 - 2026

An idea that survived three prototypes and a 17-month pause

The whole product concept was written down in July 2024: QR tracking of operations, per-operation payroll, load monitoring, statistics. Three prototypes tested the idea. A year and a half later it became a production multi-tenant SaaS.

Jul 8-12, 2024

SewingERP

17 database models in one file. The README already describes the full product: QR time tracking, per-operation pay, load forecast.

Jul 12-19, 2024

basketerp + ProductERP

A one-day auth spike, then a real SPA split: Django + DRF + JWT in httpOnly cookies, React + MUI. A manager menu of 6 tiles. Only 1 of 6 worked.

Pause

~17 months

The idea waited. The 6 tiles of the prototype stayed a written promise.

Dec 2025 - Feb 2026

WisePerformer

Brand and landing first, then the ERP: 8 Django apps, schema-per-tenant, React 19 SPA, Grafana, Traefik.

Jul 2026

Engineering polish

272 green tests, the landing's design tokens, a dark theme, a make demo runbook. The product is ready to show itself.

6 menu tiles of 2024 = 6 working modules of 2026

The manager menu drawn in the ProductERP prototype on July 13, 2024 was a roadmap. Five of six tiles were placeholders back then. In 2026 all six are live modules.

Employee management (tile, 2024)
HR module: departments, roles, module permissions, statuses
Production management (placeholder)
Orders and QR baskets: planning, printing, allocation
Load distribution (placeholder)
Production plans + the operation timer on the shop floor
Tech cards (placeholder)
Products, operations with time norms and videos, materials
Statistics (placeholder)
Analytics views in PostgreSQL + 2 Grafana dashboards
Warehouse (placeholder)
Stock, movements, reserves, purchase forecast
3prototypes, July 2024
17models on day one of SewingERP
~17 mopause between generations
8Django apps in the production ERP
1author across the whole lineage
02 Architecture

Multi-tenant by schema: one platform, an isolated schema per company

Each client company gets its own subdomain and its own PostgreSQL schema. Traefik routes the subdomain, Django middleware switches search_path per request, and the public schema keeps only auth and company registry. Analytics lives in dedicated SQL views read by Grafana.

ONE PLATFORM · A SUBDOMAIN AND A SCHEMA PER COMPANY React 19 SPA 10 screens · Ant Design 6 TanStack Query · Vite QR scanner: html5-qrcode company.wiseperformer.com session auth + CSRF Traefik v3 TLS termination subdomain routing auth stack + company stacks on one VPS Django 5.2 + DRF 8 apps · ~110 API ops TenantSchemaMiddleware: SET search_path per request fail-closed isolation PostgreSQL 16 public: auth, companies schema per tenant: 45+ models, 43 migrations analytics: 3 MV + 5 views optional separate auth DB Grafana OSS 2 dashboards: throughput, efficiency, plan vs fact theme-synced iframe dashboards embedded into the Statistics screen analytics views per tenant
Client side Platform services Data

The shop-floor loop: from a printed QR to payroll

The core scenario of the product. A basket of parts travels through the shop, and every step feeds the same database: output, stock, wages, analytics.

1 · Print the QR every physical basket has a QR token; printed from the production screen 2 · Scan at the post worker scans with a camera; context: order, product, next operation from the tech card 3 · Operation timer start, pause, finish; event log; DB constraint: one active run per basket 4 · Rejects rejects logged with photos; counted out of the basket's output 5 · Output, once recorded only on the final operation of the tech card: planned minus total rejects 6 · Stock write-off materials consumed by tech card norms; reserves go active to fulfilled; idempotent 7 · Payroll net worked time x rate; overtime per day; periods: calculate, approve, pay out Analytics throughput by department, employee efficiency, plan vs fact in Grafana every event lands in the tenant schema; analytics views read the same rows
Shop-floor steps Money and stock effects Analytics
8Django apps
45+database models
~110API operations
3 + 5materialized views + SQL views
2Grafana dashboards
43database migrations
03 The product

What WisePerformer does on the shop floor

An ERP for workshops that assemble or sew in batches: the shop works with baskets and a timer, the manager works with orders, costs and payroll, the owner watches dashboards.

QR baskets and the operation timer

Every basket carries a printed QR. A worker scans it with the camera and gets the exact next operation from the tech card, with a video instruction and a time norm. Start, pause, finish, log rejects with photos. A DB constraint allows one active run per basket. Continuations carry time over without double counting.

Per-operation payroll

Net worked seconds times the employee rate, overtime per day with configurable rounding. Payroll periods run draft, calculated, approved, paid, with adjustments and a computed balance. The payout breakdown shows every operation run behind the number.

Product costing

Materials by tech card norms times purchase price, plus labor: operation time norms times an hourly rate, with per-operation overrides. Incomplete data becomes a warning, not a silent zero. Demo product: 425 materials + 152.50 labor = 577.50 per unit.

Warehouse with a purchase forecast

Stock via movements, reserves per order, automatic write-off when a basket is released. Output is recorded once, on the final operation of the tech card. The consumption forecast answers the real question: how many days until this material runs out, and how much to buy for the horizon.

HR with work history

Departments, roles and module permissions, employee statuses, work schedules. Each employee keeps a work history: which operations, how long, at what quality. Permissions are granted per module: view, edit, delete.

Plan vs fact analytics in Grafana

Analytics views live in PostgreSQL inside each tenant schema. Grafana shows department throughput, employee efficiency and plan vs fact; the iframe switches theme together with the app.

Main dashboard with module widgets
The dashboard: 7 live widgets, from production plan to warehouse alerts, one summary endpoint.
Operation timer screen with QR scanning
The operation timer: scan a basket, watch the instruction, run the timer, log rejects.
Tech card screen with the costing tab
A tech card with the costing tab: materials plus labor, unit cost with warnings on gaps.
Manager payroll calculation screen
Payroll: the manager tab runs the full cycle from a payroll period to payout.
HR screen with employees and permissions
HR: departments, roles, per-module permissions, work history with honest processed counts.
Warehouse screen with stock and purchase forecast
Warehouse: stock, reserves, days-to-stockout forecast and a purchase recommendation.
04 Engineering culture

Tests, typing, safe defaults

A product in progress rests on discipline, not heroics. Every guarantee is written in code: a test, a DB constraint, or a configuration default.

272 + 11 tests, all green

A full pytest run on PostgreSQL and Vitest + MSW on the frontend. Payroll, warehouse and production-fact logic have dedicated test files on isolated databases.

An end-to-end scenario as a test

An integration test drives a basket through the timer API from scan to output and checks that stock was consumed and wages accrued. Plus a clean makemigrations check.

Type-checked build

TypeScript across the frontend, a type-checked production build, 0 browser console errors across all screens in both themes.

Safe defaults

Fail-closed multi-tenant isolation: middleware refuses a request without an explicit tenant schema. IsAuthenticated by default for the API, per-employee module permissions.

Invariants live in the DB

One active run per basket as a partial unique index. Output recorded once, on the final operation. Stock write-off is idempotent: a repeated call never deducts twice.

Runbook: make demo

One command brings up PostgreSQL, Django, Grafana and demo data with 346 operation runs. The stack deploys in minutes on a clean machine.

How it was built

Solo, an engineering method

The product is written by one person to an engineering method: a spec for every task, automated tests, a runbook and documentation. The human sets the task, verifies the result and holds the bar. Tests and typing are the contract that makes this pace safe.

272pytest tests, all green
11Vitest + MSW tests
0browser console errors
346seeded operation runs in the demo
05 Design system

The ERP continues the landing: tokens, dark theme, monogram

One token file drives both the antd theme and the CSS variables of custom grids. The same neon blue, the same DM Sans, the same WP monogram as the product site. This page follows the same design language.

One source of tokens

tokens.ts from the landing: accent #3D7CFF, navy scale, radius 12, DM Sans self-hosted. Feeds the antd ConfigProvider and the CSS variables of custom grids at once.

Dark theme, both ways

Light and dark themes with a header toggle. The sidebar stays brand-navy in both. Grafana iframes switch theme together with the app, kiosk mode with no extra chrome.

Details that read as a product

WP monogram and favicon, grouped navigation, breadcrumbs with the company name, Russian locale. The statistics page embeds provisioned dashboards: the user enters no UID at all.

1token file for antd and CSS
2themes: light and dark
2Grafana dashboards out of the box
0console errors and warnings
Statistics screen in dark theme with embedded Grafana dashboards
Statistics in dark theme: provisioned Grafana dashboards in a theme-synced iframe, kiosk mode.
06 Method and stack

How my own product is run

The point of this case is not only the features. It is the pipeline that keeps a prototype's speed and a product's bar at the same time.

  1. Prototype first, then build. The idea was proven by three prototypes in July 2024. The multi-tenant architecture came only after the 2024 README pinned the scenarios and entities.
  2. Invariants live in the DB. One active run per basket, transactions and row locks, idempotent write-off. What must always be true is written as a constraint, not a comment.
  3. Tests as a contract. 272 + 11 automated tests, dedicated files for money logic, isolated test databases, an end-to-end basket scenario. A green run is the condition for any merge.
  4. Finish with the eyes. After green tests, a live walkthrough of every screen in both themes, screenshots and demo data. A product should look like a product, not a test rig.

Stack

Python 3.12Django 5.2DRFPostgreSQL 16 psycopg 3schema-per-tenantpytest React 19TypeScriptVite 7Ant Design 6 TanStack Queryhtml5-qrcodeVitest + MSW

Infrastructure

Docker ComposeTraefik v3Grafana OSS Let's Encryptsubdomain per company

Pace

3 prototypes ERP: 8 Django apps engineering method, human-verified
07 Outcome

What this case shows

Product

A real domain: shop floor, money, stock. Tech cards, a QR flow, per-operation payroll and costing are wired into one data loop where every hour of work is visible and priced.

Speed

Three prototypes proved the idea. A production multi-tenant ERP built solo: 8 apps, ~110 API operations, 10 screens.

Culture

272 + 11 green automated tests, a type-checked build, safe defaults, a design system and a make demo runbook. Numbers, not adjectives.

Kirill Sedov

WisePerformer is my own product in progress. This case shows how I work: product thinking, speed and engineering discipline in one loop. If your project needs the same approach, let's talk.

Connect on LinkedIn