I spend a good part of my year in rooms with experienced enterprise developers taking their first steps on Forge, usually with a Data Center deadline somewhere behind them. Full transparency: running these workshops is part of my job at Seibert. This post is not about the workshops though. It is about the pattern I did not expect when we started, and that has held up across every single team since: it is almost never Forge itself that trips people up.
Here are the five places where strong teams actually stumble, with the details I wish someone had handed me before the first session.
1. The struggle is JavaScript culture, not the Forge API
Every DC-heavy team arrives expecting to learn Forge. The Forge API turns out to be the easy part: well documented, and there is not that much of it. What actually costs the first day is the ecosystem jump. In JavaScript, "1" + 1 is "11" and "1" - 1 is 0, and typeof null is 'object'. Watching a senior Java developer meet these for the first time is a ritual by now.
The individual differences are all small. What makes them expensive is that they are mindset changes stacked on top of each other: dynamic typing after a lifetime of compilers, an event loop after threads, npm after Maven, two kinds of nothing after one kind of null, and React as its own way of thinking on top. My takeaway for anyone onboarding Java colleagues onto Forge: run them through the potholes explicitly and early. Experienced devs cross this gap in days when the potholes are named, and in weeks when every one of them is a surprise.
2. The corporate network eats more workshop hours than any bug
The closest I have come to losing a full training day had nothing to do with code: laptops ready, coffee poured, and a corporate network that silently refused to let anything talk to the outside world. No recognizable error. Just spinners.
A Forge dev setup does precisely the things enterprise networks are built to distrust: pull packages from the internet, authenticate against cloud services, open a tunnel from a laptop to a dev environment. Proxies, SSL inspection and allowlists all doing their job, and their job is to stop exactly that. The fix was embarrassingly simple: a thirty-minute remote check on the real machines, in the real network, one to two weeks before the session. Boring every single time, and it has saved every first morning since. If you are planning any hands-on enablement inside a corporate network, steal this.
3. The ten-second decisions are the ones teams live with
My favorite demonstration: two teams build the same small Jira app, same feature, same afternoon, same amount of code. One stores the data in the app's own storage, the other writes it onto the issue as an entity property with an index. Half a year later, the first team's data is invisible to every JQL search in the instance, the second team's data drives filters, reports and dashboards. Nobody wrote worse code. One storage decision, made in seconds on day one, decided what the product can do.
Permissions are the same shape of trap, sharper edge: asApp() where the situation needed asUser() is not a bug you will find in testing, because whoever tests it usually has access to everything anyway. It behaves perfectly right up until it quietly shows a user data they were never supposed to see.
The docs list every module and storage option accurately, but they answer "what exists", not "which one fits". If you review Forge apps: look at these two decisions first, before any line of implementation.
4. AI gets you a working app, and four plausible wrong numbers
AI splits every workshop room in two. Some participants build with an assistant from the first minute, others deliberately write everything by hand to learn the platform properly. Both are fine, and we never prescribe one. What we do hold everyone to is a baseline: with or without AI support, you understand what is happening and what is being produced. The prompt is not the app. If you cannot explain why your panel shows that number, you are not done, no matter which of the two camps you sit in.
Why that baseline is not pedantry, an experiment: I asked an AI builder for a Jira issue panel. First try, it worked: real data, story points summed from the right field, clean manifest, single scope, tests, linting. Honestly better than many hand-written first drafts. (The full expedition, taking an AI-built app all the way toward production, is its own story: An Explorer's Log: Taking a Rovo Studio App All the Way to Production.)
The code review still found four things. No pagination, so a large epic silently reports a partial total. A story-point lookup that is correct in company-managed projects and wrong in team-managed ones. Only Stories counted, so mixed epics under-report. And mock data still reachable in the shipped bundle. The common thread: none of them throws an error. Every one of them produces a plausible number.
Two more findings from that trip, familiar to readers of the Explorer's Log, that keep proving themselves in workshops. First, secret handling: the tool correctly lectured me to keep secrets out of code, and then, a few turns later, asked me to paste a live API key into the chat. Second, the export is a one-way door: once you download the generated project and continue with the Forge CLI, there is no clean path back into the builder, so pick your source of truth at that moment or the two sides will overwrite each other.
None of this is an argument against AI-assisted Forge development, I use it daily and Rovo Agents are a first-class module now. It is the argument for the baseline: treat "it works" as a hypothesis, review the parts that fail silently, pagination, project types, edge data, bundles, secrets, and stay able to explain what the generated code does. The teams in our workshops that use AI and hold that line are, without question, the fastest in the room.
5. Cloud removes hosting, not operations
The sentence I hear most after go-live: "we moved to cloud, so operations is taken care of." Half true. Servers, patching and uptime are genuinely gone, Atlassian runs the platform well. The rest stays: your app calls APIs that evolve, meets production data that stops resembling test data, consumes resources that beyond the free tier become an invoice, and, my favorite twist, upgrades that add scopes wait for admin consent, so your installed base quietly fans out across versions and a fix only lands where the upgrade did.
The Developer Console has everything you need, deployments, logs, metrics, consumption, but it only works if someone actually opens it. In my experience the logs are also the only party that consistently tells the truth when an AI tool, the docs and my own confident theories disagree.
The quiet moment
The best part of every workshop is the quietest: someone deploys, switches tabs, and their own app renders inside Jira for the first time. That moment is the whole point, the proof that a DC team can genuinely do this. Everything above is just the list of things standing between that moment and an app you would trust in production.
I am curious about other people's field notes. If you have onboarded Java-era teams onto Forge, or reviewed AI-generated Forge apps: what tripped your teams up that I have not listed here?
PS: find some more insights from our workshops in this blog article
https://www.forge-apps.com/blog/dc-plugin-to-forge-app-decisions
![Photo of Paul Pasler [Seibert]](https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/557058:16d1f9bb-612b-43a6-ac1b-8857c60c5182/e35f4b50-5f2f-4df0-87f3-7d1be5a76df6/128)
