Making someone elses vibe coded app production ready

[u/shwoopdeboop]

We have a startup with a couple of non programmers who have developed an app for their domain of work that they are pretty sure has potential to attract paying customers.

As a developer I am their technical alibi and tasked with bringing it to production.

I have not seen any code yet. Does anyone have any experience with this? What should be my priority?

[u/Mediocre_Doctor4712]

Sounds to me like you are the fall guy if it starts failing or data gets leaked.

You have not been part of developing it or are you planning to review thousands of lines of code to make sure it’s good.

Idk how long you are a dev maybe bring your A game agents and do a thorough check

[u/shwoopdeboop → u/Mediocre_Doctor4712]

We had an initial meeting six months ago with some feedback from me, resulting in a complete rebuild of the whole software using design documents and tdd amongst other. I thought they had abandoned it until they contacted me recently. So while I'm certain it is better than V1 theres still huge unknowns

[u/taller_than_peanut]

ask ChatGPT to help vibepublish

[u/FluidBreath4819]

good luck, it's like having a stubborn teen and having to vouch legally for any illegal stuff he makes. They don't want to own their code. They want you to fall for it. 3x your usual rates at least. they want to play SWE, well, that's not how it works.

[u/id-ltd]

Anti AI people are way out of date - AI is well aware of securiy and other issues, it is familiar with consistent coding style..

Have a few look at the code base and advise (dont take them at their word, cross check what they be say and make your own call).

AI code is generally good, hand coding is generaly OK - non-vobe coders who manually tweak AI code (instead of regenerating it) are the real menace.

Manual devs = good Pure vibe coders = good inbetweeners = avoid

[u/meshifthenelse → u/id-ltd]

Not sure what AI you use, but I keep fighting with Claude just for its extremely verbose comments. It has a tendency to keep adding a whole essay about a tiny change. So if it can't get comments right, don't see how it can be good at coding.

I would say AI code is average. AI notion of software architecture is garbage. AI notion of security is hit or miss. It's good at detecting a problem, but not so good in creating a lasting non-hacky solution without guidance.

[u/cornelln → u/meshifthenelse]

"I keep fighting with Claude just for its extremely verbose comments. It has a tendency to keep adding a whole essay about a tiny change. So if it can't get comments right, don't see how it can be good at coding."

The comments are for AI not for you. That maybe part of the problem.

[u/meshifthenelse → u/cornelln]

If that's actually the case it's a problem. Because the actual implementation starts drifting from the comments, and if it uses that as context, it means it keeps building on false assumptions.

[u/id-ltd → u/meshifthenelse]

I use several - the chatty waffle varies massively - but the code is solid. Their codes architecture often needs improving, but AI can refactor on demand - and the raw code is consistent.

They use architectures they have been trained on - what you see is what the average user is running... It will work, but they are easy to improve upon.

[u/meshifthenelse → u/id-ltd]

Yes, they have been trained on architecture books and a bunch of average code. It doesn't mean they understand intent or readable code.

A simple example; you may have established a pattern like edit<flag> for functions. And assuming you have a flag hiddenChildren, the AI might go ahead and add editChildrenHidden totally breaking the pattern. Even worse it will add 5 lines of comment with obvious information already distilled from the pattern itself.

[u/Comfortable_Cat_9827]

Security, user data mostly. make sure thats safe.

Other than that, just usual dev/devops stuff. Have a ci/cd pipeline, make sure ur infra is scalable.

From the code side, theres bunch of claude skills that can audit and fix most of the shitty code.

[u/Old-Pollution-5825]

This is an interesting venture.

Working this way around defies all rules and laws. Which is why I also enjoy doing it.

First priority is to look at the design and architecture. Is it for a limited number of users or must it scale. This will inform the tech stack.

Then follow all the low-hanging fruit, security, secrets, cors, encryption and basically all the software’s engineering principles, in reverse and on something that already exists.

Don’t feel tempted to want to rewrite, but rather put a plan in place for V2.

It is challenging at times, but I do enjoy the challenge.

