Everyone can build

A small detail like a button colour took weeks to ship. The change itself was simple, yet the process around it slowed us down. We spotted the issue, opened a ticket, and then it repeatedly fell behind other priorities until it finally landed a few sprints later.

It highlighted a broader pattern: small, high-leverage improvements were getting stuck in a process that made them harder to move forward.

Earlier this year, Alex and I asked a simple question: what if the person who notices a problem could just fix it?

Fast forward two quarters, and here’s a fun stat: 283 pull requests from non-engineers were shipped at Alan

Here's how we got here:

From the start, we were crystal clear: everyone at Alan should be able to build. This wasn’t a slogan, it was a direction. We made sure there was no discrepancy in how we communicated it, no “engineering versus design” divide, no “business versus product” framing. Just one collective goal: enable every Alaner to build autonomously.

This didn’t happen in a vacuum. Years of nurturing cross-functional talent had already laid the groundwork. Designers understood the implications of shipping, product managers understood code reviews, engineers valued precision and quality. Everyone was already seeing the product as a whole system rather than as a set of isolated responsibilities.

Rather than jumping straight into complex AI integrations, we began with something deceptively simple: getting everyone set up to run our product locally and make their first change.

That meant smoothing every step of the developer experience. We documented a one-stop “Getting Started” guide on Notion, created scripts that handled environment setup automatically, and ensured people could spin up the app and see real data within minutes. We paired each non-engineer with someone from our dedicated setup crew, Tim and Laure, who guided them through installing dependencies, understanding our folder structure, and running a local server confidently.

We also standardized how everyone used Cursor. We configured it with rules to guide the agents, shared prompt examples for common tasks like editing copy or updating design quality, and adopted the same workflows used by engineers. Cursor became the bridge that helped non-engineers read, reason about, and safely modify code with context.

Once that foundation was in place, shipping the first pull request felt surprisingly natural. We started with small text changes, layout tweaks, and quality improvements, and celebrated every merge. Those small steps created momentum and trust.

Now that the foundations are in place, designers can autonomously tweak UI elements, adjust copy, and fix small bugs. The feedback loop between design and engineering is tightening dramatically. Quality issues can be resolved in hours, not days. Engineering time is increasingly freed up for more complex problems.

And the best part? The sense of ownership is skyrocketing. When you ship something yourself, you don’t just see the product, you shape it.

We’re only scratching the surface. Now that designers are comfortably shipping frontend changes, the next frontier is deeper integration of AI-assisted tooling across our build processes, from generating tests to optimizing UX flows.

The goal remains the same: everyone builds. The faster we collapse boundaries between roles, the faster we can learn, adapt, and innovate together.

This is not about replacing expertise. It’s about expanding it, giving every Alaner the ability and confidence to contribute directly to the product they care about.

And we’re just getting started.