Hacker Newsnew | comments | show | ask | jobs | submit | login

Catch Notes had around the same number of users when we "decided to go in a different direction" last summer.

It was incredibly challenging for us to monetize the service and our user numbers where an order of magnitude off of where things would have been intesting for some investors.


Co-founder of Catch here, we are sometimes compared to Evernote but Catch is a note-sharing and collaboration app.

1. Two-factor

We don't offer two factor but is something we are investigating. This is mitigated somewhat by the fact that a lot of our users use Google login.

2. SSL / TLS

SSL shouldn't be a paid feature. It's been included in our product for free since we launched.

We try and use SSL everywhere. All page from catch.com are only available via SSL. e.g. login, landing page, marketing, blog, etc.

There are a few exceptions like our Knowledge Base which is powered by Assitly / Desk:


3. Encryption

We don't offer note level encryption. We'd love to get some feedback on a straightforward way to do key management.


We've been using HSTS for at least a year now. It was an easy decision for us since all content from catch.com is only available via SSL.

Security is hard and hopefully these breaches will raise the bar for everybody.


> Co-founder of Catch here, we are sometimes compared to Evernote but Catch is a note-sharing and collaboration app.

Would you say Catch has something to offer over Evernote for someone who uses the latter for private & personal notes?


Evaluated them both for quite a while: No desktop client, no note formatting, no embedded images. So no.


Thank you for the kind comment!

If anybody has any questions feel free to email me at a@catch.com


Co-founder of Catch here, some context; we launched our first Android app in 2008 and have about 10x as many users on there as we do on iOS.

The issue we've seen is that people build an iOS app and then port it over to Android.

We designed Catch 5.0 apps for Android and iPhone in parallel. This let us keep consistency between the platforms when it made sense, but also let us tweak the design early on so it could take advantage things unique to the platform, e.g. Action Bar on Android.

The team is incredibly proud of this release, and it is nice to see folks taking notice. Both Google and Apple have also featured this release, everybody is beaming here. =)


17 years! That is some serious dedication, kudos to the team.


We love MongoDB at Catch, it's been our primary backing store for all user data for over 20 months now.

  > Catch.com
  > Data Size: 50GB
  > Total Documents 27,000,000
  > Operations per second: 450 (Create, reads, updates, etc.)
  > Lock % average 0%
  > CPU load average 0%
Global Lock isn't ideal, but Mongo is so fast it hasn't been an issue for us. You need to keep on slow queries and design your schema and indexes correctly.

We don't want page faults on indexes, we design them to keep them in memory.

I don't get the safety issue, 20 months and we haven't lost any user data. shrug


> I don't get the safety issue, 20 months and we haven't lost any user data. shrug

Nobody loses any user data until they do.


This should be a deal breaker for any serious app. Does the performance hit of safe mode negate all other advantages of MongoDB?


That's most people's findings. If your dataset can fit in ram [1] and you don't care about your data being safe then there might be an argument for MongoDB. Once you care about your data, things like Voldemort, Riak, and Cassandra will eat Mongo's lunch on speed.

[1] But as Artur Bergman so eloquently points out, if your data can fit in ram, just use a native data-structure (http://youtu.be/oebqlzblfyo?t=13m35s)


Do you have a citation to back up the claim that you shouldn't use MongoDB for serious apps?

We have done billions of ops with Mongo and have never lost any data.


> Data Size: 50GB

I am sorry, to sound blunt, but that's an irrelevant data point. With a data set that fits comfortably into RAM (much less SSDs in RAID!), most any data store will work (including MySQL or Postgres).

> Operations per second: 450

Again, not a relevant data point. With a 10 ms seek time on a SATA disk, this is (again) well within the IOPS capacity of a single commodity machine (with RAID, a SAS drive, row cache, and operating system's elevator scheduling).


Agreed, this is a trivial amount of data.

Context is the article which made is seem like even 220GB is an ok amount, still can fit in memory.


450 ops/sec is nothing.

What's your breakdown between the operation types, and what kind of hardware are you on?


You'd think -- but the 10gen guys weren't surprised when we were struggling at this level (periodically), on a RS with two AWS large instances and relatively large objects. Absolute ops/sec in and of itself is relatively meaningless tbh.


Not a personal attack as Catch is a neat product, but these numbers are basically irrelevant.

This type of load can easily be handled by a simple SQL box. We did these types of #s with a single SQL Server box 4 years ago, except that your "total documents" was our daily write load.


Very cool! Good luck!


Go without a doubt.


Clicking on the '"click here" if you are not redirected' on paypal.com sends me to an empty confirmation page with SSL errors.



I had the same problem but I still got an email for the download link so it's no big deal.


Time vs Money

Not worrying about what to get the team for lunch is a huge time saver.

It gives us more time to spend on users.

Disclaimer, we use ZeroCater twice a week and absolutely love them.


For those that don't have Office Manager probably? :D



Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact