Cohort 02 - Open Roles Recruiting
Spring 2027·16 Weeks·Credit-Bearing—Kickoff: January 2027 · West Palm Beach, Florida
Where innovation meets opportunity. A handpicked, cross-disciplinary student team builds one real venture in sixteen weeks, with industry mentors throughout. These are the seats we are recruiting for.
Playground Lab is a semester-long tech incubator that pairs university students with industry mentors to work on real projects for actual use. Over 16 weeks you'll move through three phases - ideate, build, and launch - as part of a small cross-disciplinary team, with technical and business mentorship throughout, and legal and other specialists available as needed.
This is not a class, and it is not a shadowing internship. You will do real work from the first week, and you will not do it alone. You will be surrounded by people whose job is to make sure you don't get stuck: mentors, a program team, and teammates. No one arrives knowing how to do all of this.
Cohort 01 is currently building Boujee Pet Care, a premium pet concierge app for gated communities. Cohort 02 will build something new.
Cohort 02's venture is already selected. It will be announced at the kickoff meeting in West Palm Beach in January 2027. That is where you will meet your team, hear the brief, and start the project. The goal is a working product delivered to the client inside the 16 weeks.
You'll be building for a real client, so the work is treated like professional work. The venture and everything the team builds for it belongs to Playground Lab and the client. What's yours is the experience, the skills, and a delivered product you can point to.
PlatformMobile, web, or desktop - set at kickoff
ClientReal client, professional work
IPStandard confidentiality & IP agreement
KickoffIn person and required
The roles below are starting points, not fixed job descriptions. Once the project is announced at kickoff, we define each person's actual scope around three things: your major and the training you already have, the areas you told us you want to grow in, and what the venture genuinely needs. Tell us what you want to learn in your application. We use it.
Every role is cross-functional by design. Run it like an early-stage startup, because that is what it is: a small team, a real deadline, and more work than there are titles to hold it. Designers file bugs and sit in on user interviews, developers weigh in on scope, the growth lead tests builds, and everyone talks to users.
Academic credit
Awarded by your university, structured so your department can approve it for credit hours toward your degree - undergraduate, master's, or PhD. We work through the process with you and provide whatever documentation your school needs.
Real exposure to industry mentors
Mentors who see how you work for sixteen weeks: how you handle a deadline, how you take feedback, and whether you finish. A far stronger signal than a résumé line, and the kind of relationship that can lead to a referral.
A portfolio piece that isn't hypothetical
A real delivered product you worked on, usable in your portfolio and on your résumé. We confirm before Demo Day what can be shown publicly.
You do not need to have done this before. Every role below lists things you may never have touched. That is expected, and it's the point. What we screen for is different:
→Evidence you finish things. A course project, a club you ran, a research paper, an event you organized. Scope doesn't matter; completion does.
→Willingness to work outside your title. Small teams don't have clean boundaries.
→Motivation over credentials. We would rather take someone who badly wants this and learns fast than someone with a longer résumé who doesn't.
→An honest read on your own availability. A 16-week project alongside a full course load is real.
→The instinct to ask why. The useful instinct is to ask why, not to defend the work.
We recruit across every discipline: computer science, engineering, business, policy, design, and beyond. Cross-disciplinary teams are a design choice, not an accident.
Every role mixes hands-on building with real analysis. Two are lead roles: the Project Lead, and the Design & Requirements Lead. We use Claude, Claude Code, and Claude Design throughout our projects, and every seat is expected to use them well. The expectation is simple: understand and test what you ship. If Claude wrote it and you can't explain it, it isn't ready.
If bullets in a role below sound unfamiliar, that is normal and expected. Those lists describe the work you will learn to do, not a checklist you need before you apply. Apply to the one closest to you; the exact shape gets drawn at kickoff around your major, your interests, and what the project needs. More than one student can share a role, so don't count yourself out if you assume a spot is already taken.
Lead role
Team direction, hands-on delivery, and the weekly build cadence — Listed as "Product" on the apply page
What you're responsible for: The outcome. Not one slice of the product, but whether the team ships at all. You set the direction, hold the schedule, keep your teammates unblocked and pointed the same way, and answer for the result in front of mentors, sponsors, and the room at Demo Day. When the semester ends, someone has to be able to say what happened and why. That's you.
What you'll be doing
→ Turn the kickoff brief into a scoped plan: a work breakdown, a milestone schedule, what's explicitly out, and what "done" means at each gate
→ Maintain the risk register: what could sink the semester, how likely, and what you're doing about it before it happens
→ Lead the team day to day: run the standups, protect people's focus, and clear the blockers your teammates can't clear themselves
→ Own the schedule. Track what's slipping, name it early, and make the call: cut scope, move a date, or ship it rougher than anyone wanted
→ Be the point of contact for mentors, sponsors, and program staff: status, escalations, and the questions nobody else has time to chase
→ Write the specs and decision docs the team builds from, clear enough that work starts without three follow-up questions
→ Run user research early and often, and turn what you hear into changes to the plan rather than a folder of notes
→ Define the metrics the team steers by, and keep the record of decisions and tradeoffs that mentor check-ins and the Demo Day story are built on
What you'll walk away knowing
→ How to lead peers with no authority over them, the hardest and most transferable management skill there is
→ Core project management practice you can name on a résumé: work breakdown, critical path, risk registers, change control, and status reporting
→ How to scope real work down to what a small team can genuinely deliver against a fixed deadline
→ How to manage upward: giving mentors and sponsors bad news early, with a plan attached
→ How to run user interviews that produce decisions rather than a pile of quotes
Tools you'll work in
Jira for tickets and the board, Confluence for decisions and reference docs, a team chat tool, Claude for drafting specs and status updates, and a spreadsheet for the schedule and risk register. No prior experience with any of them is expected.
You might be a fit if
→ You're the person who ends up organizing the group project, and you don't hate it
→ You've led something before: a team, a club, a lab, a chapter, a shift, a startup that went nowhere
→ You can hold a strong opinion and still change your mind when the evidence moves
→ You're willing to have the uncomfortable conversation about the timeline instead of hoping it resolves itself
→ You write clearly. Most of this role is written communication
→ Bonus, not required: project management coursework, PMP or CAPM exposure, agile certification, or a background in business, engineering management, MIS, or operations
No prior management or PM experience required, and this is not a coordinator seat. What can't be taught in 16 weeks is judgment under pressure and the willingness to make a call your team is counting on. Bring those; we'll teach the frameworks.
Lead role
Requirements, user flows, and the interface that comes out of them — Listed as "Design" on the apply page
What you're responsible for: The bridge between what stakeholders say they want and what the team actually builds. You run requirements gathering, turn it into documented flows and acceptance criteria, and then design the interface that satisfies them. This is the second lead seat: when the Project Lead owns whether the team delivers, you own whether what delivers is the right thing.
What you'll be doing
→ Run requirements elicitation with stakeholders, mentors, and users: interviews, workshops, and the follow-up questions that surface what the first conversation missed
→ Document requirements the team can build against: user stories, acceptance criteria, and a definition of done each developer can check their own work against
→ Map the current-state and future-state process: what a user does today, what they'd do with the product, and where the value appears
→ Design the product's screens and flows in Claude Design, from early concepts to build-ready specs, and own the brand and style guides behind them
→ Run usability testing as a measured exercise: task success rates, time on task, and where people drop out, not just impressions
→ Own change control: when a requirement shifts mid-build, you assess the impact, document it, and bring the tradeoff to the Project Lead
What you'll walk away knowing
→ Requirements elicitation and documentation, the core of business analysis, and the skill most job descriptions ask for by name
→ Process mapping and gap analysis, including how to model a workflow that doesn't exist yet
→ How to write acceptance criteria precise enough that "done" isn't a negotiation
→ How to run usability testing and read behavioral data rather than opinion
→ How to build a design system that survives contact with an actual codebase
→ Stakeholder management when two stakeholders want incompatible things
Tools you'll work in
Claude Design for brand and style guides, product designs, and marketing collateral, Claude for requirements drafting, Confluence for requirements documentation, a diagramming tool for process mapping, and Jira for tracking.
You might be a fit if
→ You ask the second and third question, not just the first
→ You can sit between a stakeholder who speaks in outcomes and a developer who needs specifics, and translate both directions
→ You write precisely. Ambiguity in a requirement becomes a bug three weeks later
→ You have a portfolio, a design file, or a class project you're proud of; polish matters less than intent
→ Bonus, not required: business analysis coursework, BABOK or IIBA exposure, process modeling (BPMN), systems analysis, or a background in MIS, HCI, industrial engineering, or design
This is a genuinely hybrid seat: half analyst, half designer. If you've done one and want the other, say so in your application; the scope gets drawn around that.
Mobile & data lead: web, mobile, the data model, and the analytics behind them — Listed as "Full-Stack" and "Mobile" on the apply page
What you're responsible for: The build, end to end. The backend and data model, the web and mobile surfaces users touch, and the instrumentation everything else gets measured by. You build the backend and the surfaces that sit on top of it, and you make sure the numbers the team argues about at Friday demo are numbers that can be trusted.
What you'll be doing
→ Design the data model with reporting in mind from day one, not bolted on in Week 12
→ Build the application layer, the web dashboard, and the mobile app when the venture calls for one - including platform-native features like location, camera, biometrics, or notifications
→ Design and maintain the API the client applications consume, including authentication
→ Build the event tracking and analytics layer, and stand up the internal dashboards the team runs on: funnel, retention, and the venture's core metric
→ Own data quality. A metric nobody trusts is worse than no metric, and tracking bugs are invisible until someone makes a bad call on them
→ Write tests as you build. Everything we ship carries proper test coverage, and it is checked at review
→ Ship through an automated pipeline: tests and deployment on industry-standard CI, with monitoring and the unglamorous parts of keeping it running
→ Handle release and distribution: app store review if we ship mobile, or deployment and release notes if we ship web, plus beta builds and tester feedback
What you'll walk away knowing
→ How a production application is structured - not a tutorial project, one with real users and real data
→ A modern full-stack framework end to end (Cohort 01 works in Laravel with Vue and Inertia; Cohort 02's stack is set at kickoff)
→ Cross-platform mobile development when the venture ships an app (Cohort 01 works in Flutter and Dart)
→ Product analytics as a discipline: activation, retention, cohort analysis, and funnel instrumentation
→ SQL against a schema you helped design, which is the fastest way to learn what makes a schema good
→ Deployment, monitoring, and debugging problems that only appear in production
→ How to work effectively with AI development tooling as a serious part of your workflow
Tools you'll work in
A modern web framework, MySQL, SQL, reporting and product analytics tooling, VS Code, Git and GitHub with pull-request review, and Claude Code in the repos. When the venture ships a mobile app, the matching platform tooling comes with it. Paid licenses are provided, so you buy nothing.
You might be a fit if
→ You can write code in at least one language, even if everything you've built so far was for a class
→ You understand relational data, or want to get good at it fast
→ You're the person who asks where a number came from before believing it
→ You use Git, or can learn it in a weekend
→ You want range: the backend, the app users touch, and the data underneath, rather than one narrow slice
→ Bonus, not required: MySQL, REST API experience, dbt or a BI tool, a stats or data science background, or prior work with Claude Code, Cursor, or similar tools
This is the widest role in the cohort, and more than one student can share it. If you're strongest on the backend, on mobile, or on the data and analytics side, say which in your application. Data and stats students who can code belong here too, even if you've never called yourself a developer.
Market sizing, positioning, launch, and the metrics behind the first users — Listed as "Growth" on the apply page
What you're responsible for: Demand, and the analysis that directs it. You size the market, define the positioning, build the pipeline of first users before there's a product to show them, and then measure which of your channels is working instead of guessing.
What you'll be doing
→ Build the market analysis: segment sizing, competitor teardown, and pricing research the team's decisions can rest on
→ Define the positioning: who this is for, what it replaces, and why anyone should switch
→ Stand up a landing page with email capture in the first weeks and keep the list warm through the build
→ Run outreach to the partners, communities, or organizations that get the product in front of its first users
→ Build the acquisition model: channel-by-channel cost, conversion rate, and payback. A real model, not a slide
→ Track the funnel from impression to signup to activation, and cut what isn't converting
→ Convert early signups into beta testers and turn their feedback into both product input and testimonials
→ Own the traction narrative for Demo Day and mentor conversations: the numbers and the story they support
What you'll walk away knowing
→ Market sizing and competitive analysis done properly, with defensible assumptions
→ Funnel and cohort analysis applied to acquisition rather than product
→ How to launch from zero: no budget, no audience, no brand recognition
→ Copywriting that converts, which is a distinct skill from writing well
→ How to present traction to investors and mentors without overstating it
Tools you'll work in
A spreadsheet for the acquisition model, Claude for research and copy drafts, Claude Design for landing pages and launch collateral, web analytics and email marketing tooling, and Jira and Confluence alongside the rest of the team.
You might be a fit if
→ You're comfortable in a spreadsheet and can build a model that someone else can follow
→ You write well and quickly, and can shift register between a landing page and a cold email
→ You'll send the email, make the call, and follow up after being ignored twice
→ You've grown something before: a club, a newsletter, an account, an event, a small business
→ Bonus, not required: finance, marketing analytics, market research, or consulting coursework; SQL; Google Analytics; or paid acquisition experience
The shared codebase and the weekly demo keep everyone pointed in the same direction: one place the work integrates, one moment each week where it has to hold together in front of the room.
The rhythm is a short daily standup, a weekly team call, and continuous backlog prioritization. Mentors are available throughout for technical and business questions, with legal and other specialists brought in as needed. The semester ends with Demo Day, where the team presents what it built - in person, where sixteen weeks earlier none of it existed.
01
Kickoff
January, West Palm Beach: the project is announced, teams form, each person's scope is defined, and the first sprint gets planned.
02
Ideate
User research, scoping the MVP, designing the core flows, and standing up the repo and the landing page.
03
Build
Weekly shipping cycles, beta testing with real users, and continuous iteration on what they tell you.
04
Launch
Production release and distribution, the acquisition push, and Demo Day.
08Eligibility & how to apply
Eligibility
→ Currently enrolled in a degree program: undergraduate, master's, or PhD
→ Available for the full 16-week semester
→ A computer you can install development tools on - we provide the paid licenses, so you buy nothing
→ Able to attend the in-person kickoff in West Palm Beach, Florida, in January 2027
→ Any academic discipline - we recruit across a wide range of fields
→ Willing to secure your department's approval for credit hours before the semester begins
Email hello@playgroundlab.org with four things
01 A brief note: what you've built or run before, and why this role
02 Your résumé or portfolio
03 The role that fits you best, and your major or program
04 What you want to get better at: the areas you'd like your scope to reach into, even if they're outside the role you picked
That last one is not a formality. Because scopes are shaped around majors and interests at kickoff, what you tell us here directly affects the work you end up owning. Applying to more than one role is fine - tell us your order of preference and why.
Selection is competitive, but if you are unsure whether you are ready, apply anyway and let us make that call. We read every application.