"Being a cowboy dev"

If any game owned this year's GDC trip, it was PEAK. Seven people built it in a month, and it reportedly made $17 million in its first month alone. In any creative industry, that kind of story feels mythical.

Before I even reached the room for the PEAK session, I could already see the line snaking down the hall. At first I assumed the previous talk had not cleared out yet. Then I realized the problem was not outside the room, but inside it: the venue was already completely packed. The crowd felt even wilder than the frenzy around The Legend of Zelda: Tears of the Kingdom in 2024 and Animal Well in 2025.

I had no choice but to beg the staff to let me in. At first they refused, saying I would block the fire lane. I stood there for five anxious minutes thinking, Great, I am not going to be able to write this piece. Then a guy walked up and told the staff he had already saved a seat and had only stepped out to use the restroom. He was turned away too, told that the talk had already started and no one else could enter. In the end he went back in, grabbed his backpack, and came straight back out. Only then did the staff finally wave me inside.

That scene says a lot by itself. GDC never lacks star developers or technical talks, but PEAK packed the room because it hit every nerve the industry is obsessed with right now: small team, short production cycle, low cost, high return. This was not the usual AAA approach of scale, money, and brute force. It was a scrappier method—lighter, faster, and much closer to the way games spread today.

Most people in that room were not there just to hear another success-story postmortem. What they really wanted to know was something else: in an era where big projects keep getting heavier, pricier, and riskier, is the PEAK method actually repeatable?

Part of the answer may lie in Aggro Crab CEO Nick Kaman's talk, "Putting the 'Friend' in Friendslop: The Story of PEAK."

1. If You Can't Beat Them, Join Them

The most interesting thing about the talk was that Nick Kaman did not begin with, "We wanted to make a hit." He began by putting an emotion on the table.

On one slide, he put it with disarming honesty: "A raging jealousy brewed." In plain English: envy, jealousy, and a bit of spite.

The object of Kaman's jealousy was Landfall's Content Warning. As he described it, it was the kind of game where you instantly understand why it goes viral: simple rules, immediate payoff, and endless room for friends to create hilarious moments together. What really got under his skin was not the concept. It was the speed.

When Kaman asked how long it had taken, the answer was six weeks—something Landfall had thrown together while in Korea for a game jam. For Aggro Crab, fresh off the three-year development of Another Crab's Treasure, that felt almost humiliating.

Aggro Crab had spent three years on a large project with middling results. Landfall had spent six weeks and come away with a breakout hit. Anyone would have had trouble swallowing that.

That frustration eventually turned into a bet with Landfall: whose game would do better? Then Kaman delivered the punch line—whoever lost had to pay for the other's therapy—which drew one of the biggest laughs of the session.

But the joke also reveals something important about PEAK's bizarre origin. This was not a project reverse-engineered from market research, player insight, or category analysis. It was a collaboration born from mutual admiration, creative fatigue, and a very human desire not to lose.

On stage he roasted them mercilessly; in the slide deck, their credentials looked immaculate.

As Kaman put it, "What really got me thinking was not the bet itself, but another question: how can they make games like that? How can they compress development that far? If I can't beat them, I might as well join them." That was when Aggro Crab started wondering whether it should go to Korea with Landfall the next year and see what the two studios could make together.

That collaboration would eventually become PEAK.

PEAK did not begin as a fully formed proposal. It began as a direction. Stranger still, the idea was not born in a formal brainstorming session but in a hot tub. Stripped to its essence, the pitch was simply this: you are a group of scouts stranded on an island, and you need to survive and climb your way to rescue.

That absurdity turned out to be energizing. As Kaman recalled, the team used a deliberately stupid phrase for the concept: "bing bong boy scouts." The point was that this would not be a solemn survival game. It would be about physics, mistakes, chaos, accidents, and the fun of friends alternately sabotaging and saving one another. Just imagining players awkwardly rubbing sticks together to start a fire, or accidentally dragging the whole team off a climb, was enough to make the tone click.

