A six-month, fully remote programme where small teams build a real product. We started Foundry because we don't think you learn to build software from a syllabus. You learn by shipping things and figuring out what's wrong with them.
We split Foundry into three phases, but they're a description of the shape of the work, not a strict timeline. Some teams blow through the first phase in a week. Others spend a month figuring out the problem before they touch code. We don't grade you on the calendar.
We pair you with two or three others. We look at strengths and what each person wants to learn, but we don't pretend we always get the matching right. You pick a problem from a list we've vetted — real ones, the kind a client would hand you with half the requirements missing. If none of them fit, you pitch your own and we decide together.
Twelve weeks of building. You'll have a mentor, a senior engineer or founder we work with, who reviews your code, asks the questions you're avoiding, and tells you when you're solving the wrong problem. Some weeks you'll ship something solid. Other weeks you'll scrap most of it and start over. That's the work.
Final phase. You take what you've built and get it in front of real users. Some products find traction. Some don't. Either way you learn something useful, and you walk out with the product, the lessons from the build, and a team that's been through six months together.
There's no diploma at the end. What you walk out with is what you built and the people you built it with. Here's what that adds up to in practice.
You're not building a toy. The problem is real, the constraints are real, and you're solving for something that matters to whoever brought it to us. There's no "graded on effort" — what you ship either works or it doesn't.
You're on a team of three or four. There's no team lead and no individual deliverables — what ships, ships under all your names. We've found this matters more than people think. Building alone teaches you different lessons than building with people who push back on your decisions.
Mentors are senior engineers and founders we know personally. They review your code, ask why you made the calls you made, and tell you when you're going in circles. They won't write code for you and they won't give you the answer.
Whatever your team builds, your team owns. Friedbot Studio doesn't take equity, IP rights, or a share. After six months you can keep building it, sell it, open-source it, or shelve it. We thought about this hard — it's the only model where the incentives line up.
It started in February 2026 and runs through mid-2026. Cohort 1is also our first cohort, so we're learning what works and what doesn't alongside the teams. Applications for Cohort 2 open when Cohort 1 finishes — likely with changes based on what we learn this round. The waitlist is the first stop.
Foundry takes real time. Six months isn't trivial, even remote. Read these honestly. They're written more to help you disqualify yourself than to sell you in. If most of them sound like you, the waitlist is the right move.
Even something small. You've felt the gap between the version that's almost done and the version that's actually shipped, and you've crossed it at least once.
Most of what we hand you won't have a clear path. You're the kind of person who asks one good question and moves, not someone who waits for the spec to be complete.
You're not a passenger. You write, review code, debate decisions, and take on the parts of a build that nobody else wants.
You're past the stage where you want someone to assign your tasks or hand you a syllabus. You want the kind of help that helps you make your own calls better.
Foundry is fully remote, which doesn't mean part-time or low-effort. The hours have to come from somewhere. Don't sign up if they don't have anywhere to come from.
Drop your email and we'll let you know when Cohort 2 applications open. We won't use it for anything else — no newsletter, no drip, no follow-up. Just one note when the next round starts.
Not ready for that? Just say hello.
