Coast Technology
RV dealers build add-on packages, invoice them and see profit per deal
For Coast Technology, which serves RV dealership groups, we built a role based platform: packages built from inventory, invoices printed from them, and a dashboard of revenue, profit and best selling packages. Managers see only the locations assigned to them.
Automotive & DealershipsPackage sales and invoicing platformBuilt from zero
The challenge
Advisers at RV dealership groups needed to build packages from inventory and invoice them through financing, and managers needed profit per deal for their own locations only.
What we did
A React and NestJS platform with five roles scoped to locations, packages assembled from inventory under the deal rules, PDF invoices with explicit statuses, and profit reports.
The outcome
We delivered the platform to Coast after test cases for every module, access control rounds and production testing.
- Roles
- Super, admin, manager, service and camping adviser
- Sales flow
- Packages from inventory, invoices as PDF
- Reporting
- Revenue, profit per deal, dealer leaderboard
- Access
- Managers limited to their assigned locations
The starting point
Coast Technology, a software company serving RV dealership groups, wanted a platform for the add-on packages those groups sell. Each group runs several dealerships and locations, where service and camping advisers sell to customers and managers track the results.
What had to change
Advisers needed to build service and accessory packages from inventory and invoice them through financing. Managers needed to see what each deal earns and which packages sell, limited to the locations they run.
What could not break
- Managers see only the locations assigned to them, in every module
- Only service and camping advisers create invoices
- A package holds at least two products, or more than one unit of one product
- An invoice's delivery date is never before its invoice date
- Inactive users cannot sign in
The calls we made
We encoded the deal rules in the backend, so packages, invoices and reports follow them and each person sees only what their role and locations allow.
- 01
Estimated two ways, built in React
We estimated the platform both in WordPress and in React during scoping, and built it in React and Material UI as an application with its own roles, rules and reports, on a NestJS API designed from an entity relation diagram.
Ruled outA WordPress build, estimated next to React during scoping.
- 02
Packages built from inventory
Each package is assembled from inventory items that carry labor time, cost and retail price, so revenue and profit come out per deal, and a package must hold at least two products or more than one unit of one.
- 03
Access by role and location
Five roles and location assignments decide what each person sees across modules, enforced by a roles guard in the API and tested in dedicated access control rounds.
- 04
A catalog loaded in bulk, with fixed categories
Dealers load inventory one item at a time or by bulk file upload that the backend parses, and service and RV type are fixed lists, so packages, invoices and reports rely on clean categories.
How the system fits together
What we built
Users, locations and roles
Dealerships, franchise locations and users with five roles, managers limited to their assigned locations, inactive users blocked from signing in, and an activity log.
Inventory and packages
Inventory items carry RV type, service, labor time, cost, retail price and images, loaded one at a time or by bulk upload, and packages are assembled from them under the quantity rules.
Invoices
Advisers create invoices from packages, with statuses such as Pending Financing and paid and checks on delivery dates, printed as PDF from an HTML template with the deal's data.
Dashboard and reports
Revenue, profit and loss, average profit per deal, best-selling packages and units sold, plus sales, type, part, customer and dealer leaderboard reports by date range.
How it works
Stock
Admins load inventory items with cost, labor time, retail price and images, one at a time or in bulk.
Package
Packages are assembled from inventory items, with at least two products or more than one unit of one.
Sell
A service or camping adviser creates an invoice from a package for a customer and prints it as PDF.
Close
The invoice carries its status, from Pending Financing to paid.
Track
Managers see revenue, profit per deal and the dealer leaderboard for their own locations.
A closer look
What changed
We delivered the platform after production testing, with every module integrated, test cases written for each and access control tested in dedicated rounds. It brings packages, customers, invoices and profit reporting into one system, scoped by role and location.
- After production testing and fixes
- Delivered
- Test cases for every module
- QA
Under the hood
- Datics role
- Product built by Datics
- Stack
- React with Material UI and MUI DataGrid on the front end, NestJS with TypeORM migrations, seeders and transactions on the back end, REST APIs and an email queue.
- Access
- A roles guard with five roles, managers limited to their assigned locations in every module, inactive users blocked and an activity log.
- Documents
- Invoices rendered from an HTML template to PDF with each deal's data, and a media storage module for inventory images.
- Deployment
- A development environment on AWS during the build, then production testing and fixes before delivery.
Cloud and infrastructure
Apps and APIs
Also in the stack
How it shipped
Research and scoping
A requirements specification, wireframes, user stories and client discussions, then estimates, milestones, a scope document and a Figma review.
Front end sprint
Every screen in React and Material UI to the client's brand guideline, from the dashboard to package, invoice and report pages, with tablet layouts.
Back end sprint
A NestJS API from an entity relation diagram, with roles, CRUD, invoices, PDF generation, reports, bulk import and a first development environment on AWS.
Integration and QA
Every module integrated, test cases written for all of them, then responsive testing down to tablet size, access control rounds and production testing.
Delivery
The platform went to Coast after production testing and a final round of fixes to report date ranges, dashboard figures, package rules and invoice validation.
Scoped before built
Requirements, wireframes and user stories came first, then estimates, milestones and a scope document checked against the Figma designs before the first sprint.
Sprints with a full QA pass
Screens, back end and integration each had their own sprint with scrums, then test cases, access control rounds and production testing before delivery.
What this unlocked
The same structure, inventory with cost and labor time, explicit invoice states and access scoped by location, is the groundwork any later reporting or AI feature on a dealership product needs.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.