5 ms·

> ” Between July and September, I worked on different things: the build system, Docker/docker-compose, continuous integration, authentication, internationalizat

by soneca 6y ago

> ” Between July and September, I worked on different things: the build system, Docker/docker-compose, continuous integration, authentication, internationalization, etc.” Authentication seems to be the only thing the author should be working on at all for a MVP. And even so, I would personally choose AWS Cognito or something like that. From reading this, it seems to me that the issue is a mix of harmful obsession code quality and bad priorization of what to work on. Probably some feature creep too, even with the author claiming they cut all to the basics.

javajosh 6y ago
Yes, its interesting from that list of things he did for 2 months one cannot discern what his project was!
- bombcar 6y ago
  Spending time reading horror stories on HN can lead to a form of paralysis. While it’s true bad decisions can be made at any level and anytime early on it is much more important to get something (anything) up and running - even if you scrap it later.
leesalminen 6y ago
Just finished a MVP idea I had and used Firebase for everything, including auth. Auth took a total of 15 minutes to work into my react SPA. Called it a day and moved on feeling very impressed with Firebase.
- nmfisher 6y ago
  I'll reiterate what I said the last time it came up on HN - this is exactly why I use Firebase, and why OP probably should have done the same. It's literally 15 minutes to configure/integrate, and you're done. You can then move on to building/iterating on actual features that matter to customers. Until you've proved you're building something that people want to buy, your data layer only needs to do the absolute bare minimum (store some data). It doesn't matter if it's not scaleable, performant, extensible, etc. 99.9% of the risk is that you fail because you're not building the right thing, not that you fail because Firebase wasn't appropriate. You have a limited number of hours in every day, and they are much better spent building features side-by-side with customers. You won't even know that Firebase is a bottleneck unless/until your platform is successful, and at that point you're in a good position to migrate/rewrite/whatever. A couple of commenters smugly pointed out that they were contracted to fix Firebase issues later down the track, and that's why they would stay away from Firebase in the first instance. First up, there's clear survivorship bias there - the fact is these businesses survived and were in a position to hire someone to upgrade their data layer. That's meaningful in and of itself. Second, don't pay too much attention to people who have never bootstrapped anything from the ground-up. What works in a mature, stable, well-funded organization is not what works in a solo, early-stage startup that's strapped for cash, time and equipment.
  - nicoburns 6y ago
    Setting up postgres on heroku is similarly quick and straightforward, also comes with a free plan for when you're just starting out, and won't leave you with the headaches you'll almost certainly have later with firebase. Firebase is slower to iterate on, because you have to bake your query patterns into the schema (yes your data still has a schema even if you don't have to define it up front) Using firebase for auth and/object storage makes sense. But I don't understand why anybody would choose to use the database(s) except for a few niches where realtime is critically important and query flexibility / data integrity aren't.
    - nmfisher 6y ago
      1) Firebase storage has the advantage of one-click integration with auth (Google Auth, Sign in with Apple, etc). Probably not difficult to achieve with Postgres on Heroku, but why waste a couple of hours on something when I don't need to? 2) My golden rule is to avoid anything that doesn't get you closer to a customer in the next 14-28 days. For some use cases, Postgres on Heroku might help you do that. For me (see next point), it's just adding another platform/service for no reason. That will only slow me down. 3) I disagree that "Firebase is slower to iterate because the schema is implicit" (at least, as a hard-and-fast rule). It depends on how complex the schema is. You iterate on implicit schemas by rewriting code, and you iterate on explicit schemas by rewriting code and the schema itself. This is faster for complex data models with strong integrity requirements, but for basic data models (think mobile game leaderboards, etc) it's just unnecessary. That's not to say that any of this is a huge amount of extra work. I'm sure a lot of people are reading this and thinking "Postgres will just take an afternoon to hook up, why not?". The reason is that spending that afternoon with a user is infinitely more valuable than spending it hooking up Postgres. You have to be ruthlessly focused on what moves you forward, which at an early stage is simple - features, customers, users. On any given day, there are literally hundreds of things you could do that "will just take an afternoon". If you allow them to distract you, you'll probably end up like OP - 2 years in with a well-architected system that doesn't have any customers.
      - nicoburns 6y ago

