Hacker News Reader

Comment by zefhous | Hacker News Reader

Oof this bit is rough!

> The startup supports Postgres, the most popular developer database system that’s an alternative to Google’s Firebase. Supabase’s goal: To be a one-stop backend for developers and "vibe coders."

View on HN

Enabling more people to make cool things themselves isn't necessarily a bad thing.

It's all fun and games until you realize the cool thing you made is locked into an overpriced cloud stack that will bleed you dry. "Vibe coders" seem to invariably end up offloading as much heavy lifting as possible to ultra-expensive PaaS/SaaS vendors, and those vendors are encouraging it (e.g. Vercel v0).

Okay? Let's say it's $200/mo or something for a moderately popular app. An engineer starts at $200/hr, so you're still saving a ton.

With Vercel/Netlify, you're paying for ease of use. For a lot of people, that tradeoff is worth it. Not everything can be free.

>An engineer starts at $200/hr

Starts?!

I’m assuming that’s the fully burdened rate, i.e., salary, benefits, taxes, overhead, profit, etc that employees never see, even though they should.

I remember getting a sheet from an employer early in my career that fully broke down the cost of benefits and taxes and showed me the full cost of just my employment, not including overhead, profit, etc. it was rather eye opening because although I kid of knew it from accounting and finance, it never really impacted me quite as much before seeing the numbers.

If the system didn't structure it that way, everyone would know the numbers and protest. As it is people pay up for the most part, they even defend the concept of taxing, supposedly going to public services.

Starts? With 40h/week, that's basically a $400k annual salary. This is certainly not the start price of an engineer.

If you hire someone full time, you can do the math that way.

But the market rate for a freelance midlevel US-based engineer would be about double per hour what you'd pay a full-time employee of the same level, to account for taxes/PTO/health care/etc.

Would be happy to find something at half that, but there’s no work right now. Lots of ghost jobs and even upwork has twenty+ applicants fighting over $30/hr scraps.

Is that 200 a made up number?

https://money.usnews.com/careers/best-jobs/computer-programm...

Do you have a better source for your number.

As far as cost, 200/month is nothing, but those are not the numbers we hear about when things spiral out of controll due to a ddos or sudden surge in popularity.

We serve thousands of customers off Supabase for $250/month including PITR. It’s a STEAL. Technical support is also responsive and knowledgeable. Outside of the auth SSR upgrade, it’s technically also been great to work with. Supabase is some of the best value we get from any vendor.

It's the right trade-off, IMO. Most projects won't succeed and the ones that do can be refactored - by real engineers if needed.

Agreed. And you can take a lot of the supabase code and try and host yourself if you get there.

I’m a “real engineer” and I don’t want to do all that until I have to.

As a "real engineer" you'd likely use LLMs differently. I save my conversations, have chats and codebase exegesis summarized into .txt files, and constantly refactor LLM output. I have an increasingly reliable sense of when to dip in and write things myself and when to let the LLM rip. My LLM-assisted code is better than my hand-written code; how could it not be? I'd have to be committing raw LLM output without even reading it to end up somewhere worse. If I did that, how much of a "real engineer" would I be?

All this is to say: even if all progress on AI halted today, it would remain the case that, after the Internet, LLMs are the most impactful thing to happen to software development in my career. It would be weird if companies like Supabase weren't thinking about them in their product plans.

Have you found any good resources on how to get a good process going? That would be an interesting read.

I have two main issues, first the tooling is changing so rapidly that as I start to hone in on a process it changes out from under me. The second is verifying the output. I’m at like 90% success rate on getting code generated correctly (if not always faster than I could do it) but boy does that final 10% bite when I don’t notice.

An aside, I think the cloud ought to make your (perhaps especially your) list. At least for me that changed the whole economy of building new software enterprises.

I haven't, besides Carlini's piece, which is already kind of obsolete:

https://nicholas.carlini.com/writing/2024/how-i-use-ai.html

The Internet, LLMs, open source, high-level languages, the cloud --- that would be my top 5.

Yeah I think it depends on what I’m doing.

For “real work” done by a “real engineer”, I approach it almost exactly as you say.

For side projects/personal software that I most likely would have never started pre-llms? I’ll just go full vibe code and see how far I get. Sometimes I have to just delete it, but sometimes it works. That’s cool.

