5 Questions with Shin Nagasada (DevSamurai)

About Shin

Shin Nagasada · DevSamurai CEO · Tokyo, Japan

"We got here because we kept showing up."

Shin is the founder and CEO of DevSamurai. The company entered an already crowded Atlassian Marketplace from scratch and has grown to 20 apps.

Areas of expertise: Atlassian Marketplace entrepreneurship · SaaS product strategy and growth · product-led growth · ecosystem partnerships · enterprise software engineering · AI-driven development and governance

1. DevSamurai entered an already crowded Marketplace, started from scratch, and has grown to 20 apps. What kept you going long enough to get there?

A mix of curiosity, stubbornness, and discipline. Probably a little too much stubbornness. 😄

When we entered the Atlassian Marketplace, it was already crowded. We had no big brand, no established customer base, and no guarantee that anyone would care about what we built.

But as engineers, we believed there were still plenty of real problems worth solving. So we focused on what we could control: building useful products, listening to customers, learning from mistakes, and making things better one release at a time.

Of course, there were frustrating moments. Features that didn't work out, decisions we had to rethink, and times when progress felt painfully slow.

One thing I've learned is that building products isn't about staying excited all the time. The excitement eventually wears off. What matters is whether you're willing to keep doing the work when it becomes repetitive, difficult, or even boring.

I guess the rocker in me wanted to do things our own way, while the samurai in me kept reminding me to stay disciplined and see things through.

Twenty apps later, we're still learning, still making mistakes, and still improving.

We didn't get here because we had everything figured out. We got here because we kept showing up.

And honestly, I'm still having fun building things. More apps are coming soon 😄

2. Some of your apps started with problems your own team was facing, while your experience with the CRM app showed that not every internal problem has a wider market. How do you test today whether a problem is worth solving for other teams, too?

One lesson I learned the hard way is that just because we have a problem doesn't mean everyone else has it. 😄

In the early days, we often built apps to solve problems our own team was facing. That worked well for some products, but our CRM app taught us that solving your own problem and finding a real market are two different things.

These days, I try to be more disciplined before jumping into development.

First, we look for evidence that other teams face the same problem. We talk to potential customers, study how they're handling it today, and try to understand how painful and frequent the problem really is.

Then comes an important question: Is this a problem people actually want to pay to solve, or just something they agree would be nice to have?

Those are very different things. People are usually quite generous with compliments, especially when they aren't paying. 😂

We also look at existing solutions. A crowded market doesn't necessarily scare me. Sometimes it's proof that there's real demand. The question is whether we can solve something meaningfully better or serve customers who are still underserved.

And whenever possible, we start small, get something into users' hands, and learn from their actual behavior rather than relying on our assumptions.

I still trust my engineering instincts to spot problems, but I've learned not to trust them blindly when judging market demand.

A good engineer asks, "Can we build it?" A good product builder also asks, "Should we build it?"

And sometimes, the most disciplined decision is to leave a perfectly good idea alone.

Illustration, not product data.

3. Product-led growth is a big part of your approach, but no company succeeds entirely on its own in the Atlassian ecosystem. How do you identify Solution Partners and other vendors who are a good fit for DevSamurai, and what are the early signs that a partnership has real potential?

I've always believed that a good product is the foundation, but good relationships help it go much further.

Product-led growth has worked well for us because customers can discover our apps, try them, and see the value themselves. But Solution Partners bring something we can't get from product analytics alone: a deeper understanding of customers, their businesses, and the problems they face every day.

When looking for partners, I focus less on how big they are and more on whether we can genuinely help each other create value for customers.

For Solution Partners, I look for teams who understand their customers well, care about solving real problems, and see our products as something that can strengthen their solutions. For other vendors, it's often about complementary products, shared customers, and opportunities to solve bigger problems together.

The early signs are usually quite simple. A promising partner talks about customer problems before talking about commissions. They bring real use cases, share honest feedback, introduce opportunities, and most importantly, follow through on what we discuss.

I've learned that partnerships are a bit like building products. It's easy to get excited at the beginning, have a great meeting, and come up with ten brilliant ideas. Then everyone gets busy, and six months later, nothing has happened. 😂

So I prefer starting small. Work together on one real customer problem, see how we collaborate, and build trust from there.

I don't think the best partnerships are built around how much business we can get from each other. They're built around how much more value we can deliver to customers together.

And like any good relationship, trust matters more than a beautiful partnership presentation. 😄

4. Jira work items can now be assigned to coding agents. But when someone later asks, "Who changed this, when, and why?", how well can a typical Jira site answer that question today? And what needs to change as agents take on more of the work?

That's a very interesting question, especially now that "who" might not even be a human anymore. 😄

Jira already gives us part of the answer. We have work item history, comments, activity logs, and integrations with development tools to track commits and pull requests. So finding out what changed and when is generally possible, assuming everything is connected and configured properly.