by soneca 6y ago

javajosh 6y ago

Yes, its interesting from that list of things he did for 2 months one cannot discern what his project was!

bombcar 6y ago
Spending time reading horror stories on HN can lead to a form of paralysis. While it’s true bad decisions can be made at any level and anytime early on it is much more important to get something (anything) up and running - even if you scrap it later.

leesalminen 6y ago

Just finished a MVP idea I had and used Firebase for everything, including auth. Auth took a total of 15 minutes to work into my react SPA. Called it a day and moved on feeling very impressed with Firebase.

nmfisher 6y ago
I'll reiterate what I said the last time it came up on HN - this is exactly why I use Firebase, and why OP probably should have done the same. It's literally 15 minutes to configure/integrate, and you're done. You can then move on to building/iterating on actual features that matter to customers. Until you've proved you're building something that people want to buy, your data layer only needs to do the absolute bare minimum (store some data). It doesn't matter if it's not scaleable, performant, extensible, etc. 99.9% of the risk is that you fail because you're not building the right thing, not that you fail because Firebase wasn't appropriate. You have a limited number of hours in every day, and they are much better spent building features side-by-side with customers. You won't even know that Firebase is a bottleneck unless/until your platform is successful, and at that point you're in a good position to migrate/rewrite/whatever. A couple of commenters smugly pointed out that they were contracted to fix Firebase issues later down the track, and that's why they would stay away from Firebase in the first instance. First up, there's clear survivorship bias there - the fact is these businesses survived and were in a position to hire someone to upgrade their data layer. That's meaningful in and of itself. Second, don't pay too much attention to people who have never bootstrapped anything from the ground-up. What works in a mature, stable, well-funded organization is not what works in a solo, early-stage startup that's strapped for cash, time and equipment.
- nicoburns 6y ago
  Setting up postgres on heroku is similarly quick and straightforward, also comes with a free plan for when you're just starting out, and won't leave you with the headaches you'll almost certainly have later with firebase. Firebase is slower to iterate on, because you have to bake your query patterns into the schema (yes your data still has a schema even if you don't have to define it up front) Using firebase for auth and/object storage makes sense. But I don't understand why anybody would choose to use the database(s) except for a few niches where realtime is critically important and query flexibility / data integrity aren't.
  - nmfisher 6y ago
    1) Firebase storage has the advantage of one-click integration with auth (Google Auth, Sign in with Apple, etc). Probably not difficult to achieve with Postgres on Heroku, but why waste a couple of hours on something when I don't need to? 2) My golden rule is to avoid anything that doesn't get you closer to a customer in the next 14-28 days. For some use cases, Postgres on Heroku might help you do that. For me (see next point), it's just adding another platform/service for no reason. That will only slow me down. 3) I disagree that "Firebase is slower to iterate because the schema is implicit" (at least, as a hard-and-fast rule). It depends on how complex the schema is. You iterate on implicit schemas by rewriting code, and you iterate on explicit schemas by rewriting code and the schema itself. This is faster for complex data models with strong integrity requirements, but for basic data models (think mobile game leaderboards, etc) it's just unnecessary. That's not to say that any of this is a huge amount of extra work. I'm sure a lot of people are reading this and thinking "Postgres will just take an afternoon to hook up, why not?". The reason is that spending that afternoon with a user is infinitely more valuable than spending it hooking up Postgres. You have to be ruthlessly focused on what moves you forward, which at an early stage is simple - features, customers, users. On any given day, there are literally hundreds of things you could do that "will just take an afternoon". If you allow them to distract you, you'll probably end up like OP - 2 years in with a well-architected system that doesn't have any customers.
    - nicoburns 6y ago