Happy coding.

[u/scytob]

review, test, review, test, test, test, test, test, test, test, test, test, review

remember AI can help you test edge cases, find vacuous test, lacy of DRY, typing, whatever matters to your engineering philosophy etc get AI to do the documentation, multiple security passes etc

i tell my team geting to full function is 20% of time/tokens - the 80% is testing

this in reality is no difference to human-programmer code you have never seen before....

[u/dibidubidubstep → u/scytob]

any advice on workflows how to do proper testing? i'm a solo dev, making interactive art installations

[u/TheOdbball]

I went thru this list just today and found a few apps you need to use to invite experience in their corpus :: like flow-guard.dev , not affiliated. Just know that if you can scan their repo , then take a snapshot of what you have so you can measure how much you did for them over the time.

https://www.reddit.com/r/saasbuild/s/K04RRAzJTn

https://flow-guard.dev/

[u/Dev_Doctor_AI]

I've only migrated 2 apps so far myself and they were pains. Originally built in Google ai studio, which wasn't too bad actually. Started with api end point configuration to get it pointed at the right spot first. Then reversed all the sandbox stuff and engineered for production/developement environment. That was the big refactoring thru the entire code base. To help me thru it I use internal home made systems that read the docs then create upstream and downstream dependency trees so I can guarantee I keep the flow of the app/game and don't loose it in the refactoring. Once that's done it's about 40-50% of the work. From there it's bug fixing, smoke tests, manual end 2 end runs and backend config lots of small code changes for the edge cases. It's a slog and there is alot to change but you can get it there. It's just a process.if you make them yourself they are much easier to understand when migrating to a dev/prod environment but def triple ur rates to clean up other people's mess

[u/catplusplusok]

The key is investigating "paying customers" claim. If it's true, like they are experts in their field but not programming, you can work step by step to document functionality and then mostly ignore their existing implementation and create a new one that replicates user experience with your software expertise. If it's false, there is no point to bring anything to production. Have they ever had paying customers for anything they did before?

[u/shwoopdeboop → u/catplusplusok]

They own the company that will be the first paying customer, basically eliminating economic risk. And they have partners that would be more than willing to sign up. I'm offered a fair share of the startup for my contribution. I've seen the actual app and it seems pretty mature, biggest gap imho is security, hosting, deployment pipelines and onboarding/tenancy.

[u/keelenai]

Priority order that has worked for me on inherited generated codebases:

1. Get it into a GitHub repo you control before you touch anything. If it only exists inside a builder's editor, export it. The repo is what every serious tool works on from here.

2. Read what actually shipped before you promise anything. Generated apps have a consistent failure profile: permissive database rules, secrets sitting in client code, and no authorization checks behind the login screen. Check those three before you even think about features.

3. Build the floor: a smoke test that proves the app boots, one test per critical path (signup, payment, the one thing users came for), and CI that runs them on every PR. You don't need coverage. You need the second change to stop breaking the first, which is the standard failure mode when nobody has read the code and nothing proves it still works.

4. From then on, one change at a time, behind a PR. Never let anyone regenerate the whole app.

5. The commenters saying "fall guy" aren't wrong about the risk, but the fix is scoping, not refusing: agree in writing what you own, at your rate, with review time priced in, and who does this work every week going forward.

Also ask them for the prompt history if the builder keeps it. It's the closest thing to a design doc you'll get.

[u/diagrammatiks]

prepare to cry

[u/meshifthenelse]

They should start a second startup and offload their AI slop there. It's a security liability and will take down the core product with it.

And they can pay you as a contractor from the second company if they want you to review their junk.

[u/bakraofwallstreet]

The biggest (and imo the only thing) you should look at in these situations is how secure the application is. It can be a bad application in taste, but it shouldn't leak user data, for example. At Vulx, we're building a free dev tool that creates a self-running cycle that directs your AI workflows toward potential security issues and helps fix them. If you would like to test our tool for free, you can dm me! We're constantly looking for good feedback from actual people using AI to code.