3 ms·

Trying to be constructive, but why would it even be a subscription model? Although it looks nice, I would think twice even spending 10$ once for it (mostly due

by CSDude 6y ago

Trying to be constructive, but why would it even be a subscription model? Although it looks nice, I would think twice even spending 10$ once for it (mostly due to our currency's value). Also, since it's an Electron based widget, is the memory overhead considerable for just a calendar widget? Also, how does this YC Launch work? Does not seem related at all with your original idea (not sure if it's a deal-breaker though?)

jordandearsley 6y ago
Thanks for the feedback. We'd like to fall into the category of other consumer SaaS products like Superhuman and Vimcal. > since it's an Electron based widget, is the memory overhead considerable for just a calendar widget? Great question. In my menu bar right now, the app's using ~150MB. > Also, how does this YC Launch work? Every startup in YC gets one YC Launch where they're featured on the front page for the day. Doesn't matter what idea was applied to YC with, just what the startup's currently working on.
- danpalmer 6y ago
  150MB might not seem like much, but it really is a lot. iStat Menus, which is tracking a lot more data across my system to render its multiple graphs is using ~85MB total. Bearing in mind that many users are going to have 5 things like this in their menubar, they can't all use this amount.
  - jordandearsley 6y ago
    That's a good point. There's definitely ways to optimize for less memory usage. We've been prioritizing feature development, but plan to focus on this before we start scaling.
    - trinix912 6y ago
      This should be a very high priority issue. The more features you'll add, the harder it'll be to perform any heavy optimizations without rewriting major parts. ~150MB is a huge memory footprint for something that just sits in my menubar idle. Not all Macs have >16GBs of RAM (and even if they did, this is pretty wasteful). I'm also concerned about the battery life. I'm pretty sure you'll eventually reach a point where it's no longer possible to optimize it any more (nonetheless Electron is just a Chrome instance). If you suddenly realize the whole thing would be twice as good if you'd just make a native app instead, it's better to have no features than have to rewrite all of them. I know this doesn't sound constructive, but why go with Electron in first place? It's a menubar widget which the users are expected to be running all the time. There's a difference between running a simple applet and a whole browser instance.
      - hazz99 6y ago
        I don’t think it should be very high priority for them. They’re a startup, they need to focus on the fastest and most effective way to create value for their users, today. No point optimising the product if the company dies before it starts slowing down.
        danpalmer 6y ago
        If they aren't a "good platform citizen" at the beginning, it's unlikely they will be later on. This might be something they're willing to accept as it's unlikely to affect them directly, but in aggregate, every growth-focused startup building is JS today because it's quick, will result in high powered machines being saturated with slow software. I suspect the effect will be that Apple gets hate for not making fast enough computers with enough battery life, and people reluctantly spend another $1500 on a laptop after 2 years because it's too slow. My advice to the company would be that their target device is almost certainly the base model MacBook Air with 8GB RAM running Slack, a large Excel spreadsheet, and Chrome with 100 tabs of Gmail and documents, and that if they aren't _lightning_ fast on that now they need to optimise soon, because they'll get slower over time.
  - Grustaf 6y ago
    Oh it does seem a lot.
- growt 6y ago
  On my macbook air M1 it is using close to 600MB. https://i.imgur.com/xRyQQOE.png https://i.imgur.com/xRyQQOE.png Might be somehow inflated by something I don't understand about apple silicon reporting memory usage. But it's concerning none the less. And I forgot to include the main process at 114 MB
- wespiser_2018 6y ago
  No offensive, but using a subscription model because of how your company wants to be categorized is an awful justification to make a product decision at such an early stage. Instead of "we want to be company X, so we build Y", it should be, "the problem is Z, so we build Y to solve it".

by CSDude 6y ago

jordandearsley 6y ago

Thanks for the feedback. We'd like to fall into the category of other consumer SaaS products like Superhuman and Vimcal. > since it's an Electron based widget, is the memory overhead considerable for just a calendar widget? Great question. In my menu bar right now, the app's using ~150MB. > Also, how does this YC Launch work? Every startup in YC gets one YC Launch where they're featured on the front page for the day. Doesn't matter what idea was applied to YC with, just what the startup's currently working on.

danpalmer 6y ago
150MB might not seem like much, but it really is a lot. iStat Menus, which is tracking a lot more data across my system to render its multiple graphs is using ~85MB total. Bearing in mind that many users are going to have 5 things like this in their menubar, they can't all use this amount.
- jordandearsley 6y ago
  That's a good point. There's definitely ways to optimize for less memory usage. We've been prioritizing feature development, but plan to focus on this before we start scaling.
  - trinix912 6y ago
    This should be a very high priority issue. The more features you'll add, the harder it'll be to perform any heavy optimizations without rewriting major parts. ~150MB is a huge memory footprint for something that just sits in my menubar idle. Not all Macs have >16GBs of RAM (and even if they did, this is pretty wasteful). I'm also concerned about the battery life. I'm pretty sure you'll eventually reach a point where it's no longer possible to optimize it any more (nonetheless Electron is just a Chrome instance). If you suddenly realize the whole thing would be twice as good if you'd just make a native app instead, it's better to have no features than have to rewrite all of them. I know this doesn't sound constructive, but why go with Electron in first place? It's a menubar widget which the users are expected to be running all the time. There's a difference between running a simple applet and a whole browser instance.
    - hazz99 6y ago
      I don’t think it should be very high priority for them. They’re a startup, they need to focus on the fastest and most effective way to create value for their users, today. No point optimising the product if the company dies before it starts slowing down.
      - danpalmer 6y ago
        If they aren't a "good platform citizen" at the beginning, it's unlikely they will be later on. This might be something they're willing to accept as it's unlikely to affect them directly, but in aggregate, every growth-focused startup building is JS today because it's quick, will result in high powered machines being saturated with slow software. I suspect the effect will be that Apple gets hate for not making fast enough computers with enough battery life, and people reluctantly spend another $1500 on a laptop after 2 years because it's too slow. My advice to the company would be that their target device is almost certainly the base model MacBook Air with 8GB RAM running Slack, a large Excel spreadsheet, and Chrome with 100 tabs of Gmail and documents, and that if they aren't _lightning_ fast on that now they need to optimise soon, because they'll get slower over time.
- Grustaf 6y ago
  Oh it does seem a lot.
growt 6y ago
On my macbook air M1 it is using close to 600MB. https://i.imgur.com/xRyQQOE.png https://i.imgur.com/xRyQQOE.png Might be somehow inflated by something I don't understand about apple silicon reporting memory usage. But it's concerning none the less. And I forgot to include the main process at 114 MB
wespiser_2018 6y ago
No offensive, but using a subscription model because of how your company wants to be categorized is an awful justification to make a product decision at such an early stage. Instead of "we want to be company X, so we build Y", it should be, "the problem is Z, so we build Y to solve it".