4 ms·

> I just don't see the email-specific barrier to entry. Syncing is hard in general, dealing with legacy systems is a pain, parsing poorly compliant file formats

by coffee 11y ago

> I just don't see the email-specific barrier to entry. Syncing is hard in general, dealing with legacy systems is a pain, parsing poorly compliant file formats is annoying... But you have that everywhere. Have you ever written a production grade email client?

jakobegger 11y ago
Of course not, otherwise I wouldn't have written "I'm pretty certain that I could develop a solid email app in a year".
- coffee 11y ago
  Of course you haven't. So you're claiming that you don't see the email-specific barrier to entry. Which is to say, you're arguing against it. While people who have authored such software are claiming the opposite. Yet you appear to have zero willingness to entertain the idea that those who have come before you have learned what you don't yet know? Very arrogant. There most definitely are email-specific barriers to entry. No reason to list them out again as @dmbaggett (among others) have already been kind enough to give up their time doing so (for the benefit of all to learn). Not buying what you're selling. So I'm sure you'll continue with your arguing and snap back with a terse reply. Carry on.
  - jakobegger 11y ago
    I'm sorry if I offended you. I felt that my argument was discredited by appeal to authority. I absolutely believe that the difficulties dmbaggett lists are real. I've experienced some of them myself on the few occasions that I've written code that integrates with IMAP and POP3. I don't assume that I could find a solution to all of them in a short time. But here's what I think: These difficulties are not "a barrier to entry". You don't need to solve all these problems to enter the market. You don't need to compete head on with the best competitors to enter a market. You don't need to make an email client that works for everyone. You just need to focus on specific audience, and solve a problem that no-one else does. If you do that, people will use your product even though it falls short in other regards. And you can leave the hard parts to the big companies.
    - coffee 11y ago
      Your points are valid, no need for them to be blindly discredited. You obviously have real world experience. The key here is your approaching the problem from a "here's what I think" standpoint and not a "based on the past 5 years of me doing this" standpoint. Again, it boils down to no having learned, what you don't yet know. More thoughts... I do have to say, though, that integrating email features into software (not an email client) these days can be trivial. For example, Rails makes a lot of it trivial. But that is a very poor litmus test. The difference between that and a full blown, production level, narrowly focused, tailored towards a specific audience, solving problems that no-one else does email client... are worlds apart. You have 2 choices today, third parties (Gmail API, JMAP, Nylas, etc...) or diving into a raw IMAP connections (as an example). The former provides general purpose layers, abstracting the complexity (to some degree). The disadvantage being they are general purpose, features everyone has. The latter provides the flexibility to create what has not yet been created. And/Or backfill what the general purpose solution lacks (typically a lot). In general, your approach to software, products and an MVP is spot on. Obviously you have experience doing this. The point that I, and others make, is that email does not fall cleanly into that same approach. Why? For all the reason already listed plus a TON more not listed. This is where you are unwilling to be open minded, and as mentioned previously, it's a classic mistake seen many times before.

by coffee 11y ago

jakobegger 11y ago

Of course not, otherwise I wouldn't have written "I'm pretty certain that I could develop a solid email app in a year".

coffee 11y ago
Of course you haven't. So you're claiming that you don't see the email-specific barrier to entry. Which is to say, you're arguing against it. While people who have authored such software are claiming the opposite. Yet you appear to have zero willingness to entertain the idea that those who have come before you have learned what you don't yet know? Very arrogant. There most definitely are email-specific barriers to entry. No reason to list them out again as @dmbaggett (among others) have already been kind enough to give up their time doing so (for the benefit of all to learn). Not buying what you're selling. So I'm sure you'll continue with your arguing and snap back with a terse reply. Carry on.
- jakobegger 11y ago
  I'm sorry if I offended you. I felt that my argument was discredited by appeal to authority. I absolutely believe that the difficulties dmbaggett lists are real. I've experienced some of them myself on the few occasions that I've written code that integrates with IMAP and POP3. I don't assume that I could find a solution to all of them in a short time. But here's what I think: These difficulties are not "a barrier to entry". You don't need to solve all these problems to enter the market. You don't need to compete head on with the best competitors to enter a market. You don't need to make an email client that works for everyone. You just need to focus on specific audience, and solve a problem that no-one else does. If you do that, people will use your product even though it falls short in other regards. And you can leave the hard parts to the big companies.
  - coffee 11y ago
    Your points are valid, no need for them to be blindly discredited. You obviously have real world experience. The key here is your approaching the problem from a "here's what I think" standpoint and not a "based on the past 5 years of me doing this" standpoint. Again, it boils down to no having learned, what you don't yet know. More thoughts... I do have to say, though, that integrating email features into software (not an email client) these days can be trivial. For example, Rails makes a lot of it trivial. But that is a very poor litmus test. The difference between that and a full blown, production level, narrowly focused, tailored towards a specific audience, solving problems that no-one else does email client... are worlds apart. You have 2 choices today, third parties (Gmail API, JMAP, Nylas, etc...) or diving into a raw IMAP connections (as an example). The former provides general purpose layers, abstracting the complexity (to some degree). The disadvantage being they are general purpose, features everyone has. The latter provides the flexibility to create what has not yet been created. And/Or backfill what the general purpose solution lacks (typically a lot). In general, your approach to software, products and an MVP is spot on. Obviously you have experience doing this. The point that I, and others make, is that email does not fall cleanly into that same approach. Why? For all the reason already listed plus a TON more not listed. This is where you are unwilling to be open minded, and as mentioned previously, it's a classic mistake seen many times before.