trevz

Anyone else see the irony in the title of this article? ;)

Totally agree.

One useful difference is that you can set exceptions (i.e. email addresses that you want to receive emails from immediately).

Some of the advantages vs using your Mail app to do this are:

1. it works across all your devices (as works at the gmail server level)

2. you can set exceptions (e.g. email from mygirlfriend@gmail.com should always arrive immediately)

Took us 10 days to build, and costs us nothing to run. No intention to monetize (we run a BI platform called trevor.io which pays our salaries. Feel free to check it out if you want to support us :) ).

Adios needs the ability to change the label on emails (in order to move them into the inbox at your chosen times). This permission is unfortunately also the permission needed to access emails. If you know anyone at Google who can change this, please let us know ;) as we're keen to ask for as little permission as possible.

Importantly though, the content of emails never ever hits our system. The API calls we use only retrieve msg ids and uses those to change the labels. These are never stored.

Exactly right. Adios just requests API access.

The way it works:

1. creates a filter that filters your incoming emails into a hidden gmail label

2. at your chosen times we use the gmail api to move the emails back in to the inbox.

Adios never ever accesses the content of your emails, for any reason.

We originally built this using a Google App Script in Gmail. Has been game-changing for productivity. Now launching it as a service so anyone can try it out.

Any and all feedback welcome. Happy to take any questions.

Would be cool if you didn't have to use your mouse so much. Kept having to click the next box to select it.

A couple of thoughts, off the top of my head:

Programming languages:

  - python (for general purpose programming)
  - R (for statistics)
  - bash (for cleaning up files)
  - SQL (for querying databases)

  - Pandas (for Python)
  - RStudio (for R)
  - Postgres (for SQL)
  - Excel (the format your customers will want ;-) )

  - SciPy (ecosystem for scientific computing)
  - NLTK (for natural language)
  - D3.js (for rendering results online)

Hi dang. This is incredible feedback. Thank you so much!

Great point about us "burying the lead" and needing to hook the user in the first 2 seconds.

After our current sprint I'll take a couple of days to see if I can rework it a little. Really appreciate your guidance on this. Will ping you an email when I have something.

Hi dang. Truly appreciate your feedback on this.

We have certainly been overwhelmed by the supportive comments of friends in this case, but it was only our intention to start the conversation - not to collude on votes (I don't have enough friends for that :-) ).

We spent a lot of time on this article, and were particularly excited to get feedback on it from the HN community. Sorry if it has come across as anything different.

Have to admit - we were a bit nervous about telling the world we used jQuery for this. ;) But it still has its place IMHO.

Thanks! Yeah, we played with the idea of making a demo version of the app, for a long time. But it would have been a mega-project.

We use Stripe, and it's been great. But now we need to start providing invoices and charging different tax rates for different countries ... and suddenly the low-level processing of Stripe just isn't enough.