At the same time, things at Aggro Crab were not in great shape. The studio had just shipped Another Crab's Treasure, but funding for the next project had fallen apart. Plans that had seemed locked in suddenly evaporated. Put bluntly, the Korea trip may have looked like a collaborative game jam, but underneath it was tied to a much more anxious question: what comes next for the studio?

The problem was that before the trip, communication between Aggro Crab and Landfall had already started to fray. "We kept going back and forth on Discord, and the vibe kept getting worse," Kaman said. "It wasn't that anyone hated each other. Text just amplifies misunderstanding. A neutral message can read like rejection, and one person can answer a completely different question from the one another person thought they asked."

So Aggro Crab started to worry: what if they arrived in Korea in that state and ended up stuck together for a month, annoyed at each other the entire time?

But the tickets were booked, so they went.

2. Communication Is the Core Mechanic

As Kaman put it, the real turning point came when everyone stopped communicating through text and finally sat in the same room together.

Looking back, he thinks most of the friction on Discord really was caused by text itself. Once people were face to face, tone, expression, rhythm, humor, and timing all came back. Arguments that might have escalated online could be resolved in minutes on site. Ideas moved faster, and so did disagreement.

By day two, the climbing system had started to take shape. Character designs were moving in parallel. The team could finally see what the game might become. Then, on day three, they found the design idea that changed everything: the everything stamina bar.

That bar was so powerful because it collapsed a whole set of systems—hunger, injuries, carrying weight, status effects—into a single resource check. Whether the player could keep climbing or not depended on that one bar.

Once that backbone was in place, most of the remaining design questions became much easier to answer. If an idea interacted meaningfully with the mountain or with the stamina bar, it was probably worth trying. That meant the team did not need endless meetings or a formal approval chain. Ideas could simply be built and tested.

That is why Kaman later delivered what may have been the talk's most important line: "At that point, the game started making itself." He immediately explained what he meant: "The whole videogame is basically the climb itself, and the stamina bar that keeps you from climbing forever."

That is also why he could say, without exaggeration, "By day seven, we had a working prototype."

Once the direction was clear, the rest was execution. By day 28, the core game was essentially there from start to finish.

Even then, Kaman kept his expectations modest. He said that if PEAK performed at even one-tenth of Content Warning's level, he would consider that a win.

Instead, the result was seven people, one month, and something close to a miracle. According to Alinea Analytics, by February 2026 PEAK had sold roughly 15 million copies and generated about $100 million in revenue.

So what, exactly, did PEAK do on the design side to make that happen?

The first answer is simple: it constantly pushes players to interact. PEAK was never designed around the fantasy of conquering a mountain alone. It was designed around reaching the summit with your friends. You can absolutely play solo, but the game's real emotional charge comes from helping, inconveniencing, teasing, and depending on one another on the way up.

Players can boost teammates, pull one another up, and manage items for each other. The game even bakes in a bit of friction on purpose so that no one can be fully self-sufficient.

Kaman gave a good example: you cannot effortlessly pull every item out of your own backpack. Quite often, you need a friend to do it for you. That kind of small inconvenience is not there to punish players. It is there to force conversation, dependence, and cooperation.

To reinforce that spirit, the team even added a field guide to the game. It does not just teach controls; it quietly establishes a social rule: do not leave your friends behind. And players really do absorb it that way. What begins as a tiny text detail gradually becomes part of the community's role-playing and group behavior.

Voice chat mattered too. The team implemented proximity voice so that distance itself became part of the experience. You hear your friends calling from somewhere above or below, with space and direction built into the sound. Naturally, players start discussing routes, hazards, resource sharing, and who should climb which side first.

All of this turns communication itself into a core mechanic rather than an external aid.

Even death is not allowed to eject you from the fun. In PEAK, dead players become ghosts and can continue helping the team. As Kaman explained, many adjacent games push dead players into spectator mode, but PEAK does not want failure to kick anyone out of the shared experience. You are still in the run—you are just participating in a different way.

3. Not Every Team Can Replicate This

Beyond communication, another design decision that drew a lot of attention was the daily map.

Kaman admitted that this feature was partly accidental. At first it was more of a technical constraint than a grand design breakthrough. The team was not building a truly infinite system that generated a completely different mountain every run. Instead, it prepared map content in a more handcrafted and controllable way. But players ended up loving it, because it meant everyone was facing the same mountain on the same day.

