How We Build

We are Amp, an independent research lab.

We let software builders harness the full power of artificial intelligence.

We believe shipping is the only valid form of research, and we explore the absurd to find the possible.

Live One Year Ahead

The market doesn’t define the game; AI progress does.

We don’t build for the 99% of today. We build for the 1% of pioneers already living in tomorrow.
We are thesis-driven, not metrics-driven. A thesis sets the direction; reality tells us whether it survives.
We don’t ask for permission, wait for consensus, or let competitors define our roadmap.
We build what pioneers need one year from now, not what they tell us they want today.

We are truth-seekers, not theory-crafters.

Everything must serve learning, and finding what’s possible. We don’t sit in a lab and theorize—we validate.
We protect the freedom to be wrong and the willingness to look stupid, because that is the cost of truth-seeking.
Put your numbers on the board. Accept the reality of the results. Iterate until you find the truth.
We build in public. The door is open. If you want to come along, come along—but we don’t make an effort to pull the skeptics.

We start with the user, study what already works, then prove the bet as cheaply as possible.

We write the news post first. Not for marketing, and not to annoy anyone. We write it to answer the only question that matters: why would a user care about this feature?
We study our competitors. We use their products. We run the same tasks side by side. We learn what works, what doesn’t, and where something meaningfully better is worth building.
Before changing something, we earn the right. We study what is already proven: we deconstruct it, explain how it solves the problem, and explain why our idea is better.
Dogfooding is our superpower. Ship, use, iterate.
We must all talk to customers and users. We join the Discord, are active on X, and reply in the customer’s Slack.

The frontier is claimed by those who execute.

We choose what to work on. It’s better if we ship what we want than not ship what someone else wants.
No task lasts longer than one week. We ship something into live production every week. When we join the team, we ship something.
We question every timeline. Instead of next week, why not this week? Instead of tomorrow, why not today?
We bias toward shipping. We don’t let perfection become an excuse for inaction. We ship the smallest version that teaches us something, then iterate.
We make it incremental. We don’t let work sit on a branch for a week and grow to 10,000 lines. We build the smallest mergeable chunk that’s easy to test and revert, verify it, merge it, then build the next one.
We don’t do big releases. We constantly merge and constantly release.

Moving fast means reducing future drag, not creating it.

We move fast, but we don’t rush. AI lets us move at breakneck speed, but speed alone is not the goal. We want velocity: moving at high speed in the right direction.
We focus. We do one thing well rather than ten things poorly. We keep the surface area small: fewer features that do more. When in doubt, we don’t add the feature.
The code should stand on its own. In the best case, nobody should ever need to look at it again. We ask from the start: how will we debug this, and how easy will it be to remove?
Fixing bugs and building solid foundations come first. A decaying codebase is a mortal threat; firefighting is not forward motion.
Robustness is speed. Every pixel matters, every interaction matters, and every millisecond matters.
Bringing it to life means getting the details right. Brand wraps around everything, from backend architecture to the phrasing of a news post.

We treat this as if it were our own project—because it is. If we see it, we own it.

We merge it, we own it. We make sure it works, keep fixing it, and don’t merge what we can’t own.
We don’t assume someone else will fix a problem. We fix it, tag someone, or make sure it is tracked.
We are our own harshest critics. We fall in love with the problem, not the feature. We challenge our ideas as aggressively as we would challenge someone else’s. Every feature has to earn its place. Kill your darlings.
We seek out hard feedback. If someone cares enough to challenge the work, we listen. We don’t defend it—we understand why they reacted that way. The goal is not to be right; it is to build the best product.
We answer the hard questions. We explain why we chose this approach, what trade-offs we made, and what we rejected. If we haven’t thought something through, we say so. We think it through, come back with an answer, and change the proposal when the answer demands it.
Give a fuck. Care about the product, care about the users, and care about the team.

If we aren’t feeling a mix of awe and nervousness, we aren’t pushing hard enough.

We embrace how AI is changing how we develop software.
We maintain a sense of play. We dare to have character.
We go against the grain. “We thought it would be fun” is a valid reason to explore.
Having taste matters. Being weird is a strength.