Case study 02 / 05

Enterprise Software

Salesync

Enterprise Distribution Platform

Year
2025
Type
Enterprise Business Software
Status
Developed and deployed
Role
Sole Software Engineer — Backend & Business Systems
Enterprise Software.NETBackend EngineeringDistributionField SalesPWA

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

C#ASP.NET CoreEntity Framework CoreSQL ServerREST APIs

Architecture

Onion ArchitectureUnit of WorkDependency InjectionDTO-based contractsAutoMapperFluentValidation

Security

ASP.NET IdentityJWT AuthenticationRole-Based Authorization

Frontend

Blazor WebAssemblyBlazor Web AppProgressive Web App

Operations

Swagger / OpenAPIGit / GitHubDeployment & environment configuration

Source code: private repository

Next case study →

FleetOps

Fleet Tracking & Operations Platform