And in many cases, it's 12 features, with 2 of the features not even existing in the big SaaS.
replyI'm pretty sure every developer who has dealt with janky workflows in products like Jira has planned out their own version that fits like a glove, "if only I had more time".
If companies wanted to build thier own simple-JIRA they could have built themselves before. I dont think making a kanban board was hard even before AI.
replyYou’re describing Excel.
replyAI will be used to do “excel better” more than “replace a managed, compliant, feature-rich-carefully-engineered, service”.
JIRA especially, and I'm always shaking my fist at Atlassian that simple APIs or workflows or reports aren't already included in the tool. I have to pay some other company $10/user/month to get this dumb report your tool should already be able to do?? Insane.
replyUntil a given company decides they need access control for their contractors that's different from their employees, etc. etc. etc. - seen it all before with internal often data scientist written applications that they then try to scale out and run into the security nightmare and lack of support internally for developing and taking forward. Usually these things fizzle out when someone leaves and it stops working.
replyBingo; the exact same arguments against regular-coding it in-house apply to vibe-coding it in-house.
replyPretty much. My employer was looking to cut costs and they were spending ~500k a year on a product that does little more than map entra roles/groups to datasets and integrated with a federated query engine through a plugin. Took a couple days to build a replacement. The product had only a few features we needed.
replyAs niche SaaS provider, I'm trying to avoid succumbing to the same fate. The product I built carefully for years would now be within the reach of a senior dev with a couple focused weeks -- if they knew all the requirements. To avoid being overtaken, I'm working to increase my customer's requirements -- getting them hooked on new reports and features I never had time to build before LLMs could do it for me. This makes it less likely for a competitor to be able to afford to quickly replace me.
replyAt the same time, I have no idea what the cost of LLMs usage will be in the future. So I'm working to ensure the architecture stays clean and maintainable for humans in case this kind of tooling becomes untenable.
That sounds like a good strategy to me. We have a couple other products we're looking to knock out to reduce costs, and the decision comes down to me and another colleague. The thing these businesses have in common - difficult to partner with, rough edges for the use cases we need, and no appetite on their end to shore them up. We're paying premium prices for a subpar experience. If instead they adopted your thinking, perhaps we would've looked for savings elsewhere.
replyI've found in the embedded space that people sell lots and lots of products that do everything you could ever want, and the most efficient thing to do is not buy those things and instead find a way to do just the subset of things you care about with your own back-end systems. The upshot of that is that because you're in total control if something goes wrong you can fix it without getting 6 people on a phone call to point fingers at each other.
replythere's no shortage of software engineers, if it was so easy for an organization to replace a saas with something built in-house they'd be doing it all the time. In my experience in enterprise consulting implementing a well defined requirement is the easiest part. Getting everyone to agree on the requirement, getting it defined, and stopping it from changing after every demo is the hard part.
replyExactly, a lot more focus -- and most importantly specific domain knowledge -- allows the end-user to build exactly what they need, fast.
reply