Case file
ADCOM SHOP
Point of sale, inventory, repair jobs, and a public storefront for a computer shop, in one app.
In one paragraphFor engineersFor hiring managersThe short version
A computer shop runs its counter, its stock, its repair bench, and its online store on one system instead of a notebook, a spreadsheet, and a marketplace page. End-of-day and monthly reports come out as PDFs.One Express application serving both the staff back office and the public storefront. POS sale orders, inventory with stock movements, service and repair job tracking, Puppeteer-rendered PDF reports, barcode generation and scanning, receipt and label printing, and a Vitest and Supertest suite running against in-memory MongoDB.A computer shop runs its counter, its stock, its repair bench, and its online store on one system instead of a notebook, a spreadsheet, and a marketplace page. End-of-day and monthly reports come out as PDFs.The shop where you get your laptop fixed now tracks every sale, part, and repair job in one place, and sells online from the same stock. I built that.
Choose a lens in the header to reorder this page for your reading.Engineer lens: the engineering story comes before the outcome.Hiring lens: the outcome comes right after the problem; the engineering story follows.Curious lens: the story first, the engineering detail last.
The problem
A computer shop has three businesses inside it: selling things over the counter, fixing things on the bench, and, increasingly, selling online. Each of those usually gets its own tool, and the stock count is wrong in all of them. Repair jobs live in a notebook, the price-check for a walk-in customer means finding someone who knows, and the daily report is whatever the owner remembers.
ADCOM SHOP wanted one system: sell in store, sell online from the same inventory, track every repair from intake to pickup, print the receipts and labels, and get the numbers at the end of the day without anyone adding them up.
What I built
One Express application with a React front end, serving both the staff back office and the public storefront at adcomshop.com.
- Point of sale. Sale orders, receipts, and an in-store price-check screen.
- Inventory. Stock with movements, so every change has a reason and a time, and barcode generation and scanning for products.
- Service and repairs. Repair job tracking with customer management.
- Reporting. Daily, monthly, yearly, inventory, and service reports, rendered to PDF with Puppeteer.
- Printing. Receipts and labels from the browser.
- Storefront. The public site with cart and checkout, selling from the same inventory as the counter.
- Quality. A Vitest and Supertest suite running against in-memory MongoDB, and Zod validation at the API boundary.
The engineering story
One app, two faces. The back office and the storefront are the same Express application with the same inventory underneath, so a sale on the website and a sale at the counter reduce the same stock. There is no sync job because there is nothing to sync.
Stock movements, not stock numbers. Inventory is recorded as movements (a sale, a receipt, a repair part, an adjustment), so the quantity on hand is derived and the history explains it. When a count is wrong, the movements say when it went wrong.
Reports as documents. Reports are rendered to PDF by Puppeteer from the same templates staff see on screen, so the printed daily report is the report, not an export that drifts from it.
Hardware from the browser. Barcode scanning, receipt printing, and label printing all happen from the web app, which keeps the shop on one machine setup and one login.
Tests that run anywhere. The Vitest and Supertest suite runs against in-memory MongoDB, so it runs in CI and on a laptop with no database installed, and every API change is checked before it reaches the shop.
What it changed
The shop runs its counter, stock, repairs, and website on one system. The owner gets daily and monthly numbers as PDFs instead of reconstructing them, and the online shop sells from real stock.