Built for Devs

Try new tools. Share your take.

How the network works, what evaluation sessions look like, and what makes a session worth approving.

The basics

How Built for Devs works for developers

Built for Devs pays developers to evaluate developer tools. Companies use the platform to understand why developers adopt—or don’t adopt—their products. The insight comes from watching real developers try their product from scratch.

When a company purchases evaluation sessions, we match developers from the network whose experience and background matches the company’s target developer profile (ICP). Matching is based on your profile: tech stack, experience level, role type, and other criteria.

When you’re matched for a session, you receive an email invitation. You have 24 hours to accept. If you accept, you complete a screen recording session and get paid once it passes quality review.

Getting matched

Complete your profile

Matching is entirely profile-driven. A more complete profile means better matches and more invitations. An incomplete profile means you’re less likely to match against the ICP criteria companies set when purchasing sessions.

The fields that most affect matching:

  • Tech stack—languages, frameworks, and databases you actively use
  • Years of experience—total professional engineering experience
  • Role type—backend, frontend, full-stack, DevOps, data, mobile, etc.
  • Current company size—solo/freelance, startup, mid-market, enterprise
  • Cloud platforms—AWS, GCP, Azure, or others you work with regularly
Complete your profile →

The session

What an evaluation session looks like

1

You receive an email invitation. You have 24 hours to accept or decline. If you don’t respond, the invite expires and we offer the spot to another developer.

2

Once you accept, you get access to the recording page. You can start the session at a time that works for you, within the window provided.

3

The session is a screen recording with your narration. You try the product from scratch and talk through what you’re doing and thinking as you go. There is no script and no briefing—but there is a goal: reach the product’s defined value milestone, the same way any new developer would.

4

The most valuable sessions come from honest, unfiltered reactions. If something confuses you, say so. If you’re not sure where to go next, narrate that uncertainty. The company is paying to see the real first-contact experience—not a polished walkthrough.

5

Sessions typically run 30–45 minutes, depending on the product. You don’t need to hit a specific duration—end when you’ve given it a genuine try.

6

After you submit, your recording goes through quality review. We check that the session was genuine, the narration was present, and the recording is usable. Approved sessions trigger your payout.

Getting paid

Getting paid

Most sessions are paid. Each approved paid session pays a flat rate—no tiers, no performance adjustments, no deductions. Occasionally a session may be unpaid; this will always be clearly marked in the invitation before you accept. You can decline unpaid sessions at any time.

Payouts are sent once the session passes quality review, which typically happens within a few business days of submission. You’ll receive an email confirmation when the payout is sent.

We pay via PayPal so we can easily pay developers anywhere in the world. You’ll need a PayPal account to receive payment—add your PayPal email address in your developer profile before completing a session, as payouts can’t be sent without it.

Add your PayPal email →

Best practices

What makes a great evaluation

Sessions that surface specific friction points are the most valuable. Here’s what separates a useful evaluation from one that doesn’t pass review:

  • Think out loud. Narrate everything you’re doing and why. “I’m clicking this because I expect it to take me to the quickstart” is exactly the kind of signal companies need. Silent sessions are not usable.
  • Don’t prep beforehand. Skip the docs and tutorials before your session. The company wants to see the real first-contact experience—the point before familiarity smooths everything over.
  • Don’t try to succeed. If you get stuck, stay stuck for a moment and narrate the confusion before moving on. Hitting a wall and working through it is more valuable than skipping past it.
  • Use your real machine and tools. Don’t set up a clean environment for the session. Use the editor, terminal, and browser you actually use. Authentic context produces authentic reactions.
  • Be specific about friction. When something doesn’t work, name what you expected, what happened instead, and what you’re going to try next. Specificity is what turns a session into actionable findings.
  • Your narration is primary, but not the only signal. The company’s tracking script captures behavioral data during your session—clicks, navigation, time spent, and milestones reached. So if you forget to narrate a moment, it’s not lost. That said, your commentary is what gives the data meaning, so narrate as much as you can.