TL;DR
ScriptFabric started with a problem its own team needed to solve: making Jira scripting more accessible with Javascript instead of relying on specialized Groovy expertise. The team chose Forge for its managed platform and modern development model, learned the platform by building and shipping, and eventually turned an internal solution into a Marketplace app. Their journey also surfaced useful lessons for other developers: start with a real problem, build something small end to end, and let what you learn along the way shape where the app goes next.
The Origin Story
A lot of developer tools start the same way: someone on a team gets frustrated with an existing workflow and decides to build something better. That’s essentially how ScriptFabric started. The team saw a familiar problem in the Jira ecosystem: scripting and automation could be incredibly powerful, but taking advantage of them often required specialized knowledge, particularly Groovy expertise. For teams already building with JavaScript and TypeScript every day, that created an unnecessary barrier.
ScriptFabric began as an answer to a problem the team was experiencing themselves: What if scripting in Jira felt more like the modern JavaScript development workflows developers already know? That question eventually took them to Forge, transforming an internal need into a Marketplace app.
I recently sat down with the ScriptFabric team members Hoysala Garudanagiri and Sandeep Kuruva from Canarys Automations Limited to understand why they chose Forge, what was easier than expected, where they encountered friction, and what they would tell another developer thinking about building on the platform. What stood out to me was how quickly their experience moved from “Can we build this?” to “How far can we take it?”
Choosing Forge (and JavaScript)
One of the clearest decisions the ScriptFabric team made early was that they didn’t want to build the future of their product around Groovy. They wanted JavaScript and TypeScript—not simply because of language preference, but because they were thinking about who should be able to build and extend Jira experiences.
JavaScript and TypeScript have enormous developer ecosystems. By building around those ecosystems, ScriptFabric could make scripting more approachable for developers without requiring them to learn a specialized language before they could start solving problems. As Hoysala explained, their own teams wanted a similar tool, but they didn’t have enough Groovy expertise to build with confidence. JavaScript and TypeScript offered a more familiar and accessible path.
Forge gave the team something else they cared about: a managed platform. They didn’t need to stand up their own infrastructure before they could start building. Authentication, hosting, permissions, and much of the connection to Atlassian products were already part of the platform. That let the team focus on the scripting experience instead of rebuilding the surrounding platform plumbing, making Forge a natural fit for ScriptFabric.
You learn Forge by actually shipping something
One thing I appreciated about the ScriptFabric team’s story is that they didn’t portray learning Forge as a perfectly linear process. They began with the documentation, but the mental model clicked only after they completed the full development loop themselves. As Sandeep explained, the team learned Forge by moving through the complete cycle—learning, developing, deploying, testing, and repeating. He called it a good journey.
Some concepts came quickly. Having the runtime managed for them meant there was significantly less infrastructure work than they might have encountered elsewhere. The relationship between local development, tunneling, deployment, installation, and testing inside an Atlassian site is something you understand differently after you’ve done it a few times.
That leads to advice I think is useful for almost anyone starting with Forge: don’t make your first goal “learn Forge.” Make your first goal “ship one small Forge app end to end.” You can spend days reading about modules, manifests, permissions, environments, and deployment commands, or you can build something intentionally small, take it through the complete lifecycle, and develop a working mental model.
Start with the fastest path and graduate when you need to
We also talked about the different ways developers can enter the Forge ecosystem. The ScriptFabric team experimented with Studio during that process, and I think their experience points to a useful way of thinking about Forge’s different development paths: you don’t necessarily need to choose one tool forever.
Studio can provide a fast way to prototype an idea, explore what’s possible, and get something tangible in front of you quickly. That matters because sometimes the hardest part of building an app is moving from an idea in your head to a first version you can interact with. But ScriptFabric isn’t a small prototype—it’s a feature-rich Marketplace product with a growing roadmap and an active development team.
At that stage, the Forge CLI and a more traditional development workflow became the right home for the project. I don’t see that as one path winning over another; I see it as progression. Use the fastest path that fits the problem you’re solving now, and if the app grows beyond that workflow, move to the environment that gives you the control you need.
What surprised them about building on Forge
I always want to ask teams what surprised them, because that’s usually where you get past the feature list and into the actual developer experience. For ScriptFabric, some of the positive surprises came down to how much Forge handled for them.
For ScriptFabric, that meant less time spent on work outside its core product. The team didn’t have to maintain infrastructure just to keep the app running, build a connection to Jira from scratch, or recreate basic platform capabilities. Instead, the Forge manifest provided a central place to define how the app connected to the Atlassian ecosystem.
But the journey also had some sharp edges. The publishing process wasn’t frictionless, and there were moments on the path to Marketplace when the team had to work through issues with Atlassian. I’m calling that out because developer stories are more useful when they don’t pretend everything worked the first time. It didn’t—and that’s okay. What mattered to me was that the team was specific about what wasn’t working, giving the responsible teams actionable feedback they can use to improve the platform.
The moment an internal tool becomes a product
ScriptFabric also represents a pattern I think more developers in the Atlassian ecosystem should pay attention to. The app didn’t begin with, “We should start a Marketplace company.” It began with a problem: the team needed a better way to work with scripting and automation, so they built one.
Then they realized the problem wasn’t unique to them. That’s the point where an internal tool starts becoming a product. Of course, there is still work between those two states. A Marketplace app needs more than functioning code. The team had to think about packaging, pricing, positioning, competitive alternatives, onboarding, and how someone outside the company would understand the value of what they created.
Going to Marketplace forced them to think like product builders, not just developers, but the technical idea had already been proven internally. That’s one of my biggest takeaways from their story: the thing your team built to solve its own annoying problem might already contain the beginnings of a Marketplace app. You don’t need to start by searching for a billion-dollar idea. Start with a real problem and solve it well.
Where ScriptFabric goes next
The interesting thing is that getting to Marketplace wasn’t the end of the team’s story; it opened up a much bigger roadmap. They’re exploring deeper integrations with developer tools, including GitHub and Bitbucket, and they’re thinking about new automation experiences.
They’re also looking at how AI can make scripting more accessible, including experiences where a developer can describe what they want to accomplish and the app helps produce the JavaScript. At the same time, they’re thinking about a challenge that is becoming increasingly relevant across the Jira ecosystem: helping teams move existing scripting knowledge and workflows toward JavaScript.
I’m excited to see where they take it. The next phase of ScriptFabric’s journey will be shaped not only by the problem that started the app, but also by the broader developer needs the team has uncovered along the way.
If you’re thinking about building on Forge
After talking with the ScriptFabric team, the advice I’d give another developer is simple: build the smallest version of your idea that can go through the complete Forge lifecycle—learn, develop, deploy, test, and repeat.
Once that loop feels normal, you have a foundation. From there, you can decide how far you want to go. Maybe the app stays as an internal tool your team uses every day. Maybe it becomes something you share more broadly within your organization. Or, like ScriptFabric, you may realize that the problem you solved for yourself is a problem thousands of other Atlassian users have too.
If you’re at the beginning of that journey, start with Forge developer resources and work through one complete build before worrying about everything that comes after it. ScriptFabric started because its team needed a better path. If you’re standing in the same place, there are more ways than ever to turn that first idea into something real and see where it goes.