But why something changed is a different story.

Even with human developers, we've all seen commit messages like "fixed bug" or "minor changes." Very informative, right? 😂

Now imagine AI agents doing a significant part of the work. We need to know more than which agent executed a task. Who instructed it? What was it trying to achieve? What decisions did it make? What code did it change? And who reviewed and approved the result?

I think the next step is moving from simple activity tracking toward end-to-end traceability and accountability.

That means connecting the original requirement, the agent's instructions and actions, code changes, tests, reviews, and deployment into a clear history. Not necessarily recording every little thing an agent does, but capturing the important decisions and evidence.

And we need to distinguish between work performed by humans and agents, while making it clear who is ultimately responsible.

As an engineer, I'm excited about how much faster we can build with AI. But as someone responsible for products and customers, I also know that building faster means we need to become even more disciplined about quality, security, and accountability.

Otherwise, AI might just help us make mistakes at an impressive speed. 😄

I believe Jira has a great opportunity to evolve from a system that tracks work into one that helps us understand and trust how work gets done—whether by humans or AI agents.

Agents can take over tasks, but they shouldn't take accountability away from people.

Illustration, not product data.

5. People often say that AI could build almost anything overnight. In your experience, what still makes a product something customers trust and rely on? And what advice would you give someone building their first Marketplace app today?

AI has made building software incredibly fast. Today, you can describe an idea and have a working prototype in hours. As an engineer, I wish we'd had these tools 20 years ago! 😂

But building something that works is not the same as building something customers can rely on.

A demo usually shows the happy path. Real products have to deal with messy data, unexpected user behavior, different configurations, security, performance, and all those edge cases nobody thought about.

And when something breaks in production, nobody cares whether the code was written by a developer or AI. They just want it fixed.

For someone building their first Atlassian Marketplace app today, I'd offer a few practical lessons from our experience.

First, find a very specific problem inside a Jira or Confluence workflow. Don't try to build an all-in-one solution. Find something users struggle with repeatedly, understand how they work around it today, and solve that one problem exceptionally well.

Second, understand the Atlassian platform before building too much. Learn Forge, the permission model, API limitations, and Marketplace requirements. Test your app across different Jira project types, configurations, and user permissions. Something that works beautifully on your development site might behave very differently on a customer's instance with thousands of users.

Third, don't underestimate everything outside the features. Security, performance, documentation, onboarding, and customer support are part of the product. Especially in the Marketplace, where customers expect your app to work reliably inside systems they depend on every day.

And finally, release early, but don't release carelessly. Start small, get real customers, observe how they actually use your app, and keep improving. Don't spend six months polishing features nobody has asked for. I've learned that lesson the expensive way. 😄

I think AI creates a fantastic opportunity for new Marketplace developers. You can experiment faster, build with smaller teams, and compete with much larger companies.

But it also means more apps, more competition, and more noise.

The real advantage won't be who can generate the most features. It'll be who understands the customer's problem best and solves it most reliably.

AI can help you move faster. Engineering judgment and product discipline still determine where you're going.

Five lessons from Shin Nagasada

1. Keep showing up. Excitement wears off. What counts is doing the work when it becomes repetitive, difficult or even boring.

2. Ask whether you should build it. Before a new app, field, workflow or automation, check that other people really need it, not just agree it would be nice to have.

3. Start with one real problem. Whether you work with a vendor or a Solution Partner, solve one customer problem together first. Good partners talk about the problem before the commission.

4. More automation needs clearer accountability. As agents take on more work, connect instructions, actions, reviews and deployments into one history, and keep human responsibility explicit.

5. Judge an app by what happens outside the demo. A demo shows the happy path. Security, performance, documentation and support decide whether you can rely on it.

Thank You

Our sincere thanks to Shin Nagasada for an honest and often witty look at what it takes to build a Marketplace business, from testing whether a problem is worth solving to building partnerships and keeping people accountable as agents take on more work.

We truly appreciate your time and your openness.

About this series

5 Questions in the Atlassian Universe is an interview series by MetaFrazo featuring experienced practitioners from across the Atlassian ecosystem.

Each conversation explores practical lessons and real challenges from people who build, run and grow work in the Atlassian ecosystem.

Because the best ideas don't come from tools alone. They come from the people who use them every day.

About MetaFrazo

MetaFrazo turns the events of your Jira Cloud site into operational, governance and compliance analytics. See what changed. See who changed it. Without building a report.

In many views, MetaFrazo shows the work of people apart from the work of apps and automation, so a change made by a rule is not counted as a person's.

www.metafrazo.cloud · Available on the Atlassian Marketplace

See you in the next edition of 5 Questions in the Atlassian Universe.

Interview conducted in writing, October 2026.