A Vibe Coded SaaS Killed My Team(cendyne.dev)
cendyne.dev
A Vibe Coded SaaS Killed My Team
https://cendyne.dev/posts/2025-11-26-a-vibe-coded-saas-killed-my-team.html
103 comments
They said that the team they work with is being replaced by a vibe coded SaaS product and that when they look at the product it only looks like it could replace the actual engineers from a very surface level.
> It's like someone took some screenshots of a competitor
> At the shallowest depth, I can see how a CEO got bamboozled. The happiest path is implemented. The second happiest path is rough. The third happiest path is unhinged.
Yes I agree. There’s no context to anything and the furry images sure aren’t helping.
I bet the vibecoded SaaS didn't have furry-related professionalism issues and was actually a lot easier to sell.
What does this even mean?
not sure, but i'm getting the sense that they're annoyed that someone is expressing themself on their own personal blog and not being Professional enough
If this blog is a Psy Op by Big Furry to normalise weird anthropomorphic animal pictures then it isn't doing a good job of it.
Images, color palette, the whole nine yards distracted me enough that I couldn’t get past the fold.
Probably too scared to share the SaaS. Or maybe it's something big?
A part of me starts liking this kind of style because it feels more human... I'd rather wanna be bothered by some cringy writing than by those em dashes...
I had the same difficulty. i.e. what was the issue that caused a headcount reduction from a 1000 to 10 or less? It’s possible the organization had larger issues than generated code but again, difficult to draw conclusions without details.
It sounds like their employer is on the outs and in a bone-headed move to save on cost, is replacing the author's team and tech with some piece of crap vibe coded SaaS product.
They are expressing their (and their team's) bitterness over losing their jobs to something of such obvious poor quality.
I can empathize with this view. Seems like people's standards are a lot lower than they let on, and slop-ware is apparently A-OK at the right price point. Sad. But as the author points out, there will be legal consequences..
They are expressing their (and their team's) bitterness over losing their jobs to something of such obvious poor quality.
I can empathize with this view. Seems like people's standards are a lot lower than they let on, and slop-ware is apparently A-OK at the right price point. Sad. But as the author points out, there will be legal consequences..
What is happening to this person sucks for sure. But one thing I have learned in this industry is the thing being replaced is always better than the thing replacing it when you talk to the team who built and run the thing being replaced.
There is enough to read between the lines. Dilbert manager has bought into a barely competent app (that they think replaces humans) in a panic because costs. They’ll learn more lessons over the next year, if they survive. The author might be a bit emotionally charged right now and is writing between some lines as they help migrate. Once they have some emotional distance they might write the fully clear article you’d like.
It was completely incomprehensible to me.
The writing style and random interjections with eye catching cartoons make it hard to follow.
I found it clear
I don't know what to say, it was pretty clear to me even while skimming.
It's saying "enshitification ensues" through a well written story, to my taste at least.
The vibe coded aspect of this article seems quite irrelevant to me. If I read this correctly, an exec team (or just CEO?) got sold a terrible piece of software without proper vetting. Very bad software has existed for a long time, and this is an age-old story. Vibe-coded garbage perhaps has increased the volume of terrible stuff to wade through, but is secondary to a familiar story of dumb leaders making dumb decisions.
> The vibe coded aspect of this article seems quite irrelevant to me.
IMO not really, because of your own point:
> Vibe-coded garbage perhaps has increased the volume of terrible stuff to wade through
This is not a hypothetical, nor an incremental difference. People are drowning in garbage, and if they don’t use garbage generation themselves, they get pushed out because they have to review a ton of garbage and they have to bump their stats (CLOC, PRs etc).
> but is secondary to a familiar story of dumb leaders making dumb decisions.
Well, sure. Both can be true. The social lessons will take a long time. MBA style leadership doctrines typically last for a decade or more, until overwhelming anecdotal evidence pushes them into the next hype. In the meantime, we’re definitely in for a ride.
IMO not really, because of your own point:
> Vibe-coded garbage perhaps has increased the volume of terrible stuff to wade through
This is not a hypothetical, nor an incremental difference. People are drowning in garbage, and if they don’t use garbage generation themselves, they get pushed out because they have to review a ton of garbage and they have to bump their stats (CLOC, PRs etc).
> but is secondary to a familiar story of dumb leaders making dumb decisions.
Well, sure. Both can be true. The social lessons will take a long time. MBA style leadership doctrines typically last for a decade or more, until overwhelming anecdotal evidence pushes them into the next hype. In the meantime, we’re definitely in for a ride.
> This is not a hypothetical, nor an incremental difference. People are drowning in garbage, and if they don’t use garbage generation themselves, they get pushed out
Disney is the best example here. Iger recently suggested Disney+ users could make short form personalized content using Disney characters. This is very surprising to hear from a company who is extremely protective of those characters and the image of those characters. We do not yet have control over these image and video generation such that we can absolutely prevent certain classes of generation from happening. If they go through with it I'll give it a week (a month tops) before someone is able to generate porn with it. But hey, maybe the hit in stock will not be greater than the rise from the hype. But maybe that's part of the problem. Though they also don't appear to be getting any of that hype money either...
"hype". People spend a shitton of money to go to a Disney resort so their daughters can see a Disney princess up close and personal and have her say their name and ask them how they're doing. $299.99 for a TikTok where your daughters favorite princess asks her how's she's doing and tells her she's the best? Iger's gonna be buying the bank!
> Iger's gonna be buying the bank!
The vast majority of vibe-coded apps are subpar because they're not built by experienced developers who understand proper software engineering practices.
However...
while I risk sounding like the discussions in r/vibecoding, I am convinced that it is absolutely possible to create high-quality, entirely machine-generated applications. And yes it bothers me as well because I am also invested my craft.
What I found is that the key isn't in how you prompt the LLMs but in the comprehensive tooling and guardrails you build around the development process. This includes custom ESLint rules, specific type constraints, custom MCPs, and even tailored VSCode plugins. It works. Not fully autonomously, but effectively enough that you often only need to perform a final review before deployment.
I have no doubt in my mind that the majority of software will be written by machines but only after the right guardrails are set in place - not just better models, magic prompts and fingers crossed.
However...
while I risk sounding like the discussions in r/vibecoding, I am convinced that it is absolutely possible to create high-quality, entirely machine-generated applications. And yes it bothers me as well because I am also invested my craft.
What I found is that the key isn't in how you prompt the LLMs but in the comprehensive tooling and guardrails you build around the development process. This includes custom ESLint rules, specific type constraints, custom MCPs, and even tailored VSCode plugins. It works. Not fully autonomously, but effectively enough that you often only need to perform a final review before deployment.
I have no doubt in my mind that the majority of software will be written by machines but only after the right guardrails are set in place - not just better models, magic prompts and fingers crossed.
I've started researching modeling architectures as an intermediate step in TLA+, prolog or whatever works (didn't find anything reasonable yet) instead of going from plan.md directly to implementation (assuming this is the lowest level plan.md of course). Got a hunch LLMs being great at boilerplate and translation should make ensuring conformance feasible...
Can you share some tips? Right now I spend 20 minutes vibe coding 3000 lines of code and then 3 hours reviewing every single line.
Exactly, I found that most of the time, I spend significantly more time reviewing the code; most of the time, there is a lot of repeated code. Refactoring and cleaning the code also require a lot of time.
I found that the time I spend reviewing and refactoring is marginally less than the time it takes to write the code myself. For very repetitive tasks, there is a sweet spot.
The only case where vibe-coding really delivered on the promise of super high-speed development is when you completely gave up on the code quality or you are in a greenfield project where all the business logic hasn't been fully defined.
I found that the time I spend reviewing and refactoring is marginally less than the time it takes to write the code myself. For very repetitive tasks, there is a sweet spot.
The only case where vibe-coding really delivered on the promise of super high-speed development is when you completely gave up on the code quality or you are in a greenfield project where all the business logic hasn't been fully defined.
Work in smaller chunks. 3000 lines of code is horrible to review, regardless if it’s human- or computer-made. Structure the tasks in a way that will enable the agent will to verify and iterate by itself.
Reviewing 100% of generated code is undoubtedly good software engineering practice, but its not vibe coding, at least by my definition.
I vibe coded a tool this week and my process was an iterative process of the prompting an LLM agent to implement small bits of functionality, the me checking the resultant output by hand (the output of the program, not the outputted code). There were shockingly few problems with this process, but when they did arise, I fixed them through a combination of reviewing the relevant code myself, reviewing log files, and additional prompting. I dont think I actually wrote or fixed a single line of code by hand, and I definitely haven't read 100% of it.
Once the project was feature complete, I used more or less the same process to refactor a number of things to implement improvements, simplifications, and optimizations. Including a linter in my automated commit workflow also found a couple minor problems during refactoring such as unused imports that were trivial for the agent to fix.
Is the code perfect, bug free, and able to handle every imaginable edge case without issue? Almost certainly not, but it works well enough for our use already and is providing real labor savings. But, its not documented very well, nor are any tests written yet. It might or might not be long term maintainable in its current state, but I certainly wouldn't be comfortable trying to sell or support it (we are not a software company and I am not a software developer).
I should note that while I have been very impressed with my use of agentic coding tools, I am skeptical that they scale well above small projects. The tool we built this week is a bit over 2000 lines of code. I am not nearly skilled enough to work on a large codebase but I suspect this vibe coding style of programming would not work well for larger projects.
I vibe coded a tool this week and my process was an iterative process of the prompting an LLM agent to implement small bits of functionality, the me checking the resultant output by hand (the output of the program, not the outputted code). There were shockingly few problems with this process, but when they did arise, I fixed them through a combination of reviewing the relevant code myself, reviewing log files, and additional prompting. I dont think I actually wrote or fixed a single line of code by hand, and I definitely haven't read 100% of it.
Once the project was feature complete, I used more or less the same process to refactor a number of things to implement improvements, simplifications, and optimizations. Including a linter in my automated commit workflow also found a couple minor problems during refactoring such as unused imports that were trivial for the agent to fix.
Is the code perfect, bug free, and able to handle every imaginable edge case without issue? Almost certainly not, but it works well enough for our use already and is providing real labor savings. But, its not documented very well, nor are any tests written yet. It might or might not be long term maintainable in its current state, but I certainly wouldn't be comfortable trying to sell or support it (we are not a software company and I am not a software developer).
I should note that while I have been very impressed with my use of agentic coding tools, I am skeptical that they scale well above small projects. The tool we built this week is a bit over 2000 lines of code. I am not nearly skilled enough to work on a large codebase but I suspect this vibe coding style of programming would not work well for larger projects.
That is a lot of code! Maybe that is the problem.
Normally I review 3-5 files in a single change. Tests are done separately to reduce the impact of writing tests that fit whatever it was written and there are a few dozen custom eslint rules (like eslint plugins) to enforce certain types of coding practices that make it harder for the LLM to generate code that I would other reject.
It is not that difficult really.
Normally I review 3-5 files in a single change. Tests are done separately to reduce the impact of writing tests that fit whatever it was written and there are a few dozen custom eslint rules (like eslint plugins) to enforce certain types of coding practices that make it harder for the LLM to generate code that I would other reject.
It is not that difficult really.
That's still a great trade in time if you end up keeping most of those 3000 lines.
depends on what you're trying to make. i suggest trying to vibe code a tool like i have called llm.exe which takes contents of predefined md file and sends it for response which is added to the end of the file. then incrementally add new flags to the tool to have more features and use other models, anything from generating audio using audio models to archiving and image input. Then try to create something in framework you are not familiar with and come up with your own methods allowing you to go much further than one shot. i tried to vibe code winapi and it's hard, but i think doable even for large scoped projects, the problem is context hoisting and you need to keep track of a spec. try to think what is the minimum text you need to describe what you are doing. ask models to generate one file or method at a time. i don't use fancy ide.
This is what I've never understood about vibe coding. Every attempt I've made (and quite a lot) makes me feel faster but in reality is slower.
When traditional coding >50% of the debugging is done while writing lines. If all you are measuring is lines out then you're discounting more than half the work.
I already have a strategy to optimize this. I work mostly in Python but it translates even when I work in compiled languages.
I write code 3 times.
Step 1: hack in an ipython terminal where I can load the program modules. This is actually where AI can help the most imo. Doesn't matter how messy, your first iteration is always garbage.
Step 2: translate that into a function in the codebase. Use Unix philosophy, keeping functions minimal. This helps you move fast now but more importantly you move fast later. Do minimal cleanup so everything is coherent. Any values should be translated into variables that the function can take as arguments. No hard coding! I guarantee even though you don't know it now you'll want to turn those knobs later. This is your MVP.
Step 3: this is a deceptively critical step! Write quick documentation. Explain your function signature. What is every variable's purpose and expected type. Ditto for the output. Add a short explanation of what the function does. Then you write developer comments (I typically do this outside the docstring). What are the limits? When does it work? When does it fail? What needs to be improved? What are the bottlenecks? Could some abstraction help? Is it too abstract? What tests do you need? What do they show or don't show? Big or small, add it. You add it now because you won't remember any of this after lunch, let alone tomorrow or in a year. This might sound time consuming but if your functions are simple then this entire step takes no more than 5 minutes. If you're taking more than 30 then your function is probably too complex. Either fix that now (goto step 1) or add that to your developer notes and move on.
Step 4: triage and address your notes. If there's low hanging fruit, get it now. A small issue now is a big issue tomorrow, so get it when it's small. If there's critical issues, address now. No code is perfect and you can't nor shouldn't address every issue. You triage! But because you have the notes if they become bigger issues or things change (they always do!) then you or someone else can much more easily jump in and address them.
This sounds complicated but it moves surprisingly fast when you get the habit. Steps 2-4 is where all the debugging happens. Step 2 gives you time to breath and sets you up to be able to think clearly. Step 3 makes you think and sets you up for success in the future even you'll inevitably come back. (Ironically the most common use I see is agents is either creating this documentation or being a substitution for it. But the best docs come from those who wrote the code and understand the intent, not just what it does). Step 4 is the execution, squashing those bugs. The steps aren't always clear cut and procedural, but more like a guide of what you need to do.
And no, I've never been able to get the to AI to do this end to end. I have found it helpful in parts but I find it best to have it run parallel to me, not in the foreground. It might catch mistakes I didn't see but it also tends to create new ones. Importantly it almost always misses big picture things. I agree with others, work in smaller chunks, but that's good advice when working with agents or not. Code is abstraction and abstraction isn't easy. Code isn't self documenting, no matter how long or descriptive your variable names are. I can't believe documentation is even a contentious subject considering how much time we waste on analyzing to just figure out what it even does (let alone if it does it well).
When traditional coding >50% of the debugging is done while writing lines. If all you are measuring is lines out then you're discounting more than half the work.
I already have a strategy to optimize this. I work mostly in Python but it translates even when I work in compiled languages.
I write code 3 times.
Step 1: hack in an ipython terminal where I can load the program modules. This is actually where AI can help the most imo. Doesn't matter how messy, your first iteration is always garbage.
Step 2: translate that into a function in the codebase. Use Unix philosophy, keeping functions minimal. This helps you move fast now but more importantly you move fast later. Do minimal cleanup so everything is coherent. Any values should be translated into variables that the function can take as arguments. No hard coding! I guarantee even though you don't know it now you'll want to turn those knobs later. This is your MVP.
Step 3: this is a deceptively critical step! Write quick documentation. Explain your function signature. What is every variable's purpose and expected type. Ditto for the output. Add a short explanation of what the function does. Then you write developer comments (I typically do this outside the docstring). What are the limits? When does it work? When does it fail? What needs to be improved? What are the bottlenecks? Could some abstraction help? Is it too abstract? What tests do you need? What do they show or don't show? Big or small, add it. You add it now because you won't remember any of this after lunch, let alone tomorrow or in a year. This might sound time consuming but if your functions are simple then this entire step takes no more than 5 minutes. If you're taking more than 30 then your function is probably too complex. Either fix that now (goto step 1) or add that to your developer notes and move on.
Step 4: triage and address your notes. If there's low hanging fruit, get it now. A small issue now is a big issue tomorrow, so get it when it's small. If there's critical issues, address now. No code is perfect and you can't nor shouldn't address every issue. You triage! But because you have the notes if they become bigger issues or things change (they always do!) then you or someone else can much more easily jump in and address them.
This sounds complicated but it moves surprisingly fast when you get the habit. Steps 2-4 is where all the debugging happens. Step 2 gives you time to breath and sets you up to be able to think clearly. Step 3 makes you think and sets you up for success in the future even you'll inevitably come back. (Ironically the most common use I see is agents is either creating this documentation or being a substitution for it. But the best docs come from those who wrote the code and understand the intent, not just what it does). Step 4 is the execution, squashing those bugs. The steps aren't always clear cut and procedural, but more like a guide of what you need to do.
And no, I've never been able to get the to AI to do this end to end. I have found it helpful in parts but I find it best to have it run parallel to me, not in the foreground. It might catch mistakes I didn't see but it also tends to create new ones. Importantly it almost always misses big picture things. I agree with others, work in smaller chunks, but that's good advice when working with agents or not. Code is abstraction and abstraction isn't easy. Code isn't self documenting, no matter how long or descriptive your variable names are. I can't believe documentation is even a contentious subject considering how much time we waste on analyzing to just figure out what it even does (let alone if it does it well).
It you're conscious of the guardrails you're putting in, are you really "vibe coding"? The whole idea behind "vibe" coding is that you don't pay close attention to what the LLM gives you, you just go along with the "vibe".
I've built a couple systems where most of the code was generated by LLM prompts, but I wouldn't describe what I did as "vibe coding". Instead I was reviewing judiciously and applying my software engineering experience to ensure that the codebase was evolvable and maintainable. Not everything required careful review because certain subsystems were low risk and tolerant of sloppiness, but knowing where to watch like a hawk or hand code something was part of what I did.
I question the extent to which effective guardrails can be put in place as a general case. My impression matches what I've seen from others, which is that LLMs make senior devs who know how to supervise them more powerful — but I'm less certain about junior devs.
I've built a couple systems where most of the code was generated by LLM prompts, but I wouldn't describe what I did as "vibe coding". Instead I was reviewing judiciously and applying my software engineering experience to ensure that the codebase was evolvable and maintainable. Not everything required careful review because certain subsystems were low risk and tolerant of sloppiness, but knowing where to watch like a hawk or hand code something was part of what I did.
I question the extent to which effective guardrails can be put in place as a general case. My impression matches what I've seen from others, which is that LLMs make senior devs who know how to supervise them more powerful — but I'm less certain about junior devs.
This is so difficult to read that I was tempted to just throw it into a chat model and let it summarize from me. Still tried to make sense between all those furry images.
Now from what I understand the company rode the pandemic wave and over hired and over spent. Their VC funded competitors out market and out sold them.
The plan was to exit gracefully once a certain number was hit and return money to investors. But then investors decided to bet on a SaaS.
As revenue went down and teams were cut down. With no revenue to support the engineering team. Investors/leadership are now taking a bet on the vibe coded SaaS.
Rest of the post is lamentation about this badly written SaaS and its vibe coded nature. There seem to be no formal contract with this SaaS but people are already being laid off and the non-American app developers seem unaware of local laws etc etc.
As much I feel for the writer I don't think the title is apt. It isn't as much as Vibe coding which killed the team, as it was bad financial decisions. Surely this vibe coded app hastened the demise and much could be said about the terrible decision to go with a vibe coded app.
Now from what I understand the company rode the pandemic wave and over hired and over spent. Their VC funded competitors out market and out sold them.
The plan was to exit gracefully once a certain number was hit and return money to investors. But then investors decided to bet on a SaaS.
As revenue went down and teams were cut down. With no revenue to support the engineering team. Investors/leadership are now taking a bet on the vibe coded SaaS.
Rest of the post is lamentation about this badly written SaaS and its vibe coded nature. There seem to be no formal contract with this SaaS but people are already being laid off and the non-American app developers seem unaware of local laws etc etc.
As much I feel for the writer I don't think the title is apt. It isn't as much as Vibe coding which killed the team, as it was bad financial decisions. Surely this vibe coded app hastened the demise and much could be said about the terrible decision to go with a vibe coded app.
So the team has been fired before a contract has been signed?
The list of issues seem a minefield, including for the poor peon who found them. People who find issues can be at risk in the wrong companies. And I have no idea what legal obligations they may have.
The list of issues seem a minefield, including for the poor peon who found them. People who find issues can be at risk in the wrong companies. And I have no idea what legal obligations they may have.
Seeing the list, I thought they might at least have some reporting responsibilities. Alas, I am also not in the US.
A particularly insightful nugget in this article was your definition of vibe-coding from an experienced insider: "Ignoring the code entirely and only prompting". I've struggled with the definitions and wondered where the line is drawn. In private, I'm more strict with how I define vibe coding: "Prompting for information about code". However, it's strict so that I don't become dependent on AI while we're still discovering the harms.
It's unfortunate that head count is considered a cost to some. I always found that the people in an organization should be considered as important as profit. Where increasing headcount is as positive an indicator as increasing profits. I'm not sure how our economy came to this point, perhaps it's a symptom of our short-term financial planning.
It's unfortunate that head count is considered a cost to some. I always found that the people in an organization should be considered as important as profit. Where increasing headcount is as positive an indicator as increasing profits. I'm not sure how our economy came to this point, perhaps it's a symptom of our short-term financial planning.
"Ignoring the code entirely and only prompting" is the only definition of vibe-coding I'm aware of. It's from a Karpathy tweet (https://x.com/karpathy/status/1886192184808149383):
> There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists... I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension.
It specifically doesn't mean "using an LLM as a code assistant". It definitely doesn't mean asking the LLM questions about code which you'll then use to write your own code. Those are LLM-assisted activities, and it's totally fine if you're using the LLM that way. But it's not what the term "vibe coding" means. "Vibe coding" is giving up on any pretense that you're in control, and letting the LLM take the wheel. It's fun for getting quick projects done, but it's also now becoming a distressingly common practice for people who literally do not know how to program in order to get a "product" to market.
> There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists... I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension.
It specifically doesn't mean "using an LLM as a code assistant". It definitely doesn't mean asking the LLM questions about code which you'll then use to write your own code. Those are LLM-assisted activities, and it's totally fine if you're using the LLM that way. But it's not what the term "vibe coding" means. "Vibe coding" is giving up on any pretense that you're in control, and letting the LLM take the wheel. It's fun for getting quick projects done, but it's also now becoming a distressingly common practice for people who literally do not know how to program in order to get a "product" to market.
I agree that the vibe-coding definition is helpful.
Ideally, headcount can be seen this way: our company is giving many people the chance to do honest work and live dignified, meaningful lives. I think that should be a company's main social responsibility not superficial marketable stuff.
Ideally, headcount can be seen this way: our company is giving many people the chance to do honest work and live dignified, meaningful lives. I think that should be a company's main social responsibility not superficial marketable stuff.
What is this slug (or whatever is it) cartoon all over the place in this article?
It's the author's fursona.
Yikes.
i'll take it over the people with cartoon girls of dubious age.
it's the same demographic.
Theres some overlap but i've found the furries tend to lean to the left more. The guys with the cartoon girls often goes to the right.
You’re looking at the wrong axis. It’s got nothing to do with politics.
Client CEO was one-shot by a vibecoded startup. Basically the YCombinator dream scenario (for the startup not you). A lot of lessons from this for incumbents. Disrupt yourself before it happens to you.
i might start a vibe cooking restaurant, disrupt the marketplace, those incumbents are wasting money by cooking their chicken. If someone get's sick and sues i'll remind of the ELA, Eater License Agreement.
No employees, everyone there will be their own business and pay me for the privilege to work.
No employees, everyone there will be their own business and pay me for the privilege to work.
Until software actually has quality regulations expect more insecure crap to be shoveled out
we've forgotten the lessons of Therac-25
> pay me for the privilege to work
This is basically how services like Uber Eats work in my country. The basics of it are foreign students want to earn extra income by working a few hours per week. This is allowed on a student visa, but it's limited hours, so real businesses like restaurants or bars don't usually want to hire students.
First of all you need a means of transport. There are small companies that will rent to you - on a weekly basis - an electric bike or a 20 year old Toyota Prius that is barely legal to drive (we have strict technical inspections here, so it's not that bad). They handle all the maintenance and insurance, you just pay your money and get a vehicle.
Next up you probably can't use your drivers license from home here to drive, as once you have a residence visa you need a local license. Many people just risk it, but if you want to do it legally you need to have a minimum number of lessons with an instructor and then pass the test. The test is only in the local language, so if you don't speak it (zero chance as a student that's been here 3 months), you need to hire a translator to accompany you on your test. They may or may not help to ensure your answers are correct. (You can only exchange a driver's license from other EU countries)
Finally you need a worker account on the delivery service, and the bag. You can register as self employed, file all the documents, go through the training course. That will take time, plus I think they are not always looking for new people due to high demand from workers. So you can skip all that and just rent an account from someone else, and hope they pay you at the end of the day.
So there is an entire industry dedicated to helping people earn a side income. I'm surprised the delivery services themselves don't start getting involved in this as it is a lot of money they are leaving on the table - although most of it has a questionable legal status.
This is basically how services like Uber Eats work in my country. The basics of it are foreign students want to earn extra income by working a few hours per week. This is allowed on a student visa, but it's limited hours, so real businesses like restaurants or bars don't usually want to hire students.
First of all you need a means of transport. There are small companies that will rent to you - on a weekly basis - an electric bike or a 20 year old Toyota Prius that is barely legal to drive (we have strict technical inspections here, so it's not that bad). They handle all the maintenance and insurance, you just pay your money and get a vehicle.
Next up you probably can't use your drivers license from home here to drive, as once you have a residence visa you need a local license. Many people just risk it, but if you want to do it legally you need to have a minimum number of lessons with an instructor and then pass the test. The test is only in the local language, so if you don't speak it (zero chance as a student that's been here 3 months), you need to hire a translator to accompany you on your test. They may or may not help to ensure your answers are correct. (You can only exchange a driver's license from other EU countries)
Finally you need a worker account on the delivery service, and the bag. You can register as self employed, file all the documents, go through the training course. That will take time, plus I think they are not always looking for new people due to high demand from workers. So you can skip all that and just rent an account from someone else, and hope they pay you at the end of the day.
So there is an entire industry dedicated to helping people earn a side income. I'm surprised the delivery services themselves don't start getting involved in this as it is a lot of money they are leaving on the table - although most of it has a questionable legal status.
I'm flummoxed by the comments here, and why is this flagged? The article couldn't be clearer:
Startup had a product. Revenue was going down, headcount was already brought to a bare minimum. Startup started to prepare to exit and return remaining funds to investors. Game over.
Instead, investors talked startup leadership into firing nearly everyone still around working on the product and pivot to using a vibe-coded SaaS for the basis of its product. All signs point to this being a poor-quality, faulty, quite possibly illegal product as a result, but do leadership & investors care? Seems not.
OP is going to aid in the migration (my question: WTF?) and then leave.
My commentary: our industry is so fscked, and a hearty two-finger salute to every software engineer who told me in 2023 that AI wasn't going to replace humans, the humans who use AI are going to replace humans. Lol, lol, and again I say, lol.
Startup had a product. Revenue was going down, headcount was already brought to a bare minimum. Startup started to prepare to exit and return remaining funds to investors. Game over.
Instead, investors talked startup leadership into firing nearly everyone still around working on the product and pivot to using a vibe-coded SaaS for the basis of its product. All signs point to this being a poor-quality, faulty, quite possibly illegal product as a result, but do leadership & investors care? Seems not.
OP is going to aid in the migration (my question: WTF?) and then leave.
My commentary: our industry is so fscked, and a hearty two-finger salute to every software engineer who told me in 2023 that AI wasn't going to replace humans, the humans who use AI are going to replace humans. Lol, lol, and again I say, lol.
>we'd be immediately in violation of the California Consumer Privacy Act (CCPA), California Privacy Rights Act (CPRA), Telephone Consumer Protection Act (TCPA), CAN-SPAM Act, Americans with Disabilities Act (ADA).
>How could a platform be that bad?
People care about technology solving their problems, not that it is 100% legal.
>How could a platform be that bad?
People care about technology solving their problems, not that it is 100% legal.
Most obnoxious link I've ever clicked on from HN.
I subscribe to a Telegram channel that posts the most recent posts on HN that meet a certain minimum karma threshold. Because it's a public channel, anyone can add emoji-based "reactions" to posts and have those reactions displayed for everyone else viewing to the channel.
The reactions as of 2025-26-25T21:51:30Z are as follows:
kiss 10; crying face 2; moai statue 2; trophy 1
The only things I can think of as to why so many people are reacting with a kiss emoji are a. people think the distorted "new girl" is hot, or b. people think the author's fursona is hot
I'm personally rooting for the latter, but I'm biased (see website for proof)
The reactions as of 2025-26-25T21:51:30Z are as follows:
kiss 10; crying face 2; moai statue 2; trophy 1
The only things I can think of as to why so many people are reacting with a kiss emoji are a. people think the distorted "new girl" is hot, or b. people think the author's fursona is hot
I'm personally rooting for the latter, but I'm biased (see website for proof)
This article makes sense when you figure out that the author's assumption is that vibe-coded == bad.
It sounds like this startup headed for closure anyway, with it's failing revenue, "At the same time, the current revenue projection calls for the end of the business within a few more months."
So, the vibe-coded app is a hail mary by the CEO / investors? If you're already just a few months from closing shop, maybe switching to a vibe-coded up saves you a ton of engineering headcount and gives you a chance? Changes the math on how you price the product?
Maybe slugs were meant for better things than engineering
It sounds like this startup headed for closure anyway, with it's failing revenue, "At the same time, the current revenue projection calls for the end of the business within a few more months."
So, the vibe-coded app is a hail mary by the CEO / investors? If you're already just a few months from closing shop, maybe switching to a vibe-coded up saves you a ton of engineering headcount and gives you a chance? Changes the math on how you price the product?
Maybe slugs were meant for better things than engineering
It sounds like the owners desperately leapt on a cheap SaaS as a life boat while the ship sunk, and the writer is blaming the life boat.
Clearly not AI written because I didn’t get the point or the SAAS in question.
The author very clearly says that they're not naming the application in question.
Al definitely made this easier but I've been on this particular merry-go-round a few times and I suspect failing to properly evaluate a product that seems too good to be true is actually a tale as old as time.
(Still sucks though, sorry and good luck)
(Still sucks though, sorry and good luck)
I'm old enough to remember all the horror stories like this when people were outsourcing.
Fast, Cheap, Good
Unvetted imported code = the first two, and only the first two.
Unvetted imported code = the first two, and only the first two.
So your employer was on the road to bankruptcy and they decided to replace the tech stack with AI as a hail mary? Did I understand that right?
Talk about an unenviable situation.
Talk about an unenviable situation.
I like the post first explains just what happened in enough detail, then comes with conclusions. It is more helpful to me as a data point.
As the style, images seem weird at first, but they help conveying emotions, point of view. Somehow, they also help with attention for me.
As another commenter said, it seems that guardrails will be important. I believe, 'software is managing complexity' at the end of the day. The complexity and decision-among-options will continue to exist. They need to live and taken care of somewhere.
As the style, images seem weird at first, but they help conveying emotions, point of view. Somehow, they also help with attention for me.
As another commenter said, it seems that guardrails will be important. I believe, 'software is managing complexity' at the end of the day. The complexity and decision-among-options will continue to exist. They need to live and taken care of somewhere.
Vibe-management and vibe-coding. What a pairing.
> Somehow, I need to keep the tech coasting in its last days while migrating all the data that I can.
I mean. What they are going to do if your time expires? Give you a bad evaluation because they didn't plan the change correctly?
But something tells me your company might be in a much worse situation than you might know. They might just doing cost cuts everywhere to stay afloat. Or maybe they are just greedy too...
I mean. What they are going to do if your time expires? Give you a bad evaluation because they didn't plan the change correctly?
But something tells me your company might be in a much worse situation than you might know. They might just doing cost cuts everywhere to stay afloat. Or maybe they are just greedy too...
ramesh31(12)
Like maybe it's that I just woke up, but all I really got out of this was that a vibe-coded app resulted in a company being downsized. But that's in the title. Any specifics beyond that? I really couldn't say despite having read the whole article.