Work with us

Pick a challenge. Build it. Get paid.

We build with a selected community of independent developers. Access is not open to the public—you apply, and if you are accepted you can take on paid engineering challenges whenever you have the time for them. No hours, no office, no standing commitment.

Access

The platform is not open to the public.

Getting in is the one part of this that is selective. A workspace gives you real code and real responsibility, so we decide who joins the community before we hand over the keys—not after.

01 / APPLY

Tell us what you build

Fill in the application with your background, the kind of systems you have worked on, and where we can see your work. It takes a few minutes, and every answer is read by a person.

02 / EVALUATION

A practical assessment

We evaluate you on real work, not on an interview performance. You will be asked to deliver against a brief built the same way every challenge is, so you see exactly what the model feels like before committing to it.

03 / ACCESS

You are in

If it goes well, your account is created and the open challenges become visible to you. From that point you decide what you take and when.

Why selection exists at all.

The automated quality gate can verify code. It cannot verify judgement, discretion, or how someone behaves around a customer's work. That part is decided by people, once, at the entrance.

Flexibility

No hours. No office. Nothing assigned to you.

Once you are in the community, the amount of work you do is entirely your decision—and it can change from one month to the next without anyone needing to approve it.

Work when you actually have time

Evenings, weekends, a quiet week between other projects. There are no working hours to observe, no availability to declare, and no meetings to attend.

Take what fits the time you have

Challenges are sized and priced individually. Take a small one when your week is full, or several when it is not.

Nothing lands on you unrequested

Work is never assigned. Every challenge you hold is one you chose to claim, which means you are never behind on something you did not agree to.

Step away without explaining

Claim nothing for a month and nothing happens. The community does not expect continuous availability, and coming back does not require re-applying.

The process

Once you are in, six steps.

No interviews to schedule, no proposals to write, no negotiation over scope. The work is specified before you see it, and the reward is stated before you commit to it.

  1. BrowseSign in to the development platform and see every challenge currently open, each with its scope, its technical contract, and the reward attached to it.
  2. ClaimPick the one that fits your skills and assign it to yourself. No approval queue and no waiting—the challenge is yours from that moment.
  3. Open your workspaceA dedicated development environment opens in your browser, already configured, containing only the code for the challenge you claimed.
  4. BuildWork with AI agents, start from microservice templates, and run builds directly from the workspace. Your written brief defines exactly what the service must do.
  5. SubmitOne button runs the full quality and test suite. You get back a report listing anything that still needs fixing, and you can iterate as many times as you need.
  6. Get paidWhen every check passes and the work is complete, the challenge is credited to you. Payment is issued at the end of the month, covering everything you cleared in that period.
Your workspace

Everything set up before you arrive.

You do not clone repositories, install toolchains, configure credentials, or wire up a local database. The environment is provisioned with the challenge and reachable from any browser.

01 / EDITOR

A full IDE in the browser

Code Server gives you a complete editor and terminal, scoped to your challenge only. Nothing to install, and nothing of ours to configure.

02 / AI TOOLING

Agents and a token allowance

Custom tooling and coding agents are built into the workspace. Every challenge includes an allowance of AI tokens, and your remaining balance is always visible on your development page.

03 / SHORTCUTS

Templates and one-click builds

Start from a microservice template rather than an empty directory, and trigger builds from the interface instead of assembling a pipeline yourself.

Scoped access by design.

A workspace exposes the code for its own challenge and nothing else. This keeps your responsibility unambiguous and our customers' work properly contained.

What you build

Microservices with explicit contracts.

Almost every challenge is one or more microservices, specified by the inputs they receive and the outputs they must produce.

You receive a written brief covering the service's responsibility, its input and output contract, the failure cases it must handle, and the quality bar it has to meet. The contract is the specification: as long as your service honours it, the internal design decisions are yours to make.

This is what makes the model work. Because the boundary is defined up front, work can be distributed without coordination overhead, reviewed objectively, and integrated without renegotiation.

Defined I/O contractWritten briefService templatesAutomated testsObjective acceptance
Example challenge

What a brief actually looks like.

This is a brief from our backlog, reproduced as you would see it on the platform. Judge the model by it: the scope, the constraints, and the boundary of the work are all settled before you claim anything.

Challenge

PII Redaction Engine — Worker Service + Desktop App

Build a system that detects personally identifiable information in text documents and replaces it with either generic placeholders or realistic fake data. The same detection and redaction logic must power two separate deliverables: a queue-based worker service that processes documents as part of a backend pipeline, and a desktop application where a user pastes text or uploads a file, runs the same redaction, and visually reviews what changed.

Both must produce identical results for identical input. This is a hard requirement, not a nice-to-have.

Total reward$450across 3 challenges
TypeScriptNode.jsBullMQTauriRustFully offlineDeterministic

Three claimable challenges

This brief is delivered as three separate challenges, each claimed and paid on its own. The core is built and validated first; the two adapters can then be claimed in parallel, by you or by someone else.

  1. 01
    pii-core

    Detection, redaction, deterministic fake-data mapping, and the full test suite. Everything below depends on it.

    $200
  2. 02
    Worker adapter

    BullMQ consumer wrapping the validated core. Thin by design.

    $70
  3. 03
    Desktop app

    Tauri shell, file access in Rust, and the side-by-side comparison UI.

    $180

