Case study 02 / 05
Enterprise SoftwareSalesync
Enterprise Distribution Platform
- Year
- 2025
- Type
- Enterprise Business Software
- Status
- Developed and deployed
- Role
- Sole Software Engineer — Backend & Business Systems
01
Overview
Salesync is an enterprise distribution and field-sales platform designed around real sales, inventory, collection, route, and treasury workflows.
It combines a backend API, a field-sales PWA, and an administrative BackOffice into one connected operational system.
02
Context
Distribution businesses involve significantly more than recording invoices. A sales operation may include sales representatives, supervisors, assigned routes, customers, warehouse stock, van inventory, collections, product returns, customer visits, treasury settlement, and management reporting.
Salesync was designed to model that complete operational flow rather than treating sales as isolated transactions.
03
The Problem
The objective was to create a centralized platform capable of supporting real distribution operations across multiple roles. The system needed to handle relationships between:
- Sales representatives
- Supervisors
- Routes
- Customers
- Warehouses
- Sales-rep inventory
- Sales invoices
- Collections
- Returns
- Load requests
- Treasury
- Reporting
Each user can only access data and operations relevant to their role — enforced by strong authorization rules.
04
What I Built
I designed Salesync as a modular enterprise platform with three major components.
Backend API
A central ASP.NET Core API responsible for:
- Authentication
- Authorization
- Domain logic
- Sales workflows
- Inventory operations
- Treasury workflows
- Reporting
- Business rules
Sales Rep PWA
A Blazor WebAssembly Progressive Web App that lets field sales representatives work through their operational workflow from a mobile-friendly interface.
BackOffice
An administrative Blazor application for management, operational monitoring, and master-data workflows.
05
Key Capabilities
Identity & Role Management
Authentication is based on ASP.NET Identity and JWT. JWT claims also carry operational context such as SalesRepId where required.
- Admin
- Sales Representative
- Supervisor
- Warehouse
- Treasury
- General users
Sales Representatives
Each rep has a business profile: code, name, phone, branch, representative type, assigned user, supervisor, and operational limits.
Routes & Customers
Field-sales routes carry branch, region, city, area, channel, Go-To-Market classification, category, business unit, and assigned sales representative. Customers are assigned to specific routes.
Sessions & Customer Visits
Reps operate within sessions that form the foundation for daily field activity. Visits are tracked and can result in sales activity, completed visits, or non-sale operational outcomes.
Sales Invoices & Collections
A complete invoice domain with statuses (Draft, Confirmed, Cancelled) and payment states (Pending, Paid, Partially Paid, Overdue). Payments are registered against invoices and flow into treasury and reporting.
Returns
Invoice returns and operational return handling, with reasons such as good product, damaged product, expired product, and wrong delivery.
Inventory & Load Requests
Stock balances, stock movements, sales-rep inventory, and warehouse workflows. Reps request stock through a controlled approval workflow — a controlled movement of inventory instead of arbitrary stock modification.
Pending → Approved / Rejected → Warehouse Confirmed · Cancelled
Supervisor Operations
Supervisors work only with their own reps, team routes, route customers, and operational reports. Authorization is applied at the business-service level, not just by hiding UI elements.
Treasury & Day Closing
Treasury and day-closing workflows connect field operations with financial settlement, tying operational cash activity back to sales activity.
Reporting
Management KPIs: gross sales, net sales, collections, returns, invoice count, visits, active reps, and customers visited. Admin reporting adds branch summaries, sales-rep ranking, and organization-wide views.
Offline-Oriented PWA
An IndexedDB-based local layer with stores for a synchronization queue and routes — the foundation for storing field operations locally and syncing when connectivity returns.
06
Architecture & Engineering
Salesync uses an Onion / Clean Architecture approach, designed so operational modules can evolve without turning the backend into a tightly coupled application.
- Domain separation
- Application services
- Infrastructure isolation
- API contracts
- Dependency injection
- Unit of Work
- AutoMapper
- FluentValidation
- Global exception handling
- Standardized API responses
- JWT security
- Role-based authorization
07
Technical Challenge
One of the hardest parts was translating a real distribution workflow into software boundaries. Sales, inventory, collections, warehouse activity, field visits, supervisors, and treasury all affect one another.
The challenge was keeping those modules connected from a business perspective while avoiding unnecessary coupling in the codebase. I separated responsibilities into domain-oriented services and enforced business rules at the backend rather than relying on frontend behavior.
08
My Role
Sole developer, responsible for:
- Understanding the business workflow
- Domain modeling
- Backend architecture
- Database design
- REST API development
- Authentication
- Authorization
- Business-rule implementation
- Field-sales PWA development
- BackOffice development
- Reporting architecture
- Deployment
- Product-level technical decisions
09
Technology Stack
Backend
Architecture
Security
Frontend
Operations
Source code: private repository
Next case study →
FleetOps
Fleet Tracking & Operations Platform