Joshua Trees sells specialty trees and boulders where no two units are the same. Every sale used to run through a phone call. We shipped a Shopify storefront that replaced it with self-serve browsing by species and size, in two weeks. The hard part: what "inventory" means when the product is a living tree.
The brief was not "build a store." It was "let a buyer find and buy a specific fifteen-foot Joshua tree without calling us first." Those are different problems, and the second one broke the default assumption Shopify is built on.
What did the brief actually ask for?
A catalog a buyer could browse unattended, filtered by species and size, with enough photos to trust a purchase they couldn't walk up to in person. No quoting flow, no live chat requirement, no delivery scheduler at launch — the founder was explicit that the phone call wasn't the enemy, the requirement to make it was.
We scoped four things: a species-and-size-organized catalog, a checkout that could carry freight-class shipping logic, an admin the yard staff could update themselves, and a photo standard consistent enough that a buyer trusted what they were looking at. That was the whole build.
Why Shopify and not a custom build?
Because the timeline was two weeks and the problem was catalog and checkout, not novel logic. Shopify's variant and collection system already solves "organize a large catalog by two axes and let someone check out." Reaching for a custom stack would have spent the two weeks rebuilding commerce primitives that were never the hard part of this brief.
The rule: the platform question isn't "what's the most capable tool," it's "what does this specific brief actually require the tool to be capable of." Joshua Trees required catalog and checkout. It didn't require anything Shopify doesn't already do well.
What was the hard part?
Shopify's inventory model assumes a SKU has many identical units. A boulder does not have a twin. A fifteen-foot Joshua tree is not restocked — it is one physical object that either sells or doesn't. We were mapping a one-of-one physical world onto a platform built for repeatable stock.
We solved it by treating each individual tree or boulder above a certain size as its own product listing rather than a variant of a shared SKU — species and rough size became collections, not variants, and each listing carried its own photo set and a "sold" state instead of a quantity count. Smaller, more uniform stock (saplings, small ornamental boulders) kept the normal variant-with-quantity model, because those genuinely are interchangeable units. Two different inventory models, living inside one storefront, chosen per product class instead of forced into one shape.
What did we cut, and would we cut it again?
Three things did not make the two-week build:
- Live inventory sync with the yard's paper tracking. The founder wanted the site to reflect what was on the lot in real time. We shipped manual "sold" toggles instead and told them: automate this once you know how often a listing needs to flip. It has flipped, on average, a few times a week — manageable by hand. Not automated since.
- A delivery-cost calculator. Freight on a boulder is not a flat rate; it depends on weight, distance, and access to the site. We shipped a simple "request a freight quote at checkout" step instead of a real-time calculator. Building a true calculator would have doubled the timeline for a feature that gets used on maybe one in five orders.
- Custom photography tooling. We considered a guided-capture app so yard staff could shoot consistent photo sets. We shipped a written photo standard (angles, lighting, a scale reference in every shot) instead. A document costs an afternoon. An app costs a sprint.
Every cut held past launch. None has come back as a support request.
What shipped in two weeks?
A Shopify storefront with two inventory models living side by side — one-of-one listings for large stock, standard variants for small stock — organized by species and size, with a written photo standard instead of custom capture tooling, and a freight-quote step instead of a live delivery calculator. Before, every order started with a phone call. After, a buyer could find, evaluate, and pay for a specific tree without one.
What would we do differently?
Write the photo standard before the first product shoot, not during it. We built it in week one, in parallel with the storefront, which meant the earliest listings got reshot once the standard settled. On a two-week clock, a half-day spent finalizing the standard before any camera came out would have saved a reshoot pass we didn't have slack for.
The inventory-model split, in hindsight, was right on the first try — mostly because we asked "which of these products actually behaves like stock" before touching the data model, instead of after.
What does this build confirm?
- "E-commerce platform" doesn't mean one inventory model. When a catalog mixes one-of-one physical goods with genuinely interchangeable stock, model them differently inside the same storefront instead of bending the whole catalog to fit one shape.
- Cut the feature that solves a problem you don't have yet. A live inventory sync and a delivery calculator both sounded necessary at scoping time. Neither has been requested since launch.
- A photo standard is cheaper than photo tooling, and ships faster. Write the standard first; buy or build the app only once the standard proves it isn't enough.
The same instinct — ask what a feature actually needs to do before picking the default shape for it — is the one behind how we scope before a line of code gets written.
Written 2026-08-12 by Naman Barkiya.