zlacker

Atlassian tools for a client like mine (hundreds of employees) can easily cover the expense of internalizing it. It's Jira plus confluence mostly, it's not rocket science.

And that's just atlassian.

Start adding stuff that costs many many many yearly salaries (special software for managing inventories and warehouses) it starts making sense to prototype alternatives internally.

I came to the conclusion that if it's not Teams/SharePoint or the moat is on the extreme legal complexity side (e.g. payrolls), you can at least think of building an alternative that is good enough without needing to be perfect.

>>epolan+(OP)
Don’t forget the salary for every dev team having the Atlassian Jira Jockey to mess around with the board all day and make sure the next 7 epics worth of tickets are in the 9 columns and in prioritised order.

Where would we be without them!?

>>epolan+(OP)
jira premium is $15/mo/user for 300 users. you're saying $50k can cover developing the app inclusive of integrations, maintaining it, providing 24/7 service and 3 9s uptime (per the sla)? don't forget compliance and security. maybe the logic is everyone can be fired and replaced with agents?

>>epolan+(OP)
I told to my colleague that it would take less time for me to vibe code jira that it would take him to configure it. Sounds crazy ? Not so much : factor the part of jira you use (maybe 10%), the many choices and dimensions you have to configure, the time it take and the complexity it bring. On the other side, the vibe code version have only the fields you want, most of the logic hard written in code (ie epic > story >task...), and that you could do anything any role, any authentication scheme.

>>louier+V2
Yes. $50k goes a long way outside of the Bay Area.

>>julien+g5
This reminds me of all the "i could turn the spreadsheet into a webapp in a weekend" type comments. Sure, you could get CRUD and a datatable working but then a user is going to ask you for a custom field and you'll say "ok let me vibe code that, update the database, and then deploy" but the user will say "well in Jira I could just to that myself...". Then the next thing they're going to ask is some kind of custom workflow utility which you'll then goto work vibe coding that feature and they'll say again "...but in jira that was already there". Meanwhile they'll ask you why they can't change the validation criteria on the custom field from before, they said it should be required but now there's a case where it's optional.

Pretty soon you're just re-implementing Jira while your users wait and get pissed because they could have just been using Jira all along. It's just like turning a spreadsheet into a webapp, inevitably you just end up trying to re-implement Excel.

>>fragme+pa
There is no way you would get anything close to as good as JIRA. Your best bet with that budget would be trying to integrate an existing open source on-prem solution (not sure what that alternative is for JIRA).

>>epolan+(OP)
Ugh you are aware that Atlassian earlier was providing on-perm edition for years.

You also know how neglected those on-perm instances were?

No one updated those, no one wanted to pay for more CPU/RAM. File storage, I know people who had some random requests to cleanup files from projects because company wouldn’t buy more hard drives. Everyone was nagging at sys admins that they do bad job and at Atlassian that JIRA sucks.

That is mostly why Atlassian pulled off on premise because companies would not update at all, would like to have all new features and also not pay for file storage,RAM, CPU to make it work well.

Don’t forget you still will need to have dedicated employees to deal with AI built solution - because existing employees have work to do.

What we pay for JIRA and Confluence would never offset fact that we pay and it works, NOT A SINGLE EMPLOYEE CARES as they have their job to do.

>>chasd0+ud
> but the user will say "well in Jira I could just to that myself..."

> "...but in jira that was already there"

Must be a different Jira from the one I'm used to, where obvious features are never there and even if you can find the button it doesn't work.

>>louier+V2
Atlassian had on premise option already.

All instances I remember seeing were neglected, not updated running on lowest amount of resources. Everyone in company nagging how slo it is but no one wanted to share budget to improve it.

So for me that experiment „it will be better and cheaper building our own JIRA” was already done. It is going to be cost center that no one will want to throw money at.

>>camden+Xu
> There is no way you would get anything close to as good as JIRA.

It would be hard to do worse. A packet of crayons and a scrap of paper is better than JIRA.

>>lmm+Cz
How many Post-it Notes will $50K buy?

>>camden+Xu
Jira is crap, so the bar is low.

>>camden+Xu
Oh please.

Yes, you wouldn't get something near as complicatedas JIRA, but that would be a good thing! Look, it's enterprise software, so I'm sure there's somewhere that needs to have the overcomplicated permissions system otherwise contractors are going to steal everything that isn't bolted down, but most places I've been don't need, and thus don't use most of all of that crap. If the ticket can only go from planned to done by a certain group of users, backed by LDAP... let's just say, I'm not going to miss configuring which group gets which permissions system.

JIRA's the perfect example of disruption, too. Everyone's got their bespoke workflow, and JIRA has to be customizable to suit all of them. Bespoke software just doesn't have to the same way.