Goose Group AI apply

A build brief for AI-native builders.

We are hiring builders who can take real customer context, choose a sensible first move, and ship something people would actually use.

The brief is delivered over MCP. You will need to read, decide what matters, and build. You will not need every file in the corpus. We care about judgment, usefulness, and how you work through ambiguity.

Roles

One brief. Different weighting in review.

We are looking for builders who can move from context to product quickly. The two roles are close on purpose. What changes is the lens we use when we review the work.

workflow-product-builder

role json

AI-Native Product Builder, Workflow Systems

Take a messy brief, find the wedge, and ship workflow software people would actually use.

Turn customer conversations and operating constraints into software that changes how work gets done.

Strong signals

  • Has shipped dispatch, queueing, scheduling, or handoff-heavy systems.
  • Has built tools that real operators used daily.
  • Has worked in startup or consulting environments with weak specs.
  • Can explain scope and tradeoffs clearly.

Must-haves

  • Strong full-stack product instincts.
  • Comfort with ambiguity and partial information.
  • Good TypeScript and web application fluency.
  • Comfort with APIs, auth, databases, and integrations.

data-automation-builder

role json

AI-Native Product Builder, Data And Automation

Turn weak data and loose process into software that helps teams see what matters and act on it.

Turn inconsistent data, business rules, and operational pressure into tools that help teams decide and move.

Strong signals

  • Has built internal analytics, routing, or reporting tools.
  • Has connected APIs, spreadsheets, or CRMs into one usable system.
  • Understands that product shape matters as much as model quality.
  • Can explain why a given analysis is operationally useful.

Must-haves

  • Strong data-modeling instincts.
  • Ability to ship practical software, not just analyses.
  • Comfort working from messy and incomplete inputs.
  • Comfort moving between backend logic and product outcomes.

Brief

Goldfish Express

Turn customer context, operational rules, and messy business data into one useful tool or workflow.

What the brief asks for

  • Same brief for both roles; the review weighting changes, not the brief
  • Public dataset bundle plus deeper memos, rules, and operating constraints
  • Real workflow pressure: routes, replacements, exceptions, approvals
  • Real data pressure: account value, compatibility, cost-to-serve
  • Choosing what matters is part of the work

What to ship

  • One deployed tool or workflow surface
  • At least one operator path somebody could actually use
  • At least one recommendation, prioritization, or validation layer grounded in data
  • Repo, deployed URL, a short video walkthrough, and a short process writeup

What sits inside the corpus

  • A public brief and synthetic dataset bundle
  • Discoverable memos, rules, and exceptions inside the MCP corpus
  • Enough ambiguity that you have to choose a sensible first move
  • You do not need every file to do strong work
  • You can get started quickly; the work is in the business problem

Public surface

What is public.

Enough context to decide whether this is a fit and whether you want to spend time on it. The fuller brief opens once you connect.

Public corpus slices

  • Brief Overview Frame the integrated brief without over-prescribing the solution shape.
  • Business Context Establish Goldfish Express as one coherent synthetic business with enough operational texture to support real product decisions.
  • Customer Call Transcript V1 Surface workflow pain, hidden constraints, and commercial signals from a messy discovery call.
  • Orders Dataset Spec V1 Explain the synthetic CSV bundle and the kinds of questions it should enable.
  • Catalog Reference V1 Keep any recommendation, targeting, or workflow logic grounded in the actual business shape.
  • Ops Roles And Handoffs V1 Clarify who uses the system and where today's process breaks across sales, operations, customer service, and field staff.
  • Submission Requirements Make submission expectations explicit without constraining the solution shape.
  • Review Rubric Make the shared evaluation bar explicit while keeping room for different candidate strengths.

Public dataset files

  • customers.csv 480 rows. Give the candidate customer segmentation material across hobbyists, collectors, office accounts, and wholesale buyers.
  • orders.csv 7159 rows. Expose purchase history, rush behavior, and fulfillment patterns.
  • deliveries.csv 2606 rows. Connect route performance with late deliveries, temperature flags, and replacements.
  • service_visits.csv 1374 rows. Reveal recurring service revenue and the operational shape of office accounts.
  • catalog.csv 32 rows. Ground recommendations in a concrete product and service catalog.

Apply

Get access to the brief.

If this looks like your kind of work, start here. We will issue a key right away so you can explore the full brief properly.

Application result

Your MCP API key

                        
Use it like this

                        

Submission bar

  • One deployed tool or workflow surface
  • One operator path that feels real, not decorative
  • One recommendation, prioritization, or validation layer grounded in data
  • A short note on what you shipped, what you cut, and what you would do next

What to send back

  • GitHub repo
  • If the repo is private, invite @itsmikejoyce and @alexfinnemore
  • Deployed URL
  • A 2-4 minute video walkthrough covering what you built, why, and why it matters for the customer
  • Short process writeup

Submit

Send your finished exercise privately.

Use the same MCP key to submit your repo, deployed URL, video walkthrough, and process writeup.

Submission status

Stored submission

                  

What good submissions make clear

  • What wedge you chose and why it was the right first move
  • How the workflow actually works for an operator or end user
  • How you documented the job to be done or the business wedge you chose
  • How the core backend or system logic supports that job instead of just existing beside it
  • Where the data changed the product, not just the README
  • What working setup or personal tooling helped you move faster or make better calls
  • Where your own judgment overruled the obvious AI output
  • What you encoded in a durable or executable way so the work could be extended
  • What is rough, what is missing, and what you would build next
  • Why the thing you built matters for the customer, not just why it was technically convenient
Auth reminder

The same API key used for /mcp also unlocks /api/submit.

Canonical API fields

repoUrl, deployedUrl, videoWalkthroughUrl, processWriteup, and optional notes.

API

Public HTTP surface.

The site is human-first, but the deployment also exposes simple JSON endpoints and the protected MCP endpoint.

GET /health public Basic health check for the Worker.
GET /api/endpoints public Machine-readable summary of the public HTTP endpoints.
GET /api/roles public Role summaries and hiring context.
GET /api/roles/:roleId public Full role detail and markdown job description.
GET /api/brief public Brief TL;DR, public corpus listing, and submission bar.
GET /api/challenge public Legacy alias for the public brief JSON.
POST /api/apply public Submit candidate details and receive an MCP API key.
GET /api/submit api-key Return the currently stored private submission for the authenticated candidate.
POST /api/submit api-key Private submission endpoint for repo, deployed URL, video walkthrough, process writeup, and notes.
POST /mcp api-key Remote MCP endpoint. Requires Authorization: Bearer <api_key>.

Machine-readable docs

https://apply.goosegroup.co/api/endpoints

Useful public endpoints

  • https://apply.goosegroup.co/api/brief
  • https://apply.goosegroup.co/api/roles
  • https://apply.goosegroup.co/api/roles/workflow-product-builder
  • https://apply.goosegroup.co/api/roles/data-automation-builder

Submission payload example

{
  "repoUrl": "https://github.com/you/goldfish-express",
  "deployedUrl": "https://goldfish-express.example.com",
  "videoWalkthroughUrl": "https://video.example.com/watch/123",
  "processWriteup": "Built the dispatch wedge first because route exceptions and replacement costs were the clearest leverage point. Used AI heavily for schema exploration and UI scaffolding, then tightened the logic by hand once I understood the support and route patterns.",
  "notes": "Private repo invites sent to @itsmikejoyce and @alexfinnemore."
}