You make it sound like it’s a binary situation where in one case it doesn’t matter and in the other it’s No Problem. I think both are wrong.

An unsuccessful project might be unsuccessful because it got eaten by costs before it became successful.

A wildly successful project is risky to migrate.

The YC crowd seems to think the only worthwhile businesses are worth $1 billion+ otherwise why bother

If you are trying to commercialize something, a popular project with bad margins is a better spot to be in than an unsuccessful project with good margins. If it's a personal learning project, that might not be the case.

Counterexample:

https://x.com/levelsio/status/1730659933232730443

I don’t think that’s a counter example. If hood maps shows a lot of potential then the $11k is something to figure out.

If not, then it’s poor price controls.

IIUC Pieter Levels talks a lot about not prematurely optimizing engineering solutions because most ideas will flop.

I strongly disagree with this.

Most startups fail. Optimizing for getting revenue is more important than optimizing cost in the beginning.

If you get revenue you can solve the cost problem. If you don’t, it doesn’t matter.

Anything that gives you more shots at the goal is a win in a startup.

These cloud back and stacks are very cheap at low volume and honestly I expect them to remain so or even go down in price.

I've seen many colleagues bootstrap something - even if they're not themselves very technical - because they've leveraged these well integrated low cost platforms.

I do think it’s binary. The project either shows potential to meet your goal or it doesn’t.

I think it’s rare that fails to show potential because of the underlying technology that’s chosen.

Sure, Vercel is relatively expensive. But I just don’t see how you’d throw in the towel because the costs are too high without first evaluating how to lower them.

If you’re saying that the evaluation is likely to show that you’re stuck - I have never seen that be the case personally.

Regarding refactor: My understanding is that vibes codebases are effectively write-only due to their structural incoherence.

That’s my understanding also. I think a project that’s vibe coded could easily be recreated by a programmer using coding assistance.

Honestly I love that vercel and Superbase and these companies are making enormous amounts of money by only targeting JavaScript developers who have such a phobia of doing actual development work that they're willing to pay 10 times, 20 times the price for infrastructure to actually host their apps. They are not real developers and it's great to see them being squeezed and I'm glad that companies are making them pay through the nose and locking them in. They should suffer and face the consequences of their lack of skill.

Let’s not raise ourselves up by saying that other developers are no true Scotsmen based on what language they prefer.

“Real developer” label or not, it is now easier than ever to dream up, build, and ship an app. And at the end of the day, that’s all that matters—-what you ship. Just seems incredibly gatekeepy to devalue someone’s work based on the tools they used to build their product.

Yes, “vibecoding” still has issues (and likely will for the forseeable future). I’m sure the next decade will be an absolute boon for security researchers working with new companies. But you shouldn’t dismiss people based on their use of these tools.

And other commenters are right that these expensive infra tools can be replaced later when the idea has actually been validated.

I don’t think it happens because the “vibe coders” are necessarily clueless, it can very much be a calculated risk or tradeoff.

Based on the “vibe coders” crowd I see on X, they are a superset of indie hackers with lower barrier to entry when it comes to coding skills and less patience for mediocre success. They seem to have the “go big or go home” mindset.

As long as they have a popular product, they don’t mind forking over some of their profit to OpenAI or a hosting provider. None of the Ghibli generator app creators complained about paying OpenAI… If the product is not popular, no outrageous costs, and the product will be abandoned anyway very fast.

> the cool thing you made is locked into an overpriced cloud stack that will bleed you dry

Not necessarily applicable to vibing with Supabase specifically, right?

There are several ways to host Supabase on your own computer, server, or cloud.

https://supabase.com/docs/guides/self-hosting

I think the real "vibe coders" in the end will be people like me. Making neat little personal projects that don't use many resources and can be relatively insecure because they don't matter much. I made wannawatchsomething.com with no knowledge of how it works and full knowledge that it's insecure and dumb. It still does what I want and I couldn't have done it a year ago so it's a net win.

PostgREST is open source, and so is the rest of Supabase.

Migrating from it is not that hard so far. I did it on an afternoon for a customer.

Also a couple friends are running the open source version in their own containers.

Maybe there are (or will be) cloud only features, but for the basic service there isn’t as much lock-in as something like AWS.

None of these are expensive if they help you ship products that solve problems that customers are willing to pay for.

