Consolidating Multi-Store Operations for a Retail Platform Operator - PROJECT RENT
The System
Project Rent operates a retail platform that combines two distinct business structures under one roof: external tenant stores on a commission or profit-sharing model, and directly operated stores. For this engagement, the portfolio consisted of multiple stores. The dashboard I built is a single-file web application that ingests monthly POS exports, standardises data across all three store types, and produces a single view of the platform's operational and financial position — along with one-click access to settlement documents for each tenant.
Role & Fit
I ran the project end-to-end as a solo build — planning, requirements definition, data model, system design, implementation, and QA. The engagement sat at the intersection of two things I already had: deep familiarity with Project Rent's operating model from working with them on multiple coffee and retail projects, and the discipline of separating true master data from project data that I had developed on the Husk Master Planner engagement. This project applied that discipline to a different industry — retail platform operations rather than interior contracting.
Context
Project Rent's operational complexity comes from a simple fact: the three stores in the portfolio each make money differently. It is a system in which a few stores generate revenue, and Rent takes a percentage of sales. Basket is direct, so the P&L runs on cost of goods, labour, and margin rather than commission. Staff were reconciling these three models across separate Excel files every month, and errors were compounding at the settlement step.
Challenges
Four problems to solve. First, unify three different revenue-recognition models into a single data structure without flattening the differences — commission, profit-share with utilities, and direct P&L each had to preserve its own logic. Second, automate the ingestion of POS exports so that monthly data entry is no longer manual. Third, produce settlement documents that tenants could receive as-is, with the correct commission base. Fourth, give the operator a single dashboard view that answers the real question — not 'what are my tenants earning' but 'what is Project Rent actually keeping'.
Approach & Execution
The system was scoped as a single HTML file with Chart.js and SheetJS on CDN, localStorage for state, and a drag-and-drop upload zone for POS files. The data model was the key design decision: a single nested structure keyed by store and month, with a type field ('external' vs 'direct') that routes each store to the appropriate calculation. Commission is computed from Hitit sales only, profit-share uses total sales, and direct stores run their own P&L. Settlement documents are generated via SheetJS directly from the same dataset, so the numbers on the tenant's settlement file and the operator's dashboard cannot diverge. Auto-generated issues surface the conditions an operator actually needs to see — month-over-month revenue drops, utility cost ratios crossing threshold, direct store margin going negative — rather than a generic analytics feed. Also, the custom sales analysis logic I developed was implemented to enhance its analytical capabilities.
Outcomes
Project Rent now runs its multi-store operations from one view. Monthly POS files are uploaded rather than entered; commissions, profit-shares, and direct-store P&Ls reconcile to the same source; tenant settlement documents are generated in one click with the correct commission base; and the operator sees the platform's real financial position — not a stack of store-level Excel files that have to be read together. The system is in active use and has become the default settlement and review tool across the monthly cycle.