How is that any different to 99% of startups who preach they are "changing the world", but at the base of it, are just a crud app. Only difference is they are using a "hip" language which will probably make your life more difficult than .net
How is that any different to 99% of startups who preach they are "changing the world", but at the base of it, are just a crud app. Only difference is they are using a "hip" language which will probably make your life more difficult than .net
One place I worked, every solution we did had to shove at least 2 of these ingredients into the finished product: 1) .NET, 2) SalesForce, 3) SAP, 4) BizTalk ... frequently it had nothing to do with the merits/needs of what we were tasked to build.
It was simply an equation of having an IT department with these teams, and the department head for each were competing for budget and would inject themselves into the solution or their department would shrink and disappear.
Once "which language will we write this in?" becomes equated to "which team gets this work?" then your company is headed down the bad path. Because now technology choices will be driven by management politics instead of technical aptness.
We are just working on an integration/implementation with one of our systems, and it's quite a drag uninteresting. I don't quite understand the hype behind it, and since our motto (and other people I've spoken to) is "We're just going to move it into Salesforce!" my resentment towards it grows.
It is also unbelievably customizable, with one click plugins that even your grandma can add, and practically anything you can wish for already built for you. It's also extremely familiar to practically every salesperson or management out there.
Basically Salesforce is to CRM what Wordpress is to CMS - the easiest one for non-technical people to use.
The trouble is that the other 25% of the functionally that doesn't fit into the Salesforce mold is hard to come by. Partly due to platform limitions. Mostly because developing on Salesforce is littered with pitfalls and requires intimate knowledge of how the platform works. Most "developers" out there are business analysts/admin who after writing a simple trigger were transitioned into a developer role. I very rarely run into other people with CS background.
Ha ha I actually had to work with it 6 months ago at a late stage startup.. What they needed was a simple apex trigger.. it took 30 min to write on a demo account.
.. but it took us a week to find out we couldn't do it because of the version of SF that we had, and an upgrade would 6x the cost of their monthly licensing cost.
It was a really bizarre dev experience. Really crappy errors!
Business and Sales people love salesforce. It promises instant business gratification via enforcement of best practices through a single unified platform. It also promises to cut down the need for in-house software development, since everything is promised to work out of the box with some point and click configuration tools which the SF admins can easily work on (their slogan is or used to be "no software"). However, as soon as the company realizes that the standard SFDC solutions don't quite meet their business model, that's when the need for custom SF development comes up which is very restrained by APEX/SOQL capabilities and is not cheap. This is often the point where many businesses back track to custom solutions and then build messy integrations that forces the two systems to pass data to each other...
I know what you mean there...lots of DB work and json payloads has been what we are working with. Most of our work is completely custom, so it's been ~interesting~...
It demos well, and you can do some basic things with it. But then you always end up hiring someone to do custom development. So the whole appeal of a point and click platform goes away.
.. This was 6 years ago and I didn't work with it enough to really have an educated opinion. The department that used it thought it was revolutionary technology but honestly most of their devs were rejects/burn outs from the 'more real' engineering teams, to put it mildly.
What we saw in our team (.NET) was that data became siloed and was awkward to use. It was also really challenging to build responsive applications when you had to interact with clunky web services. User experience was absolutely awful the times when we couldn't just send it async.
... that said, if I had the opportunity to architect something like that, I would have rather opted to keep the data elsewhere and just push it to SalesForce when it changes.