FlutterFlow
Build cross-platform mobile apps visually
4.4•43 reviews•3.4K followers
Build cross-platform mobile apps visually
4.4•43 reviews•3.4K followers
Create beautiful UI, generate clean code, and deploy to the app stores or web in one click. Fully extensible with custom code.
This is the 10th launch from FlutterFlow. View more
Campus
Launched this week
Campus gives builders a shared space to build with teammates and AI agents. Keep your repo, terminal, project knowledge, conversations, and agent work together in one persistent workspace, instead of scattering context across Slack threads, docs, tickets, canvases, and one-off AI chats. Campus is organized around the thing you are building, so humans and agents can pick up where the work left off.
Free
Launch Team
FlutterFlow
Hey Product Hunt! Alex here, co-founder of FlutterFlow.
Not long ago, I used to have 20+ terminal tabs open, each connected to a different part of my projects. Claude in one. Codex in another. Browser tabs, docs, notes, Git worktrees, design files, all scattered across different windows. Every time I switched tasks, I had to remember where everything was and rebuild context.
It got even harder because we're a remote team. I wanted to share context, get feedback, and see what everyone was working on without scheduling another meeting or asking someone to share their screen.
So we built Campus.
Campus gives every project its own persistent workspace. Instead of jumping between apps, everything lives together on one canvas: terminals, browsers, documents, designs, files, AI agents, and most importantly your teammates. When you come back tomorrow or someone new joins the project, the context is already there.
Today our entire team builds in Campus every day, and it's completely changed how we work together. My favorite part is the sense of connection - we’re dropping GIF reactions, memes, and screenshots into the canvas mid-build.
Download Campus and create your first work area: campus.flutterflow.io
Happy to answer anything in the comments.
— Alex, co-founder at FlutterFlow
FlutterFlow
@agreaves okayyyy but being able to execute INSIDE of Campus is actually wild.
and the gifs/memes really do pop off over here.
everyone, get your whole team to join, build, AND joke together! literal best way to do team bonding :)
@agreaves What’s one concrete example of a recurring pain or workflow your team had before Campus, and how did moving that workflow into a persistent Campus workspace change measurable outcomes like time-to-merge, number of meetings, or onboarding time for a new teammate?
Campus feels most useful if it keeps the context handoff map, not just the tools, in one place.
When I run Claude/Codex alongside normal dev work, the hard part is usually returning later and knowing: what did the agent inspect, what assumption did it make, which terminal state mattered, and what still needs a human review.
If Campus can make that history easy for a teammate or future-me to scan, that is a stronger workflow win than simply having fewer tabs open.
FlutterFlow
@grace_lee26 totally - that's the goal. Give it a try and let us know what you think!
FlutterFlow
@grace_lee26 totally agree. The biggest bottleneck right now is context switching.
We're actively optimizing Campus to be equally easy to use for a human & an AI!
FlutterFlow
@grace_lee26 future-me matters SO. MUCH.
The project-first structure makes a lot of sense. as someone building with a small team and using several AI tools, the hardest part is often not the work itself, but keeping terminals, conversations, docs, decisions, and agent context connected without constantly rebuilding the mental map.
I also like that Campus includes the social side of building, not just another serious productivity dashboard. GIFs, screenshots, and quick reactions probably matter more for remote teams than people admit :) Curious how Campus handles multiple agents or teammates changing the same project at once. can everyone clearly see what changed, why it changed, and safely roll back or branch the work?
FlutterFlow
@andrasczeizel Campus runs 'local first', meaning everybody is working on their own local files and local terminal sessions. By default terminals are view-only for team-members in the same room (think, everybody sitting in the same physical room but working on their own computers). You can however setup shared workspaces where everybody has access to terminal/files etc. for collaborating on the same files. More on this in future Campus releases! :)
FlutterFlow
@andrasczeizel @norbert1 not to mention the social side brings us all back into one spot - nothing like judging your teammate's song choices :)
FlutterFlow
@andrasczeizel Norbert gave a great answer, but "GIFs, screenshots, and quick reactions probably matter more for remote teams than people admit :)" is so true!
Once we started using it we felt instantly more connected as a team, it's almost like being in an office and feeling the "hum" of the room. Also, the easter eggs can be fun :)
FlutterFlow
@andrasczeizel @agreaves the "hum" of the room is real
FlutterFlow
@ridhwikvinod this is a great question! i'm a growth lead so i know what you mean hehe
we're still in alpha, but i've found that i really love to use Campus to see what my team is building in real-time and actually build my marketing campaigns that way. so instead of having product and marketing separated in silos, there's a more unified sense of vision (and PROGRESS UPDATES)
FlutterFlow
@ridhwikvinod @lydia_lee3 to add to this. In this very first release Campus definitely is more optimized for the developer archetype, just because that's how we're mostly using it.
The bigger vision (and future update will reflect this) is to better support any possible workflow!
FlutterFlow
@ridhwikvinod love this question! We initially built Campus for ourselves to make it as low friction as possible to manage our work, which also means keeping the technical barrier low. So as long as you're building with agents and want your team and other agents to share context, there's nothing stopping your whole team!
This looks really compelling. How do agents on the canvas get their context, do they read the full repo, docs and past conversations automatically, or can you scope what each agent is allowed to see and touch (repo vs terminal vs docs)? Curious how you keep multiple agents' work reviewable when they're building alongside the team.
FlutterFlow
@thisisgach
on context: agents in Campus get context from what's on the canvas, not from automatic full-repo ingestion. the idea is that you decide what each agent can see by what you put in their workarea. if you tile a terminal, a git worktree, a doc, and a browser preview together, the agent working in that context has access to those things. it's spatial scoping rather than permission-based scoping. you control it by what you put in front of it!
the Campus CLI is what gives agents the ability to act: move tiles, type into terminals, interact with webviews. so an agent can only touch what it can reach via the CLI in its workarea. if you don't give it access to a terminal, it can't run commands in it.
FlutterFlow
@thisisgach just to tack onto this, each work area is scoped to a folder, so if you create one for a repo, a new agent tile in it it will have full access to the repo! And in general, each agent can use the CLI to view what other agents on campus are doing and view any outputs or assets from them.
The challenge of shared context between human devs and AI agents is underrated. Most tools treat AI as a sidecar; mixing them in the same project space changes how you think about state and handoffs. Figuring out where agent context ends and human context begins is one of those problems that bites you late. How do you handle concurrent writes from agents and humans on the same resource?
FlutterFlow
@anand_thakkar1 couldn't agree more, Anand! For code, we recommend the tried and true version control (as a team we lean heavily into worktrees). For most non-code resources it's effectively live collaboration (via CRDT) and making sure that agents have the tools (via the CLI) to understand what's currently present in the canvas live.
the "one persistent workspace instead of scattering across Slack/docs/tickets" pitch makes sense for the human side, but I'm curious about the agent side specifically - if two different agents (or an agent and a human) are working on the same repo context at the same time, does Campus have any concept of locking or conflict resolution, or is it more like a shared read layer where the actual edits still happen elsewhere and could still collide?
FlutterFlow
@omri_ben_shoham1 great question! When it comes to working on code, in our experience git is the best layer for version control and context resolution. But for non-code assets and context, it's live collaboration so agents see the realtime state of the canvas (via the CLI) and can update it accordingly, with Campus using CRDT for conflict resolution if it's coming from separate users.