6 ms·

It impossible to overstate how wrong you are. Read some of my comments in this thread. One of the absolute worst mistakes you can make as a developer is to ass

It impossible to overstate how wrong you are. Read some of my comments in this thread. One of the absolute worst mistakes you can make as a developer is to assume that what you don't know or understand must be easy. That's the path to ultimate project doom -- don't do it.

jakobegger 11y ago
I never said that I thought it was easy; 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. What do you expect? That writing an email client should be as easy as cobbling together a map view with Google Maps? If that's your point of reference, then yes, there is a barrier to entry. In another reply you said that your MVP took 4 years; but looking at your website I see something that tries to compete with Outlook. That's hardly what I'd consider an MVP. I'm pretty certain that I could develop a solid email app in a year. Of course, it wouldn't do everything that existing mail clients do, and it wouldn't be compatible with every email provider, and it would probably be limited to a single platform. But it would do some things differently enough that it would be worthwhile for a few people. If you think there's an insurmountable barrier to entry, you need to take a step back. There is absolutely no need to compete with the best existing clients on a feature-by-feature basis to enter a market. Focus on a small niche, and go from there.
- 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.

jakobegger 11y ago

I never said that I thought it was easy; 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. What do you expect? That writing an email client should be as easy as cobbling together a map view with Google Maps? If that's your point of reference, then yes, there is a barrier to entry. In another reply you said that your MVP took 4 years; but looking at your website I see something that tries to compete with Outlook. That's hardly what I'd consider an MVP. I'm pretty certain that I could develop a solid email app in a year. Of course, it wouldn't do everything that existing mail clients do, and it wouldn't be compatible with every email provider, and it would probably be limited to a single platform. But it would do some things differently enough that it would be worthwhile for a few people. If you think there's an insurmountable barrier to entry, you need to take a step back. There is absolutely no need to compete with the best existing clients on a feature-by-feature basis to enter a market. Focus on a small niche, and go from there.

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.