SimplyCodes, our coupon site, tests promo codes at real checkouts and knows which ones work. Its agent server is live: it speaks the Model Context Protocol, the standard AI agents use to call tools, and every call carries a key. A free key returns what we know about a merchant's codes with the proof attached; paid tiers return the codes themselves. Developers sign up on the SimplyCodes developer site.

We have written down how a developer should get in: a key in under 5 minutes, and a first verified answer inside their own application in under 30. Nobody has watched an outside developer try, and nobody has asked them what they would build. In this mission you recruit 8 to 10 developers who build shopping agents and run one session with each: they connect from their own tools while you time it, then you interview them about what they would build, what they would pay for, and what would make them stop calling. You are paid per completed session.

Our goals for this mission

A person may install a connector because they know our name. The agent keeps calling it only if every answer comes back fast, in the format it promised, and with its proof attached. A server that is slow or returns a malformed answer loses that developer, and so does a server that says no without showing its checks. Logs show that a call stopped. Sitting next to the developer shows why.

We also do not know who the developer is. Indie agent builders, AI startup teams, and platform teams each need something different from the server. Ten conversations written down in the developers' own words tell us what to build first and what to fix first.

What you would do

  • Your own run. You sign up, get a key, and connect to the server yourself from a clean machine, timing each step, so you know the path before you watch anyone else walk it.
  • Recruiting. You find 8 to 10 developers who build shopping agents and who work for neither Product.ai nor SimplyCodes. Finding them is part of the work; we can suggest places to look.
  • The session, part one. You sit with the developer, in person or on a call, while they get a key and connect from their own tools to a first verified answer inside something they built. You time two things: the minutes to a working key, and the minutes to that first answer. You record whether they open the proof attached to each answer, where they doubt an answer, what they do when one comes back slow, malformed, or as a no.
  • The session, part two. A 30-minute interview: what they are building, where they get product and price data today, what they would do with verified promo code data, which tools they would call first, what they would pay for, and what would make them stop calling.
  • The write-up. Each session becomes a dated note: the two timings, what the developer said in their own words, and whether they want to hear from us again.
  • The report. It names which build of the server each developer saw, lists every timing, ranks what to fix, and says what these developers would build and pay for. Every finding points to a session note anyone can read.

If the server changes while the sessions run, you note the change and keep going.

What success looks like

  • 8 or more completed sessions, each with a timed record and a note anyone can read.
  • Per developer, the minutes to a working key and to a first verified answer, beside the 5 and 30 we set for ourselves.
  • The three things to fix first, in order, with the developers each fix would have kept.
  • The three things developers would build or pay for first, each traced to a note.
  • Where a developer would have stopped calling, the report quotes the developer on why.
  • A result you did not expect is reported as it is. If every developer got in fast and none would pay, you say so and show the notes.

Ground rules

  • The developers are outsiders. Nobody employed by Product.ai or SimplyCodes counts toward the 8.
  • You record a session only with the developer's consent, and a developer who asks to stay anonymous in the notes stays anonymous.
  • You describe the server as it is at kickoff and promise no dates. Our engineers own the timeline.
  • Any change to the server itself goes through our engineers as a reviewed pull request. Your report ranks the fixes.
  • At least 2 sessions are recorded, or watched live by one of our engineers, so the report's findings can be checked against the session.
  • Nothing a developer says is published without their written yes.
  • Pay is per completed session, at the rate set in the contractor agreement.

What happens after you send a proposal

3 steps, and a person reads every proposal.

  1. You send a short written proposal. It covers how you understand this mission and how you would approach it, and you attach your resume or a LinkedIn profile.
  2. We read it and reach out with questions. There is no test and no exercise.
  3. If there’s a fit, the mission begins under a contractor agreement and an NDA, paid at your stated rate, with kickoff in Santa Monica.