The seed round closed last week. They were officially a company now – an office above a cafe in Fremantle, and $75K in the bank. Angela’s $150K investment came in two tranches: half now, half when they hit 200 active subscribers. Miss the milestone and the second tranche doesn’t release – leaving them with whatever runway remains from the first. At their current burn rate, that meant about three months after the milestone deadline to either hit it late, find other funding, or wind down. The clock was real.
The seed money bought two things the team needed badly. Priya – 29, quiet, precise, recently moved to Perth from Melbourne, her first startup – joined as the second developer. And they finally had enough runway that Maya, Tom, and Sam could stop treating this as a side project and start treating it as a job.
They didn’t have a designer yet. Maya handled the brand herself, badly. Tom built the UI, also badly. That was fine for now. Design could wait. The first boxes had gone out to 38 pilot subscribers and the feedback was good – the produce was excellent, the delivery logistics were shaky, and the sign-up process was held together with sticky tape and a Google Form. It worked. It wouldn’t scale.
Maya’s pitch to the team on Monday morning was simple: “We’ve proved people want this. Now we need to build it properly. Farms list what they have each week. Customers subscribe to a box size. We match supply to demand, pack the boxes, and deliver. Let’s build the software that makes it real.”
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, and asks Tom to push it live. By Wednesday she has a portal where farms can list their available produce: tomatoes, 50kg, $4/kg.
Maya sketches a box customisation page on a whiteboard – subscribers pick which items they want each week. Customer delight angle. Tom builds a prototype from the sketch, prompting an LLM for the UI components. It looks rough but functional.
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.
The customisation prototype is functional. Maya clicks through it – pick your tomatoes, swap out the zucchini, add extra basil. It works. And something about seeing it working makes her stomach drop.
“This isn’t right,” she says, mostly to herself. Then, louder: “This isn’t what we’re selling. We curate the box. That’s the whole point – they trust us to give them good stuff. If customers are picking items themselves, we’re just a worse version of online grocery shopping.”
Tom looks at her. “You sketched this. On the whiteboard. Last Tuesday.”
“I know.” Maya stares at the screen. She had been thinking about delight – about customers feeling involved. But seeing it built, she can see what it actually is: a feature that undermines the thing that makes them different. She hadn’t thought it through. She’d had a half-formed idea, sketched it in the excitement of the moment, and Tom had built it before either of them stopped to ask whether it made sense.
The whole customisation flow is wasted work. Tom spent a day and a half on it.
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.
Maya starts redesigning the customer experience without customisation, but she’s pulled in every direction – answering Priya’s farm portal questions, reviewing Tom’s code, talking to courier companies. Nobody is doing the design work full-time. It shows.
Sam mentions a designer she met at a coworking space event in Leederville – Jas Kowalski, freelance, good portfolio, available. Maya hesitates. “We don’t need a designer yet. Not full-time.” Sam pushes back: “Two days a week. Just to sort out the customer-facing stuff. You’re doing three jobs and none of them are design.” Maya agrees to two days. Jas starts the following Monday. Nobody briefs her on the customisation decision. Her first task is tidying up a flow that the team has already decided to throw away.
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. Maya is supposed to be thinking about the customer experience but hasn’t found time. Sam redesigns the landing page instead – at least that’s something she can do without needing decisions from anyone.
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 customisation prototype, 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 – a third-generation farmer outside Margaret River whose produce she’s hoping to build the business around – 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. The team assumed they understood the domain because the concept sounded simple.
LLMs made it worse, not better. 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 and going quiet about it. 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.
“Five stages,” he says. “Let’s start.”
Stage one: set the stage. Lee reads 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 lets it sit for a moment. “This isn’t a blame session. 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. The landing page is working.”
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.”
Maya: “I sketched a whole customisation flow that we’re not using. I should have checked the premise before Tom built it.”
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.”
Jas: “I spent my first three days redesigning a customisation flow that was already dead. Nobody told me.”
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. “Group the pink notes that seem related.”
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.
One large cluster. A few stragglers.
“What do you notice?” Lee asks.
Tom sees it first. “They’re all the same problem. Maya understands the business. We don’t. And building stuff without that 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: “And the green side?”
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. “The tools aren’t the problem. The people aren’t the problem. One person 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. “Actions,” Lee says. “What could this team do to fix the root cause? One idea per note, no filtering. 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.” Sam: “Record Maya explaining the business on video.”
Five ideas. Lee reads them back. “What do they all have in common?”
Priya sees it. “They all depend on Maya. Every single one puts Maya at the centre.”
“Right. Five ways to get knowledge out of Maya’s head, one conversation at a time. They’d work – slowly.” He writes a seventh note. “There’s a technique called Event Storming. Whole team in a room, farming contacts too if you can get them. A few hours mapping out how the business actually works – not architecture, not user stories. Just: what happens, in what order, and where are the hard parts. Sticky notes on a wall. The shared understanding these six ideas are reaching for? Event Storming builds it in an afternoon.”
He sticks it on the board. “Dot vote. Two dots each. Pick whatever you think will make the biggest difference – even if it’s not mine.”
Event Storming gets six dots out of eight. Daily check-ins get two.
Lee nods. “That’s your call, not mine. If I’d walked in and said ‘do Event Storming,’ you’d be doing it because I told you to. Different thing entirely.”
Maya looks unconvinced. “So the answer is… sticky notes.”
“The misunderstandings that just cost you four weeks? They surface in the first hour, when they’re cheap to fix.” Lee pauses. “You’ll feel like you’re going slower. You’re not. You’re just putting the learning where it’s cheap – on a wall instead of in production.”
Stage five: close. “One last thing,” Lee says. “One thing you appreciated about someone else these past four weeks.”
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.”
Priya: “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.”
“And the retros?”
“Every two weeks. Non-negotiable.” Lee glances at the wall of pink notes. “When everyone’s prompting LLMs on their own, the thinking goes invisible. This is where it becomes visible again. But first – Event Storming.”
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. Ava calls out from her room: “Did you make something today, Daddy?” Tom doesn’t answer. Sarah 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. He’d been thinking about other jobs all weekend. He’s not thinking about them now. Not quite.
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 walks back to her flat in Leederville. Her contract is two days a week and she’s already wondering if those two days are worth it. She spent her first week designing improvements to a customisation flow that was already dead. Nobody told her. She found out when Tom mentioned it in standup, casually, like everyone knew. She’d sat there with her Moleskine open and said nothing. She thinks about not renewing. It’s only two days. She could fill them easily. She calls her mum in Adelaide instead. Her mum listens, then tells her about her grandmother, who ran a market garden in the Adelaide Hills for thirty years. “She never grew what she thought people should eat. She grew what they actually wanted.” Her mum pauses. “The good ones figure that out. Give them a minute.”
Jas doesn’t quit.
The retro produced one action. One. And it changed everything that followed.
Maya books the biggest meeting room she can find and calls Dave Morrison.
“I need you to come to Perth,” she says. “You and Rachel. My team has been building for a month and half of what they’ve built is wrong because they don’t understand how any of this actually works. How the farms operate. What happens when a crop fails. What the substitution logic really looks like. They need to hear it from someone who lives it – not from me relaying it secondhand between meetings.”
She takes a breath. “I need everyone in the same room – the developers, the designer, Sam, you, Rachel, Lee. I need us to map the whole thing out together. What happens, in what order, where it gets complicated. I need the team to see the problems you see. I need you to tell them about the deadlines that matter, the things that go wrong, the stuff I’ve been carrying around in my head that I should have put on a wall weeks ago.”
Dave is quiet for a moment. “I’ve been to workshops before. They were rubbish.”
“This one might be too. But we can’t keep building on guesses. I need you there so we can figure out what’s actually important, what we’re getting wrong, and what we haven’t even thought about yet.”
“What time? I’ve got cows.”
Dave agrees to come. The workshop is called Event Storming: Building Shared Understanding, and it starts with a wall of sticky notes and everyone in the room.