Technical leadership · Storage and logistics
StoragePal: Improving the software behind a storage business.
I lead development of the platform behind a Paris storage business, from staff tools and customer bookings to pricing and payments.
- +34%
- transport revenue in the year after launch vs the year before
- 0.884s
- median catalog server response, down from 9.1 s
- 3 → 1
- pages in the payment flow
Transport: 12 months after launch vs the 12 months before. Catalog: median of 15 runs per version on a local benchmark. Reviewed September 2026.
The short version
- 01RoleLead devI took over a live platform and improve it in stages, with other developers.
- 02Staff tools12 pagesBackoffice lists now share one system for filters, sorting, and exports.
- 03Catalog9.1 s → 0.884 sMedian server response on a local benchmark, after caching the shared catalog.
- 04Payments3 → 1Pages in the payment flow, plus one clear rule for what a customer owes.
- 05Transport+34%Transport revenue in the 12 months after launch, compared with the 12 months before.
- 06AIRules decideThe assistant suggests items. The catalog and pricing rules decide what is sold.
A business already in operation
StoragePal customers book collection, storage, and return of their things online. I took over the existing platform and improve it in stages.
- CustomersBook collection, storage, and return online.
- PlatformStaff manage orders, stock, invoices, and payments.
- WarehouseThe SPS app receives, places, and returns items.
My part
PrioritiesSpecsCode reviewMajor features
Other developers
ReportingCRM integrationReservations
I also built the SPS warehouse app end to end.
Start where staff were blocked
Staff use the inventory and reservation screens every day. I fixed those first.
Before
- Filters could take minutes, or time out
- Big exports could run the server out of memory
After
- Filtering and paging run in the database
- Exports run in batches
- 12 backoffice pages share one system for columns, filters, sorting, and exports
Still open: a few heavy computed columns cannot be sorted, and some exports need a filter to finish in time.
Cache what customers share
The catalog repeated the same database work on every visit. I cut queries and added indexes. Then I built the page on the server from cached data.
Shared by everyone: cached
- Product data, stored per language
- Cleared when staff change the catalog
- Expires after 24 hours to catch anything missed
Some import paths do not clear the cache yet. The 24-hour expiry covers them.
Personal: read fresh
- Cart quantities, merged in on every request
- Custom items, kept out of the shared cache
- 9.1 s → 0.884 s
- Median server response time, not full page load. Local benchmark: 15 runs per version, same database.
Sort out what is owed before charging
Unpaid amounts carried over into later invoices. The system could still treat them as separate debts, so more retries could charge the wrong amount.
- Invoice 1Left unpaid.
- carried into
- Invoice 2Includes the unpaid amount.
- carried into
- Current invoiceHolds the full amount owed.
One rule: the current invoice, at the head of the chain, is what the customer owes.
Payment rules
- Charge the current invoice, and nothing else
- Never start a second payment while one is in progress
- Retry failed payments, and send blocked ones to a review queue
- Check the payment state again before each reminder
- 3 → 1
- pages in the payment flow
Price transport by the real job
Quotes used to be flat by region. Now one engine prices each job from its real details. Customer care and logistics helped shape the rules.
Before
One flat price per region, whatever the job.
After: four inputs
- Distance
- Real driving distance
- Vehicle
- The size the job needs
- Crew
- How many people
- Access
- Floor and elevator
Collections and returns use the same engine.
After launch
- +34%
- transport revenue in the 12 months after launch, compared with the 12 months before
Order volume and customer mix also changed in that time.
Keep AI proposals inside the business rules
The shopping assistant turns a description or a photo into a proposed cart. The model helps. The business rules stay in charge.
- DescribeThe customer types or sends a photo.
- SuggestThe model proposes items.
- CheckThe server rejects unknown items, limits quantities, and sets prices.
- EditThe customer adjusts the cart. Every line is priced again.
Who decides what
- The modelHelps the customer describe what they need
- The catalogDecides what can be sold
- Pricing rulesDecide the price of every line
Product walkthrough
Visit StoragePal