Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

After building a business with Zoho functions, blueprints and if-this-than-that flow -

I can tell you conventional wisdom missing in Zoho like version-control and testing is very much needed.



I use Zoho and while it sucks, pretty much every other alternative sucks to the same degree (or more) than Zoho. (That is if you are looking for the full range of functionalities that Zoho offers).

It seems to be an industry-wise thing and I wonder if it's time for disruption.


But disruption in this space is not easy; these are massive and complex products; they look pretty trivial from the outside until you use them; there are 1000s of small features you need to have and support in all the workflows and api tools. I had to integrate the Freshworks/sales api a few weeks ago for instance, and that looks like a trivial thing to copy, until you start really looking into all it does under the hood.

It is ready for disruption but to do so, I think it would need a holistic base that is consistent with respect to and between programming language/implementation, infrastructure, api and gui tooling. Now these are mostly manually adapted between each other when stuff gets added and the end result is a lot of leaky abstractions, instability, issues scaling, bugs and inflated infra costs.


Feels like the disruption could be identifying a subset of the 1000s of features used that a cover a large enough part of the market and solely focusing on that.

Instead of 1000s of features, have 40 good features. Limits how many customers you can get, but should lower development costs as well. There's probably a sweet spot that works.


> identifying a subset of the 1000s of features used that a cover a large enough part of the market

Deceptively hard. The only way to make this happen is using telemetry, and users don't like that, understandably. My belief is that Excel and Word are so successful because EVERYONE uses a different subset of those thousands of features. A one-lawyer office will differ from a dozen-person firm, a big general contractor will use different features from a small one, etc.

You can't survey users about those features either. Users don't know what your surveys mean half the time. They will answer according to how they think you want them to answer instead of what they really do. Or they will be satisfied but name features they would never use because they heard about them at a conference once. They use different terminology from you, so signal gets lost either way. Ad nauseam.


Well, rather than telemetry, I suppose excellent domain knowledge may help? Experience in a particular field might help you choose a particular workflow that could work for a lot of users.


I worked at Microsoft for years and no one ever cracked that nut.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: