A framework for ambitious projects

This is an edited transcript of my talk at Laracon US 2025. It has been tightened for reading while preserving the ideas and examples from the stage.

One week, one unfamiliar framework

Three months before this talk, I had a ridiculous idea: build an icebreaker game for React Miami. The catch was that the conference was one week away. I needed to make a complete, playable game—with prizes—in seven days.

You might assume I reached for a stack I had shipped a thousand times. Instead, I chose Laravel, a framework I had never shipped to production. I had heard this community say again and again how quickly you can build with it, and I wanted to put that claim to the test.

Two days later, the game was running on Laravel Cloud. Friends found bugs, the community helped me untangle them, and with a day to spare the project was ready. That week changed this talk. It was no longer about a generic framework for ambitious projects. It was about what can make ambitious projects possible.

Turning a room into a dungeon

The game begins by recording a few seconds of sound from the room. That audio generates a one-of-a-kind dungeon: different rooms, corridors, enemies, and enemy positions every time. The player then explores the level and clears the enemies.

I did not know how to turn audio into a game level when I started. I first had to learn the language of the problem. The broad idea is procedural generation, but that name opens the door to a huge family of algorithms. Because I wanted square rooms joined by corridors, I settled on a binary space partitioning tree.

A BSP generator begins with a fixed area, chooses a safe location to split it, and repeats that process until each region reaches a minimum size. It places rooms inside those regions and connects them with corridors. A seeded random-number generator makes the result feel random while remaining reproducible: the same seed always produces the same sequence.

From microphone to seed

The browser’s getUserMedia API asks for microphone access and gives us an audio stream. A stream alone is transient, so aMediaRecorder collects it and produces a file when the recording stops.

The Web Audio API then gives us analyzable amplitude and frequency data. Amplitude drives the particle visualization: the louder the room gets, the farther the particles move from the center. Frequency data becomes the input for the game itself.

For the dungeon seed, I use an entropy calculation that condenses the frequency array into one measurement of complexity. Highly varied audio produces a higher value; patterned audio produces a lower one. A mode-based calculation produces another number for enemy count and placement. Those numbers feed the procedural generator, and the game loop turns the result into something you can play.

Why Laravel worked

Laravel is a mature ecosystem. More than a decade of strong opinions has produced a stable foundation and, when you have a question, a clear answer. Coming from JavaScript, where the same question can have a hundred competing answers, that was refreshing.

Getting started takes one command. I can choose the frontend I want, but Laravel gives each option a consistent starting point. The ecosystem also has the batteries that real businesses eventually need, purpose-built infrastructure, observability, good documentation, and a community full of people willing to help when the tools do not give you the answer.

That last part matters even more in an AI-assisted workflow. Models work best around mature, well-documented conventions. When they fall short, a strong community closes the gap. My short time with Laravel showed me an ecosystem that supports ambitious work from top to bottom.

Ambitious projects chart a path

The path between your present and the future you actually want can often be found through ambitious projects. Mine started in 2014 when, as an industrial-design student, I answered a paper flyer asking for an app designer. I was not qualified on paper, but I wanted to design an app, so I said yes.

That project appeared in my portfolio at a university job fair, where Martha Underwood noticed it and became my first web-design client. Six years later she invited me to help build a startup. I said yes again and worked alongside its backend engineer, Chris Winslett. A year later, Chris recommended me for an open role at Crunchy Data because he already knew how I worked. In 2025, Crunchy Data was acquired by Snowflake, and I found myself in San Francisco explaining this chain of events to a new coworker.

It took more than a decade to arrive in that car. There was no master plan—only a series of moments when I was willing to bet on myself. This community exists for the same reason: one person was willing to pursue an ambitious project.

Four lessons for the next one

1. Every expert starts as an explorer. Ambitious work requires learning things you do not know yet. Explorers push both themselves and their communities forward.
2. Expect friction. New codebases feel wonderful until the first hidden complexity appears. The times I pushed through that friction became some of the most fulfilling work I have done.
3. Do not leave discovery to chance. Hold up a giant neon sign that says what you love and what you can do. Sharing the work also attracts people with the same interests, and friends make hard projects easier.
4. You do not need to succeed to be successful. I once made a one-season podcast about Elm. It never became a successful podcast, but a CTO heard it and hired me. A project’s most important outcome may be one you never planned.

No one can be ambitious for you. If something excites you, do not wait for permission. Start building, keep exploring, and make the work visible. The future you are excited about may come find you through it.