Hacker News new | past | comments | ask | show | jobs | submit | lleims's comments login

There's two updates to the original post:

- All my communications with the Budapest Service Center: https://www.myteslaexperience.com/2025-02-04/all-my-communic...

- How to spit in a customer's face: https://www.myteslaexperience.com/2025-02-07/how-to-spit-in-...


For you and anyone else who might find this relevant. It may seem obvious in retrospect, but with pointing out that "taking delivery" is a significant moment in the purchasing experience. If there is a problem with the car, don't drive it off the lot. Once you have, it's your problem and not the dealer's.


It's funny to me to buy a domain name just for that.


It's effective. I consulted once for a food delivery chain that has wronged a customer - a food order that was delivered wrong and they foolishly refused to either right it or refund it.

The customer went to the length of buying the domain of the type _company_ is terrible, started to collect reviews from other allegedly wronged customers, and SEO it to the first position in Google search results when you searched for any of the food items or the company name, above the company itself.

As a result the company had to advertise a lot on Google to make sure it's own order links are sponsored above the complaint website. That costed A LOT of money, but if they stopped advertising, the online order business would die.

We offered to buy the website or pay the owner to take it down, at basically name your price, and the owner refused any deal, out of principle.

It's amazing what an unreasonably determined individual can do


Seems reasonable to me!


they bought 2 domains in fact: https://laexperienciatesla.com/


$12 is a small price to pay compared to the opportunity cost of having a bricked car in one's garage for months on end, multiplied by however many individuals they may have saved from the same pain.


Imagine how much your customers have to hate you to do this.


The .sucks TLD is supposed to be for the express purpose. In reality, it's a way to extract anywhere from $250/year onwards from companies to not have tesla.sucks in the wild.





They're still going to get 7% for $125k. The $375k extra will convert on the same terms of the next financing.


I don't understand at all. I know nothing about startups - so is it an additional 7% that YC owns for every additional 125k, so 28% for 500k? Disclosure - I did not watch the SAFE video.


Roughly: The additional converts at the best deal another investor gets at/before the next priced round.

If the next priced round is at $7.5M, their $375K converts at that price (so it buys them another 5%). If your next round is not above $1.8M, it’s already an unfavorable sign.

The only downside I see is it doesn’t let you raise another small amount without valuing YC’s follow-on $375K. You might want to do such a raise for strategic rather than financial reasons and this would be an overhang against that. (I don’t think it’s that big a deal in practice and the additional committed money is probably better by way more than this detriment.)


I think you can just do more MFN SAFEs for small follow-on, if an investor is willing (maybe not though if there is no discount)


In practice for small round you will be raising SAFEs instead anyway, so it might be fine for early companies.


Nope. It's $125k for 7%; then the 375k are on terms of next equity round.

So the first tranche values your company at 1.78 million; if, afterwards, you raise more money at 6 million valuation, YC gets another 6.25% for 375k.

Correct me if I'm wrong.


Good read!

Eesel looks great :)


Hey HN!

This is Jaime, one of the cofounders of Arengu (https://www.arengu.com/).

When you start building an application, there are always a ton of non-core features to be built: sign-up flows, login flows, subscription flows, update profile flows, automating tasks after the sign-up, etc. And then, when you start scaling your application, new requirements come up.

Arengu is what we like to call the brain behind those user flows. We allow developers to build and orchestrate all those boilerplate blocks with pre-built UX components that work with any stack, custom logic and integrations following the best UX and security practices and if you need it, you can always extend our capabilities adding some custom coding.

We don’t handle identity nor user management, instead we offer the tools to visually build the components, its validations, logic and the two-way connection with your own API or extending your identity provider capabilities (eg. Okta, Auth0, Firebase, etc).

Use case are endless: a sign-up with a Stripe subscription, sign-up with OTP email verification flows, blocking fraud or spam sign-ups based on IP scoring, custom MFA flows, custom login flows (eg. ask users new data on the next login), etc. We want to wrap up most common use cases on 1-click templates and allow you to adapt them to your needs and connect them to your current stack.

User onboarding and authentication tends to be a complex process with many integrations associated, and with Arengu we believe we can help with that.

If in the past you’ve had to deal with these situations, I invite you to try Arengu. We’d love to get some feedback and if you have any questions, happy to try to reply :)


RIP Mamba. It was a great pleasure being able to grow up watching you. So many fond memories.


Ben Thompson of Stratechery precisely wrote about this last week:

>Given this week’s theme, though, I wanted to focus on AWS: revenue was up 46%, and while that may be lower than Azure in percentage terms, it is almost certainly higher in absolute terms. AWS had $6.7 billion in revenue last quarter, while Microsoft’s entire Server Products and Cloud Services — the majority of which remains on-premises — was $5.7 billion. Microsoft of course has other cloud revenue, including Office 365 and Dynamics 365; those are SaaS products though and generally don’t compete with AWS.

https://stratechery.com/2018/ibm-red-hat-follow-up-microsoft...


wonder how much of those were attributed to Serverless revenues....probably negligible.

2018 is almost over and I still don't know if I should go fully serverless, more importantly, which cloud vendor has fixed the "cold startup time" for serverless functions. Google seems quite promising but still no recent study has been done on this. Would somebody like to see a test on this done? I've been wanting a straight up answer for a long time but hard to find a consensus, seems to be all over the place.


Someone measured serverless cold startup time a couple of months ago:

https://news.ycombinator.com/item?id=17949694


> which cloud vendor has fixed the "cold startup time" for serverless functions.

I'm interested in this problem area, so I would be interested in your definition of fixed.


no warm up period despite sporadic use.


It will depend a lot on "sporadic". The dominant factor is where your workload sits in the warmth hierarchy. RAM and disk space are limited, so less-frequent workloads will eventually be evicted from worker nodes.


It seems to me that any vendor could solve this for the price of around 24 requests a day...


Decathlon in Spain has a very similar system. The first time I saw it I had the same reaction. Pretty exciting to experience it.


Down here (Spain).


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: