Greenbox is a produce-box company delivering to 5,400 subscribers across Perth and Melbourne, with a team of eighteen. The architecture is clean, the domain logic is captured in decision tables and ADRs, but now someone wants to build a delivery tracking system, and the question is whether they should.
Sam is drowning.
Her Tuesday starts at 7am. She’d set her alarm for 6:30 to get ahead of the delivery confirmations, but she hit snooze twice. She showers, eats standing at the kitchen counter, and opens the spreadsheet on the bus.
The spreadsheet has seventeen tabs. One for each courier. One for each city. One for the routes that don’t fit neatly into either. Colour-coded, green for confirmed, yellow for in transit, red for problems. By 8am, five red cells. By noon, twelve.
At 1pm, the Melbourne courier calls. Three boxes didn’t make the morning run. Wrong addresses, mismatched postcodes from the new farm onboarding data. Sam spends forty minutes sorting it out while Perth emails stack up.
At 2:30, a Perth subscriber messages: “My box hasn’t arrived. It’s 38 degrees and I’ve got dairy in there.” Sam checks the spreadsheet, calls the courier, sits through four minutes of hold music. Driver is running late. ETA two hours.
At 4pm, five Melbourne customers email asking “where’s my box?” Five calls. Five individual emails. The courier doesn’t have a self-service tracking page. Everything goes through Sam.
By 6pm, the red cells outnumber the green. She’s been on the phone for four straight hours. She missed two complaints that came in while she was handling the Melbourne courier. One is from a subscriber who’d flagged a problem last week. Two problems in two weeks. The subscriber has cancelled by the time Sam replies.
Sam sits in her car in the car park. It’s dark. July in Perth, the sun gone by half six. She puts her hands on the steering wheel and cries. Quietly, with the engine running and the heater on. She cries because she’s been at this for eleven hours and she lost a subscriber anyway.
Then she feels angry at herself for crying. She’s twenty-seven. She handles things. That’s who she is.
She calls her mum.
“You’re not a machine, Samara,” her mum says. Her mum only uses her full name when she’s worried.
On Monday, at standup, Sam says what she’s been needing to say. “I need a system. Delivery tracking. Real-time notifications so customers stop emailing me. Customers are comparing us to Freshly. They’ve got tracking in their app. Our customers email me and I call a courier.”
Tom’s instinct
Tom has been watching Sam struggle. He solves problems with code. That’s who he is.
“Give me a week. I’ll build it. Courier API integrations, customer-facing status page, automated notifications. Five days, maybe six.”
He’s probably right. The code isn’t hard. He’d already scoped it in his head.
Charlotte has been listening. She doesn’t disagree with Tom’s estimate. She disagrees with the question.
“Before we talk about how to build it, let’s talk about whether we should.”
Tom’s face changes, that slight lean back that Priya reads as “I’m about to argue.” He’d already imagined the architecture.
“Cheap to build,” Charlotte says. “But is it cheap to own?”
The map
Charlotte introduces Wardley Mapping. The technique comes from Simon Wardley. Plot everything in your value chain on two axes: visibility to the user (vertical) and evolution from custom to commodity (horizontal).
Things on the left are novel, custom, your competitive advantage. Things on the right are well-understood, standardised, commodity. Everything moves left to right over time.
The team spends an hour placing Greenbox’s capabilities on the map. Lee dials in, he’s still involved for strategic sessions.
Left side (custom, competitive advantage): Box curation. Substitution engine. Farm relationships. Nobody else has these.
Middle: Customer notifications. Visible but not unique.
Right side (commodity): Delivery tracking. Route optimisation. Payment processing. Solved problems. Hundreds of providers.
Lee, who’s been quiet on the call, says something that stays with the team. “Look at the map. Everything on the right side, delivery tracking, route optimisation, payment processing. Freshly has too. They probably have better versions. You will never out-deliver Freshly on logistics. But look at the left side. The farm relationships. The curation. The substitution engine that knows Dave’s zucchini over-promises by twenty percent. That column, they don’t have. That column, they can’t buy.”
Maya shares something from last week. Dave’s son Ben, thirty, more comfortable with a phone than his father, had started using the farm portal to submit availability. Dave watched him do it in the farmhouse kitchen, squinting at the screen.
“That’s more technology than I’ve used in fifty-eight years,” Dave had told her. A pause. “It’s quicker than calling you, though.”
The build-vs-buy calculus
They work through the numbers.
Build with LLM: Tom estimates five days ($5,000). But the Perth courier uses one API, Melbourne uses a different one, Sydney will be a third. Each changes their API periodically. Maintenance: ~4 days/year at $1,000/day. Year 1: $9,000. Year 3: $17,000. Gets worse with every city.
Buy: A tracking platform that integrates with every Australian courier. $500/month. Year 1: $6,000. Year 3: $18,000. If a courier changes their API, the platform handles it.
Tom looks at Year 1 and says “building is cheaper.” Charlotte says “look at Year 2.” By month fourteen, the maintenance on the build catches the subscription cost, and from there the lines diverge. The build gets more expensive with every city and every API change. The buy stays flat. By Year 3 the build costs more, and that’s before you count the four days a year where Tom is debugging courier API changes instead of building features.
Charlotte puts the columns side by side.
“The LLM made building cheaper than it used to be. Five years ago, this would have cost $25,000. Now it’s $5,000. That’s real. But the maintenance cost didn’t change. The LLM helps you build fast. It doesn’t help you maintain it forever.”
Build what differentiates you. Buy what’s commodity.
Tom builds it anyway
The team signs up for the third-party platform. Priya integrates it in two days.
But Tom can’t let it go. Over the weekend, he builds the tracker anyway. The LLM generates the Perth courier API integration in three hours. Customer notifications on Saturday afternoon. By Sunday evening, a working prototype, polls the API, updates statuses in real time, sends SMS when a box is thirty minutes away.
On Monday, he shows the team. “I know we went with the third party. But this is better. The notifications are more granular.”
Charlotte looks at it. “It’s good work. Now show me the Melbourne integration.”
Tom opens his LLM. The Melbourne courier uses completely different authentication (OAuth2 instead of API keys), different status codes, different webhook formats, different time zones. Three hours later, the Melbourne integration works. But it’s ugly, conditional logic mapping between two incompatible APIs.
“Now imagine Sydney,” Charlotte says. “And Adelaide. And Brisbane.”
Tom looks at his weekend project. He looks at the third-party platform, which supports every Australian courier out of the box.
“Yeah. Fair enough.”
The prototype goes in the bin. Charlotte doesn’t frame it as failure.
“You learned something real. You confirmed the analysis with your hands. And now you’ll never wonder ‘what if we’d built it ourselves?’ The Perth integration was easy. The second one was hard. The fifth one would have been a nightmare.”
She glances at the Wardley Map. “And every day you spent building that tracker is a day Sam spends on the phone because it’s not live yet. Delivery tracking is a commodity. Sam’s judgement is not. We’re burning a scarce resource on a commodity task.”
Tom looks at Sam. She doesn’t say anything, but her expression says enough.
Using the map
The delivery tracking decision becomes a template. Over the following weeks:
Customer analytics dashboard. Commodity. Third-party. $150/month.
Seasonal recipe suggestion engine. Custom, left side of the map. Nobody else matches recipes to Greenbox’s specific box contents. Tom and the LLM build a first version in four days.
Email marketing. Commodity. They already use Mailchimp.
Each decision takes ten minutes of mapping instead of two hours of debate.
When to use Wardley Mapping
- When someone says “we should build this” and someone else says “can’t we just buy it?”, and neither has a framework for resolving it.
- When developer time is being spent on something that feels like it should be someone else’s problem.
- When the build cost is low enough that building feels obvious, but the long-term implications aren’t clear.
When not to use it
- When the answer is obviously commodity, just buy it.
- When the answer is obviously custom and core, just build it.
- When the decision is small enough that mapping costs more than being wrong.
What comes next
Greenbox is now two squads across two cities. Eighteen people. The bounded contexts helped the code stay clean. The Wardley Map helped the team make strategic decisions. But the squads keep surprising each other. Perth changes the subscription API without telling Melbourne. Melbourne builds a notification system that duplicates Perth’s. A subscriber moves from Perth to Melbourne and gets contradictory messages.
The code has boundaries. The teams don’t. That’s the problem two squads need to solve, before the next API change breaks something nobody saw coming.
The next chapter, API Contracts: Two Squads, One Direction, publishes around 25 August.