That’s not a great business to run though as it’s very difficult to scale.
Far too many fall into the trap of saying yes to the first BigCo that comes by early on because they need the $$. While they neglect every other niche and business where it could fit like a glove.
Or more often doesn’t even bother legitimately testing it on the open market since their very limited programming time is spent serving BigCo and doing support.
A lot of companies using SaaS have a bunch of different systems interconnected with Zapier or their own systems. Which IMO is far more like Unix than x product that turns into a full blown CRM, CMS, ERP etc tacked on top a niche product.
Building highly customized software also generates tons of risk for smaller companies as it binds their entire revenue on the success of a small group of other companies who may die, switch core business, or get stolen away by a bigger enterprise software sales team.
I’d much rather build a niche software product and instead of building a CRM on top just add every sort of API, webhook, Zapier, or direct integration. Or isolate them into separate products with shared authentication and logging systems.
That's true, but sort of necessarily so, though. How else do you build a product that meets such a broad set of needs? Someone's got to do the work. At some point, features are going to drop linearly.
I agree in theory, but I thoroughly disagree in practice.
If a client could spec/develop good software and cost it realistically, then sure. But I have rarely had clients like that - instead they think the problem-space is simple and end up with a half-baked solution that can't be maintained.
Developing greenfield software is a high risk strategy. (Edit: with a high reward if core function, and not much reward if not core).
This happens because management is doing cover-your-ass methodology of software procurement. If they backed a greenfield development and it failed, then get blamed. But if they choose SAP/salesforce/bigCo, the same failure can be blamed on the vendor, or if it ran over budget, they can claim the vendor is expensive.
'Custom' is scary in a way that 'customizable' isn't.
The other issue is that a "great business" and "scale" are not synonymous. In fact many of the current batch of companies of great scale, like Slack, have spent enormous amounts of money to get there, and still lose money after becoming public. Then you have a company like Atlassian, with a confounding mix of enterprise products that are hard to use: but a fantastic businesses that's been profitable since the very beginning.
I do agree with you that the APIs, webhooks, and Zapier integrations solve the problem of customization, although I'd still say it's less customization and more a bevy of options.
They are often using the same source tree and instance, but are enabling feature flags for certain customers. This often extends beyond code to data and caching. These don't get maintained and are a pain for support, as well as developers/operations. Over time they are almost as bad as a separate source tree.
And scaling beyond 2-3 real customers does make a very big difference for any legitimately good company.
This is kind of a symptom of “the buyer isn’t the user”, though. Often we build these features, then monitor usage, and the customer that demanded it doesn’t even use it! Or we build it, and it doesn’t matter, we still don’t close the sale.
I think the core issue is “building for users” and “building to close specific sales” are often strongly at odds with one another, and most of the time “building to close specific sales” wins.
This was arguably Steve Jobs key role at Apple.
Lets say you are starting sn enterprise saas company, woohoo! You have your initial product and customers love it, yes! Things are starting to hum along nicely.
Now your sales people are identiying new markets and saying “hey if we add feature x and y, we can make $x million more per year from x y and z clients”.
At this critical juncture, managwment most likely approves and has UX involved, but adding the features will be the priority regardless. Theres no overrulin g UX voice that can say “no, dont build that feature because theres no way to maintain the delightful user experience” because MONEY IS ON THE TABLE! Execs got revenue goals to hit, sales people have revenue goals to hit, and this seems like a match made in heaven. Additionally, its important to point out that pioneering companies dont know all the end state user flows at the beginning so they are hacking along, reacting as they learn more about end customers.
Now fast forward a decade. The software is bloated but has grown a lot. Users hate it. New startups look at your product, your end customers, and say “hey! We can do this more simply and steal their customers”. And they can, because they have the advantage of starting from the ground up, KNOWING THE CUSTOMERS and their workflows. So of course they can build a more efficient product because they have the clear end vision - your product, but with the bloat cut out.
Your team has already done the hard work of identifying the best and largest customer use cases.
So what’s the solution? Acquire these upstarts or make your company a platform. I dont what blackboard has done here but salesforce is still by far the largest game in town despite universal hate. Why? In large part due to the vast network of 3rd party developers who can configure salesforce to a customer’s complicated workflows. They’ve actually taken this problem (it’s complicated to use) and turned it into a retention feature. No wonder they have a giant skyscraper in san francisco.