Sometimes it's the other way around. Lockers for packages were first introduced in Germany (Packstation) then they were rolled out in the US almost a decade later.
Not having a lot of credit cards and the associated rewards is actually healthy. Research has shown lower social classes "pay" for the rewards due to paying the higher transaction fees. There was actually a relevant thread here a few days ago
https://news.ycombinator.com/item?id=49432201 (How credit card rewards became a $9.2B wealth transfer)
Do you think Anthropic or OpenAI will eventually try to crack down on routing harnasses? Provide a more vertically integrated experience? They are already trying ro ship hardware products.
I will believe there is no moat when the revenues for Anthropic is not 70B. It seems like people want to throw away money and they don’t like switching
Indeed. I used to be on the upgrade program so I could upgrade every year, but decided to skip the 16 and keep my 15 until the 17 came out.
Even if you are upgrading every single year, it works out roughly the same to just buy every phone outright and then trade in last year's model -- you typically get ~half your purchase price back as trade-in value after a year anyway.
Hey that's not fair, there has been one actually useful "innovation" -- switching to USB-C like the rest of the world has been using for 10 years. Literally nothing has made me feel the slightest craving for a new iPhone since getting my 15 Pro Max.
If expending 6k per year on your database alone sounds reasonable to you, we have very different perspectives on a good use of investor funds.
We’re not talking about maintaining your own k8s cluster here mind you, but a basic Postgres setup. If you can’t handle that comfortably in an afternoon, you probably shouldn’t be entrusted with customer data.
> We’re not talking about maintaining your own k8s cluster here mind you, but a basic Postgres setup. If you can’t handle that comfortably in an afternoon, you probably shouldn’t be entrusted with customer data.
Intelligence is being able to set up your own postgres database with backups, PITR, retention policies, HA/replicas, and everything else needed to prevent catastrophic data loss. Wisdom is realizing that's a solved problem completely unrelated to your business, so you don't have to.
Well yeah, you can apply that to most problems you encounter as a company - there are service providers for pretty much anything you can imagine. That doesn't mean it's smart to spend a huge chunk of your revenue on OpEx, however.
Sure, and you need to do the build vs buy math, but why not take the "If you can’t handle that comfortably in an afternoon, you probably shouldn’t be entrusted with customer data." logic further and say
1. Don't use a third-party auth provider, if you can't build out an OAuth provider in an afternoon you shouldn't be entrusted with login credentials
2. Don't use Github, if you can't build out an internal Gitlab instance in an afternoon you shouldn't be entrusted with securing source code
3. Don't use Github Actions or CircleCI, if you can't self-host a Jenkins server in an afternoon you shouldn't be entrusted with secure deployments
4. Don't use a lawyer or outsourced HR, if you can't draft legally binding employment agreement in an afternoon you shouldn't be entrusted with hiring people
That's a straw man, obviously: I didn't talk about building your own database, but setting up PostgreSQL and pgBackRest, two well-defined, and thoroughly documented applications. With coding agents available, you don't need to much arcane domain knowledge for the fringe details, so a lot of the old reasons for appliances as a service don't hold anymore.
Other than that, yes! Setting up a Keycloak instance as opposed to handing over login credentials to Octa should be a consideration. Keeping your source code in GitLab over tying your entire development workflow to Microsoft vibe coders with an awful track record is a sensible stance.
> Don't use a lawyer or outsourced HR, if you can't draft legally binding employment agreement in an afternoon you shouldn't be entrusted with hiring people
That's a little ridiculous; there's an overlap between someone setting up a database for a startup and someone programmatically using a database at a startup. The overlap between that person and someone with a legal background is infinitesimally smaller.
I think we live in very different realities, 6k a year is nothing, its a weeks worth of pay for 1 SWE. A 6k a year savings opportunity is not on any funded startups radar.
And RDS is doing a lot more for you than what you can set up in an afternoon w.r.t observability and features that are just a click away. I actually implemented some of those features when I worked there :)
We just might—not everyone works in SV. The 6k are a single database out of a vastly bigger pool of expenses, so unless you’re funded with six to seven digits from the start, it’s not nothing. At least in Europe, shelling out 300 grand on an SWE for an early stage company is delusional.
> (For some reason, when I search the Internet for "streaming mapreduce," I don't get programs that do this real-time processing of lots of files as they get written. Instead, I seem to get batch-oriented mapreduce clones that happen to read from stdin, which is a stream.
reply