That shared condition gave the community something to talk about. Was today's route brutal? Was there a best path? Was yesterday's mountain easier? The feeling that everyone was tackling the same map together became one of the game's defining social features.

Kaman was equally candid about how the mountain itself was built: "Honestly, there was no secret advanced algorithm. We basically threw rocks and terrain in there and prayed it would create paths that were climbable, playable, blockable, and rescuable."

That sounds crude, but it perfectly matches the spirit of the project: do not trap yourself in overdesign. First, make something people can actually play.

The team also stuffed the game with things that exist simply because they are funny. Bing Bong is the clearest example.

To be fair, Bing Bong is not the sort of element you derive from a careful core-system diagram. It feels more like the byproduct of a high-energy collaboration—something the team kept riffing on because it made them laugh. But that is exactly the kind of thing players remember. A bizarre, adorable, screenshot-friendly character often does more for a game's identity than paragraphs of lore ever could.

That, too, gets at something essential about PEAK. The goal was never to make a work where every single element had to be sober and internally airtight. The goal was to make something that kept generating shared memories and social hooks. Very often, the thing that seems like a dumb joke is exactly what players use to share the game, remix it, and recommend it to their friends.

By this point, we can answer the question everyone really cares about: can you replicate something like PEAK in a month?

Kaman's answer was refreshingly direct: try. Even if you do not finish, getting to a respectable prototype in a month is already valuable. Working fast lowers the cost of failure, lets you evaluate the direction earlier, and forces you to focus on what matters most. A lot of good ideas only appear under that kind of pressure.

But there are a few conditions you cannot ignore. First, Landfall is unusually good at this mode of development. The studio has years of experience making physics-driven, multiplayer, systems-heavy games, and its people are broad generalists. That is why it can assemble a PEAK skeleton so quickly. Second, the team has almost zero tolerance for management friction: no elaborate process, no stacked approvals, just tasks being marked off with emoji in a Discord channel. Kaman joked that he had always thought of himself as a cowboy developer—until he worked with them and realized he looked more like a NASA engineer by comparison.

Of course, speed has a cost. The bugs that keep resurfacing in post-launch maintenance are the technical debt you take on by moving that fast. But Kaman's view was clear: this was a choice made with full awareness of the tradeoff, and for PEAK, it was worth it.

Another often overlooked prerequisite is marketing capability. Landfall and Aggro Crab had spent years building communities and channels. They knew how to light the fuse with a single short video, and they were confident enough to release the official trailer only four days before launch. That confidence allowed them to skip the long traditional warm-up campaign that many games rely on.

Still, this path does not fit every kind of game. Highly linear games built on large volumes of bespoke handcrafted content are a poor match for this process. PEAK works because the developers are building a scaffold for player interaction rather than scripting every experience in advance.

At this point, Kaman offered four practical questions. If you are wondering whether to pursue a very short development cycle, ask yourself:

• First, does your team have enough experience to make something good, fast?

  
  

• Second, do you have a realistic distribution or marketing plan, even if it is not a traditional big campaign?

  
  

• Third, are you willing to abandon some conventional workflows and accept the consequences of a more cowboy-style development process?

  
  

• Fourth, is this actually the kind of game that can be prototyped and assembled quickly?

So, is PEAK a new blueprint for the industry?

Yes and no. It does demonstrate a lighter, faster, more interaction-driven path to development, and seven people turning that into $100 million is persuasive on its own. But it is not a universal formula that can simply be pasted onto any team or project.

What Kaman really seemed to be sharing was not, "Do it exactly like us," but, "Rethink the way you work." What is your team actually good at? What kind of game fits that strength? And do you have the nerve to discard processes that look professional but have really just become bloated?

The real key to PEAK was not a methodology. It was a group of people finding the way of working that suited them best—and then betting on it. Whether you win that bet depends not just on skill, but on whether you truly understand the price you are willing to pay.

That may be the real meaning of "being a cowboy dev": not charging in blindly, but knowing the risks and going wild anyway.