Case study · SL3D RC · Custom store
First real orders went through the morning the new store launched.
All a customer needs to request a custom order: a name and an email.
Custom requests that were duplicates, before I fixed the form.
The team's own workbook still drives the catalogue.
01 · The situation
SL3D RC makes 3D-printed tire inserts for RC crawlers. The team already ran the business from a workbook on Google Drive. Cam keeps it up to date. Neal answers custom requests by hand.
So I built the store around how they already work.
02 · The build
The whole store lives in one custom plugin. A finder helps customers pick the right insert. Every insert ID is the SKU, with shared stock across the products that use it, and a reverse lookup that works the other way.
An Update from sheet button pulls the catalogue straight from the team's workbook. Cam keeps editing the spreadsheet he knows. The store keeps up.
03 · Custom orders
So the custom order form asks for a name and an email, and everything else is optional. Neal prices the job, one line per set, and the site emails the customer a checkout link. They buy it like any other order, with their own address and their own shipping.
I also removed a button that created orders nobody had asked for.
04 · After launch
The store moved to a server I manage on 30 September. First real orders went through that morning.
Then I watched what customers actually did. 11 of the first 26 custom requests were duplicates, so I stopped those. I changed the packing slip to show the tire, not the size code, so shipping labels make sense. And I fixed Apple Pay orders so they link back to the request they came from.
“The numbers speak for themselves – I went from a 9-5 job to doing what I love for a living thanks to Alec and his amazing work.”
Why it matters
Good systems fit the people who use them. Cam kept his spreadsheet. Neal kept his process. The store learned both.
See how the roadmap works →Thirty minutes. Same-day reply. If I'm not the right fit, I'll say so.
