Maya runs the coastal track in Fremantle at 5:30 every morning. It’s the only time her mind is quiet. This morning it isn’t quiet at all.
The seed round closed yesterday. The terms are sitting in her inbox, printed out on her kitchen table, and playing on repeat in her head: reach 200 active subscribers within three months, and the next round of funding follows. Miss the target, and GreenBox is done.
She finishes the run, showers, and eats breakfast standing up in the rented cottage she shares with Nadia. On her desk in the spare room, next to a monitor and a stack of seed-round paperwork, there’s a framed photo of her parents’ farm outside Margaret River. The farm that became a subdivision when her father sold it during her second year at university. She touches the frame on the way past, the way other people touch a lucky charm.
GreenBox is a small startup connecting local farms with subscribers who want weekly produce boxes. Fresh seasonal vegetables, delivered to your door, sourced from farms within fifty kilometres. Simple concept. Maya grew up watching her parents – first-generation immigrants from Taiwan – convert their dairy farm to mixed organic produce. A brutal transition that nearly bankrupted them. She knows the supply side cold.
The team is five people. Tom is the senior developer – 38, two kids, the kind of programmer who builds side projects after bedtime because making things is how he processes the world. Priya is the other developer – 29, quiet, precise, recently moved to Perth from Melbourne for this job, her first startup. Jas handles design and product – she joined because Maya’s pitch about local food reminded her of her grandmother’s vegetable garden in Adelaide. Sam does everything else: marketing, operations, the odd customer support email when they eventually get that far.
Maya has a clear picture of the business in her head. She describes it in the kickoff meeting: “Farms list what they have each week. Customers subscribe to a box size. We match supply to demand, pack the boxes, and deliver.”
Sounds straightforward. The team gets to work.
Week one
The output is incredible. Tom has Claude open in one tab and his IDE in the other. He describes the subscription model he wants, and the LLM generates a complete Stripe integration, data models, signup flow – all in an afternoon. He’s shipping pull requests faster than he ever has in his career.
Priya does the same with the farm portal. She prompts for an inventory management screen, gets a working prototype back, tweaks it, deploys. By Wednesday she has a portal where farms can list their available produce: tomatoes, 50kg, $4/kg.
Jas uses an LLM to generate a full set of UI mockups for a box customisation page where subscribers can pick which items they want each week. Customer delight angle – let people choose exactly what goes in their box.
Slack is buzzing with screenshots and pull requests. The team is shipping faster than any of them expected. Tom messages the group: “This is the most productive week I’ve ever had.” Everyone agrees. It feels like they’ve cracked it.
When the code is ready, Tom deploys by SSH-ing into the server from his laptop and running a script he wrote on the first day. It takes about twelve minutes. Nobody else has the credentials or knows the steps. That’s fine, Tom thinks – he’s the only one writing code that matters right now.
Week two
Maya reviews what the team has built.
The subscription system looks impressive – lots of code, clean UI, working payment integration. But Tom has assumed the box contents are fixed – the same items every week. “No,” Maya explains. “The whole point is that contents change based on what farms have available that week. Seasonal produce. That’s what makes it different from a supermarket delivery.”
Tom’s subscription model doesn’t account for variable contents at all. The data model is wrong. The LLM generated exactly what he asked for – the problem is he asked for the wrong thing. That’s a substantial rewrite.
Priya’s farm portal works, but she has questions nobody has answered. How far in advance do farms need to commit their availability? Can they update quantities after a deadline? What happens when total supply across all farms doesn’t cover all subscriber orders? She’d been guessing at the answers and feeding those guesses to the LLM, and some of those guesses are wrong.
Jas’s customisation designs are beautiful. Maya looks at them and says, “Customers don’t pick items. We curate the box. That’s the value proposition – they trust us to give them good stuff, and they don’t have to think about it.”
The customisation flow is entirely wasted work. All those LLM-generated mockups, binned.
Week three
The team tries to course correct. Tom prompts Claude again: “Rebuild the subscription model to support variable weekly contents based on farm availability.” The code comes back in twenty minutes. It’s clean, well-structured, has tests. Tom is pleased.
Then Maya asks: “What happens when a farm can’t supply what they promised?”
Tom looks at the code. There’s no concept of supply shortfalls. He prompts again: “Add handling for when farm supply doesn’t meet subscriber demand.” Claude generates a substitution system that randomly swaps items. Maya shakes her head. “You can’t just swap randomly. Carrots for parsnips, sure. Carrots for lettuce? Nobody wants that.”
Tom prompts again. And again. Each iteration gets closer, but each one surfaces a new question nobody had thought to ask. The LLM is extraordinarily helpful at generating code. It’s just that nobody can tell it what the code should do.
Meanwhile, Priya has paused the farm portal entirely. She has a list of questions and nobody to answer them: How far in advance do farms commit? Can they change quantities after a deadline? What units do they report in – kilograms, crates, “enough for about forty boxes”? She asks Maya, but Maya is in back-to-back meetings with courier companies trying to figure out delivery logistics.
Jas is redesigning the customer experience without customisation, but now she’s unsure what the customer actually sees each week. A preview of what’s coming? A surprise? A notification after packing? She asks Maya. Maya says “I’ll think about it” and doesn’t get back to her for three days.
Week four
Tom’s subscription model v2 is working – sort of. He demos it to Maya on Monday. She spots a problem immediately: “This charges customers on signup day. We need to charge them on delivery day, because we don’t know what’s in their box until the morning we pack it.”
Tom stares at the screen. The entire payment flow assumes charge-on-signup. The data model, the Stripe integration, the receipt emails – all of it. He could ask the LLM to restructure, but the last three restructures have each introduced new assumptions that turned out to be wrong.
“I’ll fix it,” he says, but the energy has gone out of his voice. He’s thinking about his brother Marco at the family Christmas, asking “how’s the little startup going?” in that tone that manages to be both supportive and pitying.
Priya, still blocked on the farm portal, starts helping Tom with the subscription rewrite. Jas, waiting for answers about the customer experience, redesigns the landing page instead – at least that’s something she can do without needing decisions from Maya.
Sam sends a cheerful Slack message: “Customer #1 just emailed asking when their first box arrives! The pilot subscribers are getting restless.” Nobody knows the answer. Even Mrs Patterson on Stirling Highway has asked twice now.
New questions keep surfacing:
- What happens when a customer is allergic to something in this week’s box?
- Do farms get paid per item, per box, or per week?
- Who decides substitutions when a farm can’t deliver what they promised?
- What about delivery logistics – own drivers or a courier?
- What if a customer wants to skip a week on holiday?
The LLM is still generating code fast. But each answer raises two more questions, and the team keeps building on assumptions that turn out to be wrong. The velocity is high. The progress is circular.
Four weeks in, the team has a subscription system built on wrong assumptions (twice), a farm portal that nobody’s sure how to finish, a discarded set of designs, a landing page nobody asked for, and a growing list of questions that should have been answered before anyone opened an IDE. Tom’s git log has more reverts than merges. Maya needs to talk to Dave Morrison about supply commitments, but she hasn’t found the time.
They’re not lazy. They’re not bad at their jobs. The LLMs aren’t the problem either – they did exactly what they were asked, impressively fast. The problem is that nobody understood what to ask for. The team started building before they understood the problem, and the LLMs just helped them build the wrong thing faster.
The expensive kind of learning
Every one of those surprises was knowable. Maya had the answers – or at least knew where the open questions were – but nobody thought to ask systematically. The team assumed they understood the domain because the concept sounded simple.
This is incredibly common. I’ve seen it in startups, in enterprise teams, in agencies. LLMs have made it worse, not better, because the sheer speed of code generation disguises the lack of understanding. When it took two weeks to build something wrong, you noticed after two weeks. When the LLM builds it wrong in an afternoon, you might not notice until you’ve built three more things on top of the wrong foundation. The velocity feels incredible. The progress is an illusion.
“It’s just a…” is one of the most expensive phrases in software development. And “the LLM can build that in an hour” is its dangerous new cousin.
The cost isn’t just the wasted code. It’s the trust erosion. Tom is frustrated because his work got thrown away – twice. Jas is frustrated because nobody told her the customisation premise was wrong. Priya is blocked. Maya is wondering if she hired the right people. Everyone’s doing their best, but the team is pulling in different directions because they never built a shared understanding of what they’re actually building.
The retro that changed everything
Maya’s friend Lee drops by the office on a Friday afternoon. They’d met at the Margaret River farmers’ market six months earlier – Maya buying produce for a dinner party, Lee buying coffee, and a twenty-minute conversation about supply chains that turned into a friendship. Lee spent twenty years in enterprise consulting before semi-retiring to the coast. He’s 52, surfs badly but persistently, and has the calm manner of someone who’s watched a lot of teams struggle with the same problems. He can feel the tension the moment he walks in. Tom is quiet. Priya is staring at a Jira board full of blocked tickets. Jas is redesigning the landing page for the third time because nobody will answer her questions about the customer experience.
“When was the last time you all stopped and talked about how the work is going?” Lee asks.
Maya looks blank. “We have standups.”
“Not standups. A proper retrospective. Where you actually talk about what’s working and what isn’t.”
Maya is sceptical – they’re burning runway and the last thing they need is another meeting. But Lee pushes gently: “Ninety minutes. I’ll facilitate. If it’s a waste of time, I’ll buy the team lunch.”
They gather in the meeting room on Monday morning. Lee draws two columns on the whiteboard – “What went well” and “What didn’t go well” – and hands out two colours of sticky notes.
“We’re going to run a proper retrospective,” he says. “Five stages. It’ll take about ninety minutes. I know that feels like a lot when you’re burning runway, but I promise it’ll be worth it.”
Stage one: set the stage. Lee starts with the Retrospective Prime Directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time.” He reads it aloud and asks the team to actually sit with it for a moment.
“This isn’t a blame session. We’re here to understand what happened and decide what to do about it. Before we start, I want one word from each of you. How are you feeling right now?”
Tom: “Frustrated.” Priya: “Stuck.” Jas: “Confused.” Sam: “Anxious.” She has 47 unread emails from pilot subscribers on her phone. She reads them before bed most nights, but she hasn’t told anyone that. Maya pauses. “Guilty.”
Lee nods. “Good. That’s honest. Let’s work with that.”
Stage two: gather data. “Green notes for what went well. Pink notes for what didn’t. One thing per note, as many as you want. No talking – just write.”
The team writes for five minutes. Lee tells them to put the green notes on the left side of the board and the pink notes on the right, then read each one aloud as they place it.
The green side is thinner than the pink side, but it’s not empty.
Tom: “LLM code generation is genuinely fast. I’ve never shipped this much code this quickly.” And: “The Stripe integration works perfectly. Payment flow is solid.”
Priya: “I identified the farm portal questions early – the problem wasn’t spotting them, it was getting answers.”
Sam: “We have pilot subscribers. People actually want this product.”
Jas: “The landing page is good. The brand identity works.”
Maya: “The team is motivated and hardworking. Nobody’s coasting.”
Then the pink side.
Tom: “I’ve rebuilt the subscription model twice. Both times I asked the LLM to generate it, both times it was wrong, and both times I didn’t find out until Maya looked at it.”
Jas: “I designed a whole customer experience that we’re not using. Nobody told me the customisation premise was wrong until I’d finished.”
Priya: “I’ve been blocked for two weeks waiting for answers about how farms work. I keep guessing and getting it wrong.”
Sam: “Pilot subscribers are emailing me asking when their first box arrives. I don’t know the answer.”
Maya, reading her own note back: “Everyone is frustrated with me. I have the answers but I’m not sharing them fast enough.”
Stage three: generate insights. Lee asks the team to stand up and look at the wall. “Let’s group the pink notes that seem related. Move them around, cluster them.”
Priya puts her “blocked waiting for answers” note next to Tom’s “didn’t find out until Maya looked at it.” Jas adds her customisation note to the same cluster. Sam’s note goes there too.
There’s one large cluster and a few stragglers.
“What do you notice about that big group?” Lee asks.
Tom sees it first. “They’re all the same problem. Maya understands the business. We don’t. And building stuff without that deep understanding isn’t working. I’m prompting an LLM to write code, but I’m describing the wrong thing because I don’t know what the right thing is.”
Priya nods. “The LLM does exactly what I ask. The problem is I’m asking the wrong questions.”
Lee: “Now look at the green side. What do you notice there?”
Jas reads them again. “We’re not bad at our jobs. The code quality is high. The speed is real. We have customers who want the product.”
“Right,” Lee says. “So the tools aren’t the problem. The speed isn’t the problem. The people aren’t the problem. The problem is that one person” – he looks at Maya – “has the domain knowledge, and everyone else is guessing. The LLMs made that worse, not better, because the guesses turned into working code before anyone could catch them.”
The room goes quiet.
Stage four: decide what to do. “We’ve got the insight,” Lee says. “Now we need actions. Let’s brainstorm first – quantity over quality. What could this team do to fix the root cause? Write one idea per sticky note. No filtering, no judging. Two minutes.”
The notes come fast.
Tom: “Daily check-ins with Maya.” And: “Maya reviews every PR before merge.” Priya: “Shared document of all business rules.” And: “Weekly domain Q&A session.” Jas: “Pair with Maya on every design decision.” Sam: “Record Maya explaining the business on video.”
Six ideas in two minutes. Lee puts them all on the board.
He reads them slowly, then steps back. “Look at these. Daily check-ins with Maya. Maya reviews every PR. Shared business rules document. Weekly Q&A. Pair with Maya on designs. Record Maya explaining the business.” He pauses. “What do they all have in common?”
Priya sees it. “They all depend on Maya. Every single one puts Maya at the centre.”
“Right. These are all ways to get knowledge out of Maya’s head, one conversation at a time. They’d work – slowly. But there’s a technique that does most of what these ideas are reaching for, all at once. It’s called Event Storming.”
Lee explains: “You get the whole team in a room – plus your farming contacts if you can – and you spend a few hours mapping out how the business works. Not architecture diagrams, not user stories. Just: what happens, in what order, and where are the hard parts. Everyone writes sticky notes. Everyone puts them on a wall. The shared understanding that these six ideas are trying to build one conversation at a time? Event Storming builds it in an afternoon.”
He writes it on the board as a seventh idea. “This doesn’t replace all of your ideas. But it addresses the root cause that most of them are trying to fix: the domain knowledge is in one person’s head and needs to be visible to everyone.”
“Now let’s narrow down. Dot vote: two dots each. Put them on the actions you think would have the most impact. I’ve put my suggestion on the board, but this is your team and your decision. Vote for what you believe will make the biggest difference – even if it’s not what I suggested.”
The Event Storming suggestion gets eight dots out of ten. The daily check-ins get two. The rest get zero or one.
Lee nods at the board. “That’s your call, not mine. I would have voted the same way, but what matters is that you chose it. If I’d walked in and said ‘do Event Storming,’ you’d be doing it because I told you to. Now you’re doing it because you’ve seen the problem and you believe this is the best response. That’s a different thing entirely.”
Maya looks unconvinced. “So the answer is… sticky notes.”
“Sticky notes. The whole team walks out with the same picture of the business. The misunderstandings that just cost you four weeks? They come out in the first hour, when they’re cheap to fix.”
“You’ll feel like you’re going slower,” Lee adds. “You’re not. You’re just putting the learning where it’s cheap – on sticky notes and whiteboards instead of in pull requests and production incidents.”
Stage five: close. Lee asks one last thing. “Before we leave, I want each person to say one thing they appreciated about someone else these past four weeks. Doesn’t have to be big.”
Tom: “Priya spotted the farm portal questions before any of us even thought about them. That’s good instinct.”
Priya: “Tom’s code is always clean. Even the stuff we threw away was well-written.”
Jas: “Sam’s been handling angry pilot subscribers by herself and never complained.”
Sam: “Maya’s always available when you can actually get hold of her. She never brushes you off.”
Maya: “Everyone kept working even when they weren’t sure what they were building. That takes guts.”
Lee smiles. “You’ve got a good team. You just need a shared picture of what you’re building. Let’s go get one.”
The team files out. Lee steps outside by himself. His phone shows a missed call from his daughter Yuki. He looks at it for a moment, puts the phone back in his pocket, and goes to find his car.
Inside, Maya stays in the meeting room alone. The wall of pink sticky notes stares back at her – every one of them a version of the same problem. She calls Nadia. “I think I’m the problem,” she says. Nadia listens for a long time.
That evening, Tom sits on the couch while Sarah puts Ava and Leo to bed. She comes out and asks how the startup is going. “It’s fine,” he says. Sarah studies him. She knows it’s not fine, but she also knows that Tom processes things by building, not by talking. She lets it go. Tom opens his laptop and stares at his git log. More reverts than merges.
Priya goes home to her flat in North Perth, feeds her cat Refactor, and calls her mum in Melbourne. Her mum asks about work. “It’s fine,” Priya says. It’s not fine, but she doesn’t know how to explain what “blocked on domain questions” means to someone who runs a grocery shop in Dandenong.
Jas looks at the discarded customisation mockups on her desk and thinks about quitting. She calls her mum in Adelaide instead. Her mum tells her about her grandmother: “She never grew what she thought people should eat. She grew what they actually wanted.” It lands, though Jas isn’t sure why yet.
The retro produced one action. One. And it changed everything that followed.
Lee tells Maya afterwards: “Retros matter more now than they ever did. When everyone’s prompting LLMs independently, decisions happen inside individual sessions that nobody else sees. The code arrives clean and confident, but the thinking behind it is invisible. Without a regular space to surface what’s going wrong, teams can drift apart for weeks before anyone notices. In the old world, the slow pace of implementation gave people time to talk. Now the code arrives so fast that the talking gets squeezed out. Retros put it back.”
Maya nods. “We should have done this weeks ago.”
“You should do it every two weeks from now on,” Lee says. “But first – Event Storming.”
What’s next
Over the rest of this series, I’ll walk through the techniques the GreenBox team uses to turn things around. It starts with that Event Storming session Lee suggested, and builds from there:
- Event Storming: Building Shared Understanding (est. 31 March) — Getting the whole domain out of Maya's head and onto a wall, so everyone sees the same picture.
- Example Mapping: Making Stories Concrete (est. 7 April) — Turning vague stories into concrete, testable examples that developers can build from.
- The First Sprints: Turning Sticky Notes into Delivery (est. 14 April) — Walls of sticky notes, a prioritised backlog, concrete examples — and six weeks until the funding deadline. The team needs a rhythm for delivery.
The tools themselves aren’t complicated. The hard part is having the discipline to do the thinking before you do the typing.