Core constraints — non-negotiable

  • No cloud APIs. Detection and redaction run fully offline and in-process. No PII may ever leave the machine for a third-party service—no OpenAI, no Google Cloud DLP, no AWS Comprehend.
  • No ML models. Deterministic, rule-based detection only: regular expressions with real validation logic (checksum and format validation, not bare pattern matching) plus static gazetteers for names. Identical input must give 100% reproducible output, with no probabilistic behaviour.
  • Deterministic fake-data generation. The same original value must always map to the same fake replacement—within one document and across separate runs and documents. "John Smith" appearing three times, or in two different files, always becomes the same fake name. Use a seeded or hashed approach, never true randomness.
  • No original PII in output metadata. When reporting what was found, emit the entity type and its position only—never the sensitive value itself.

PII categories to detect

  • Email addresses
  • Phone numbers
  • IBAN and bank account numbers, with checksum validation
  • Credit card numbers, with Luhn validation
  • National tax IDs — format specs provided
  • Full names, via gazetteer plus contextual heuristics such as titles and capitalisation patterns
  • Physical addresses

We provide a test dataset with expected outputs. Detector accuracy is measured against it.

Architecture — shared core, thin adapters

  • pii-core — a standalone package holding only the detection and redaction logic. No dependency on any queue system, UI framework, or file system. Pure functions: text in, redacted text plus detected entities out. Zero native or binary dependencies and zero network dependencies, enforced in the codebase via a dependency lint rule.
  • Worker adapter — a thin wrapper that pulls jobs from a queue, loads the referenced document, calls pii-core, and pushes the result onward.
  • Desktop adapter — a thin wrapper around the same pii-core functions, handling file and text input and rendering results.

Design pii-core to be consumable from both a Node.js backend and a desktop frontend without modification.

Challenge 02 — Worker service

  • Consumes jobs from a BullMQ input queue; each job is a JSON payload referencing a document.
  • Loads the document, runs it through pii-core, and pushes the result to an output queue.
  • Queue names, connection details, and the job payload schema are provided at onboarding.
  • Runtime: Node.js and TypeScript.

Challenge 03 — Desktop application

  • Cross-platform: Windows, macOS, Linux.
  • Tauri is the expected framework, not Electron—we want a small installer and a low memory footprint. Since pii-core has no native dependencies, the redaction logic should run inside Tauri's webview, with Rust used only for file system access. If you have a strong reason to prefer Electron, raise it before starting.
  • User flow: paste text or upload a file, submit to the engine, view the redacted document, then compare original and redacted side by side with detected PII highlighted in both panels, colour-coded by entity type with a legend.
  • Assume plain text input: .txt, .csv, .json, .md.

Deliverables

  • The pii-core package, with unit tests covering every PII category and the edge cases: overlapping matches, adjacent entities, empty input.
  • The worker service implementation.
  • The Tauri desktop application, including the comparison and highlighting UI.
  • A brief README per component: how to run it, how to test it, and any assumptions you made.

Explicitly out of scope

  • Any cloud or API-based detection fallback.
  • Rich document formats such as .docx and .pdf. Flag it if you believe this materially changes your approach, but do not build for it.
  • Authentication, user accounts, and multi-user features.
  • CI/CD pipeline setup—we handle integration into our existing infrastructure.

Settled at onboarding

  • The exact list of supported countries for tax ID and address format validation.
  • Repository access and the exact package and repository structure.
  • Queue connection details and the job schema.

Anything still open is answered before the clock starts—you never begin a challenge with an unresolved question in the brief.

See every open challenge →

Acceptance

The quality gate decides, not an opinion.

Submitting runs the same automated checks for everyone. You always know where you stand and what is left to do.

Submit whenever you are ready

There is no penalty for submitting early. The gate is a tool for you, not a one-shot examination.

Get a specific report

Failures come back as a concrete list of what did not pass—not a vague rejection or a subjective critique.

Iterate until it is green

Fix, resubmit, repeat. There is no limit on attempts and no reduction in reward for needing more than one.

Clear it and it is credited

Once every check passes and the work is complete, the challenge is credited to your account for the month.

Compensation

Known before you start. Paid monthly.

Every challenge carries its reward on the listing, before you claim it. What you see when you commit is what you are paid when it clears.

Cleared challenges accumulate through the month and are paid together at month end. Take one challenge or several—the platform tracks what you have completed and what it is worth, and you can see your running total at any time.

You work as an independent collaborator, choosing what to take on and when. Engagement terms, confidentiality, and intellectual-property assignment are agreed in writing before your first challenge begins.

Who this suits

Developers who would rather build than negotiate.

01 / FIT

You work best with a clear spec

You would rather receive a precise contract and deliver against it than spend the first week deciding what the work actually is.

02 / FIT

You deliver without supervision

Nobody checks in on your progress or asks for a status update. You are trusted to work through a brief on your own—and to say so early when something in it does not hold up.

03 / FIT

You are comfortable with AI-assisted work

Agents are part of the toolchain here, not a novelty. You are expected to use them well and to stay accountable for what ships.

Get started

Apply to join the community.

Tell us what you build, where your strengths are, and anything you can show us. We read every application. If it looks like a fit, we will take you through the evaluation and, if that goes well, open the platform to you.