Anthropic interviewed more than a dozen fast-growing startups, including ClickHouse, Clay, Omni, Artemis Security, Crosby and Heidi, about how they actually run Claude Code day to day. The results are the kind of numbers that make you check them twice. Clay has automated 100% of bug triage. Artemis Security ships more than 6,000 pull requests a week. ClickHouse shipped 30% more features.
Five patterns come up repeatedly, and none of them require a bigger team or a bigger budget than an Australian startup already has.
1. Everyone ships, not just engineers
The lowest-headcount teams get the most value, because Claude Code lets the person who understands the problem ship the first version rather than the engineer who happens to have capacity.
Heidi's co-founder framed it well: without Claude Code, an idea moves from person to product manager to designer to engineer and loses half its meaning along the way. With it, the person who had the idea ships a working draft themselves.
For an Australian business without a large dev team, this is the single biggest lever. Your operations or sales lead can prototype a fix instead of filing a ticket and waiting three weeks for it to reach the top of a backlog.
2. Automate the tedium, not the thinking
The strongest teams don't use Claude Code to write code faster. They use it to remove entire categories of manual work: automated code review passes, bug triage agents, data analysis pulled together without a person doing it by hand.
The point isn't speed for its own sake. It's freeing people up for the portion of the work that genuinely needs judgement, which is usually a much smaller share of the week than anyone would like to admit.
3. Trust, but verify
None of these startups let agents merge to production and hope. That's particularly true for the ones in regulated industries, where an unreviewed change isn't just a bug risk.
Two habits do most of the work:
Put your non-negotiables in a CLAUDE.md file so the ground rules travel with every session rather than living in one person's memory.
Keep an evaluation set of verified question and answer pairs so you can catch drift before it ships rather than after a customer finds it.
One healthcare billing startup runs every change against a golden set plus random samples before anything goes near a real record. For an Australian business handling health data under the Privacy Act, that pattern is worth copying directly rather than adapting.
4. Build for rebuilding
Because the underlying models keep improving, nothing gets treated as permanent. Clay's founder described their approach as building something, then rebuilding it three more times once you actually understand what's needed.
The practical trick that makes this survivable is git worktrees: run a rebuild in an isolated copy of the repository while the current version keeps working. Building it four times doesn't have to mean four outages, and the teams who figured that out early are the ones who kept iterating without the business noticing.
5. Prototype, dogfood, productionise
Build an internal agent, use it yourselves for a while, and only then decide whether it's good enough to put in front of customers.
This is the same discipline good Australian businesses already apply to any new process. Nobody rolls out an untested procedure to clients first. The only novelty is applying it to AI features specifically, which teams routinely forget to do because a working demo feels closer to finished than it is.
What this looks like for a small Australian team
The gap between reading this and doing it is usually organisational rather than technical. Claude Code sitting with one developer produces one developer's worth of improvement. Claude Code treated as infrastructure the whole team touches produces the numbers in that Anthropic write-up.
Closing that gap generally means three things: getting non-engineers set up and confident enough to prototype, writing down the guardrails so the rules are consistent, and picking the first category of tedium worth automating rather than trying to do everything.
For a Sydney or Melbourne startup of five to twenty people, a rollout covering those three tends to run A$5,000 to A$12,000, depending on how many roles are involved and how much needs to be documented from scratch.
The takeaway
None of this requires a bigger team or a bigger budget. It requires treating Claude Code as infrastructure your whole team touches, not a tool that lives with one developer and gets mentioned in standups.
If you're already paying for it and only one person is really using it, the tooling isn't the constraint. The rollout is.
If you want a Claude Code rollout built around how your team actually works rather than how a demo suggests it should, book a time to talk it through.