Heroku is the OG "vibe coding" platform and, honestly, it was awesome. The first platform where you could deploy with one CLI command, sure it was expensive, but for years it was my favorite place to prototype or MVP stuff.

I don't necessarily think this is a bad goal, but the term "vibe coder" is almost certainly considered derogatory now.

The day before yesterday I got a technical assignment from a company I was interviewing with to build a Next.js app. Normally I would build it myself, but that day it just felt so tedious, so I gave Claude Code a try. To my surprise, with little to no guidance (probably cuz it was React), it built the app and it even looked very similar to mock-ups the company gave. I changed some things here and there and submitted the task. The whole thing was done in about half an hour. Yesterday they emailed me to schedule the next interview. I'm hooked.

Sadly it seems the days of take home interview assignments are numbered. I much preferred them to live coding assessments when given the option.

We still do take-homes. You just design them assuming people are going to use LLMs. They're going to do that on the job anyways, so why tie a hand behind their back?

Same. We just ask people to explain what they delivered, and this is 1000x better and more interesting than any quiz or whiteboard.

LLMs have also allowed us to significantly expand the scope of what we ask candidates to look at. Previously, we were constrained by time budgets (the candidate's, not ours) to a relatively small project, from which we had to read tea leaves; minor variations, objective but still small-bore, were determinative of how candidates ranked. Now we can drop a pretty ambitious project, which creates a lot of variation and room to demonstrate approach.

I turn 50 tomorrow and I love vibe coding. In the hands of an expert with decades of experience in all the internal corners of C, Python and Postgres I find AI tools to be miracles of technology. I know how to ask them exactly what I want and I know how to separate the goodness from the bullshit. If Supabase is bringing AI closer to the developer at the database level then that is a great thing.

Do you have any writings or materials that show your process in depth? I’m interested in learning from those who know how to really squeeze the juice out of these tools.

I think what they are saying is the 'secret sauce' to successfully vibe coding is being an expert with all the languages, frameworks and tools yourself.

Makes sense to me, vibe coding basically shifts your burden to specification and review, which are traditionally things a senior developer should be good at.

I think there is a lot to be said about what tasks you give to it, how you describe the work and prompt it, and the iteration / workflow loop.

I have a limited intuition for this based off my AI usage the past few years, but I want to learn from the pros.

Vibe coding is excellent if you have the experience to understand what the AI is churning out and then what to do with it.

The problem we have now is we have people who aren't engineers trying to make an app and they end up creating insecure and buggy messes, then struggle with figuring out how to deploy, or they end up destroying all their code with no recovery because they didn't know anything about version control.

As a professional developer, this seems like a problem I don't need to care about.

All of those things were already happening with normal developers 10, 20, 30 years ago, and will keep happening, with or without AI.

AI allows it to happen at scale though.

I agree with this - I hear a lot of hate towards vibe coding but my experience with voice dictation and using 20 years experience in the trenches and so being very specific telling the model what to do has been, well, refreshing to say the least.

I used to pride myself of knowing all the little ins and outs of the tech stack, especially when it comes to ops type stuff. This is still required, the difference is you don't need to spend 4 hours writing code - you can use the experience to get to the same result in 4 minutes.

I can see how "ask it for what you want and hope for the best" might not end well but personally - I am very much enjoying the process of distilling what I know we need to do next into a voice dictated prompt and then watching the AI just solve it based on what I said.

Derogatory and just plain stupid.

Only rough if you're pretentious.

Making it easy for engineers, experienced OR aspiring is huge.

Yeah the heroku model, arguably AI makes the barriers for aspiring coders lower which means more potential customers

Part of what I think is rough is the framing of Postgres being "an alternative to Google’s Firebase" in the article. I mean, ok yeah they are both databases in a sense, but they are not the same thing at all. Firebase is a service and Postgres a database technology, and certainly not well-described as an alternative to Firebase by anyone competent in the industry. Lol.

I don't mean to demean "vibe coders" exactly either, but rather jumping on the hype train of using that term for your funding pitch. You're using AI to learn to become a software developer? Great! No problem with that.

But also — if you now have a database involved and you're handling people's data, you better learn what you're doing. A database provider pushing "vibe coding" is not a good look imo.

Hey man, their money spends like anyone else's.

Reply on news.ycombinator.com