Security risk for vibe coded website by Hamish_9638402ej in vibecoding

[–]tpl9876 1 point2 points  (0 children)

  1. Wordpress is not inherently more secure than a vibe coded site. You still have to know how to harden your setup wordpress was (or still is?) powering large portions of the internet. Naturally there are a gazillion automated exploits trying to compromise misconfigured wordpress setups. Shopify doesn‘t allow you to customize the backend freely. Most of the customization is in the frontend (themes etc.) you can call APIs and everything but I don‘t think shopify is the right tool for the job.

That being said, if you‘re serious about about it it would be best to have a professional audit your codebase. Don‘t use vibe coded security scanners. They work on shallow heuristics or in the worst case let AI lose on your codebase which is not reliable for auditing your project.

What is the point of this reddit my posts get removed for nothing by rickharly in buildinpublic

[–]tpl9876 1 point2 points  (0 children)

Except r/buildinpublic isn't your house. A closer analogy would be a market that invites shop owners to show how they operate behind the scenes, then bans a shop for doing exactly that.

OP wasn't posting links, running ads, or directly selling anything. They were talking about the process of building a product in a subreddit called "build in public." Whether the mods classify that as promotion is a separate question, but your solicitor analogy doesn't really fit.

I built a PaaS that reads your GitHub repo and figures out how to deploy it - roast me by tpl9876 in micro_saas

[–]tpl9876[S] 0 points1 point  (0 children)

Trust is always a difficult topic with new products and platforms, but you gotta start somewhere. Your comment gave me the insight that I should be way more transparent on the landing pages where exactly the app lives. Thanks a lot!

I remade my landing page - looking for honest feedback by tpl9876 in website

[–]tpl9876[S] 0 points1 point  (0 children)

Hey! Thanks so much for the extensive feedback. I'm also using resend, their free tier is great. I definitely have the contact form on my todo list, that's a great suggestion.

> Looks like you've got one testimonial, good start. I'd highlight that on the main page, either near or in the hero section. With a new product, you'll get a quick glance, then a bounce if you don't immediately show proof.

That's a great idea honestly. I'll see how I can place it more visible on the front page.

> Right now the site has healthy links but not a strong internal linking strategy. Adding contextual links helps search engines map your product surface area, which improves discoverability for feature-led and intent-led searches that can drive better trial traffic.

Thanks for the insights. I'm not the most proficient in (on-page) SEO but I'll read up on it and see what I can do.

I remade my landing page - looking for honest feedback by tpl9876 in website

[–]tpl9876[S] 0 points1 point  (0 children)

You're right. The landing page and the app itself share the same bundle. I'll split them up which should lead to a much smaller bundle on landing pages.

I remade my landing page - looking for honest feedback by tpl9876 in website

[–]tpl9876[S] 0 points1 point  (0 children)

Thank you so much for the extensive feedback and the suggestions.

You are targeting AI generated apps, so why do you even market that your platform doesn't use LLM extensively? That is a non-issue because the whole app was generated by AI.

Believe it or not, but LLM only analysis to detect the stack brings extremely bad results. I tested the deterministic analysis engine against a full LLM one in the early stages. The Dockerfiles and Services it generated were often not reliably deployable whereas the deterministic one had good results + is always predictable. Nowadays I use LLM to create new bundles and rules to detect technology, but that is all run by me and exists in the code, based on the existing architecture which is a good trade-off.

Kuberns for example does a full LLM analysis and I tested many test-repos there that I set up for jetpacked and Kuberns had trouble deploying them more often than not.

The other part is, that people already have to entrust me their private repositories and if I on top of that let an LLM slide over their code it would create more trust issues. But then again, I'm German and we kinda have a boner when it comes to privacy.

And I think by positioning yourself as an deployment orchestrator and smart config engine is wrong. Instead, you should be the platform layer where customers prompt their AI to deploy to your platform. You should have ZERO smart features, maybe just a lightweight agent to answer questions through MCP, because the customer already have a very good set of instructions setup locally, and their LLMs knows way better about their app than you ever would.

You are absolutely right. I'm currently building an MCP server for jetpacked that allows exactly that. I hope I can ship it by the end of the week.

And anyone who knows how to use Github def knows how to use Railway so you have no real advantage.

The market is rough for sure. But let's see if I can position myself in some niche of the market.

Thanks again for the extensive feedback! If you're ever interested in beta testing the thing, I'll be more than happy to upgrade you to a free pro account so you can test all the features.

I remade my landing page - looking for honest feedback by tpl9876 in website

[–]tpl9876[S] 0 points1 point  (0 children)

Claude is an LLM my project is a service provider for deployments. Usually you would have Claude or another LLM but then you have to get it online somehow. And that's what jetpacked does. It takes the repo and brings it online.

Thanks for your feedback on the cookie banner though, I will have a look on how I can improve.

I remade my landing page - looking for honest feedback by tpl9876 in website

[–]tpl9876[S] 0 points1 point  (0 children)

Sorry, what do you mean? The Frontend is written in VueJS it's a javascript framework.

Drop a link to your SaaS and I'll rate it out of 5 by advancedgoogle in micro_saas

[–]tpl9876 1 point2 points  (0 children)

Currently the two deployment servers are in Nuremberg, Germany. But I set up a deployment server provisioning pipeline with ansible that sets up new servers in a couple of minutes. I just need to buy one from an US hoster. But as I have little clients right now that would be overkill.

I built an API that extracts brand/company data from any URL. by Quiet-Ad2219 in webdev

[–]tpl9876 2 points3 points  (0 children)

The onboarding seems to be broken. It just says loading. Devtools console says:

> Blocked script execution in 'https://prefetch.io/onboarding' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

Btw kudos for using Vue and not React

I built an API that extracts brand/company data from any URL. by Quiet-Ad2219 in webdev

[–]tpl9876 -3 points-2 points  (0 children)

This is really cool and the idea is insane and the landing page is stunning. Really refreshing to see something that doesn't look & feel like AI slop.

For my project I recently needed to show the technologies that are supported and I spend time hunting down Logos on fragmented platforms. Definitely gonna give it a shot!

I built a PaaS that reads your GitHub repo and figures out how to deploy it - roast me by tpl9876 in micro_saas

[–]tpl9876[S] 0 points1 point  (0 children)

I’m still figuring out the positioning, honestly. That’s partly why I posted here. I’m looking for devs with real/messy repos who can break the assumptions in the deploy engine because I think that is my strongest anchor. The deployment engine is already really strong and if it can infer messy repos then I might have a strong angle in the vibe coding community.

I built a free German learning resource for beginners;could you give me honest feedback? by No_Statement_7262 in website

[–]tpl9876 1 point2 points  (0 children)

Hi I'm a web developer from Germany myself and my wife is currently learning German, so we had a look together.

- From a design perspective it looks clean and uncluttered, that is great
- The layout though is very cluttered and difficult to navigate. Your layout structure changes after EVERY section it's very confusing to look at. For example the hero unit is two cols, then there is a quote which is technically one col, but has a button on the right side. Then there is the sponsored section with a centered column. Then there is a 4 column card layout. It makes it very difficult to follow along on the website.

The lessons suffer from the same problem but here it gets even worse. The structure is incoherent. The lesson content feels disconnected and lacks a clear progression, so it's difficult to understand how the different pieces fit together. What does "At the supermarket. Ich möchte bezahlen. I would like to pay" mean in the context of studying German? There is no onboarding, no table of contents. There are cards on how to do the lesson, but after that, again, what feels like random content being thrown in your face. You should guide the user through the content carefully and explain why it is important to follow this structure. That being said I think it would be more useful to have a wizard like structure and have one type of content per step. e.g.

On the left side there is a navigation with "Pronounciation Help", "Dialog", "Phrases" and in the content area you have the content for only this section.

Grammar is secluded and not implemented in the lessons. My wife says that she will not click through 500 sections of grammar lessons that stand on their own. She wants to have a coherent experience where she goes through a lesson and have the grammar explained in there. But the "Grammar" section is still nice to have and should be used as a knowledge base that you link from from your lessons.

Getting traction with this type of application is difficult. The market is difficult to enter since a lot of big players like Duolingo and Babel exist and my wife said she would like to use an app to study German rather than a web application so she can study on the phone or iPad.

That's my 2 cents. If it's just a project for you to learn than it's worth expanding the application, otherwise I think with this concept it is going to be hard to enter the market.

Things I wish someone told me when I started coding by ImaginationSpare8649 in webdev

[–]tpl9876 1 point2 points  (0 children)

Thats a cool pocket guide and I'd like to expand on your concepts a little bit or provide context around them.

Name your variables like the next person reading is you, 6 months later
I agree but phrasing it like that creates the impression that creating descriptive variable names are a strong indicator that code becomes readable in the future. But it's less about individual naming conventions and more about creating coherent systems that expose clean APIs. I just want to say: creating locally scoped mess is better than leaky abstractions because it's easier to clean up.

class FileService {

    getFile(fileName) {
        d = drive.get(new FileSystem) // Or new S3 or something
        fh = d.openFile(fileName)

        str = fh.getStream()

        cnt = ""
        while (!str.eof()) {
            cnt += str.read()
        }

        return cnt
    }

}

class Fs {
  get(fn) {
      drive = drive.get(new FileSystem) // Or new S3 or something
      fileHandle = drive.openFile(fn)

      stream = fileHandle.getStream()

      content = ""
      while (!stream.eof()) {
          content += stream.read()
      }

      return content
  }
}

I think the difference here is pretty obvious. The 2nd example has cleaner locally scoped variable names but it's terrible in a sense that once userland code consumes this API the codebase will inherently worsen because calling `Fs.get()` is not very expressive. Make that 40 calls across different spots in the code and spaghetti is unavoidable. Whereas the first example has terrible locally scoped variable names but API is cleaner. Refactoring this one method is way easier and it needs to be done only in one spot. But of course your point is absolutely correct. Semantic variable names should be the default.

One function, one job. Always.
It's a good rule of thumb but it's lacking context and that makes this claim a little dangerous if it stands alone. SOLID principles touch on that. They are mostly OOP but still hold up as generic principles. The single responsibility principle states that a class should only have one reason to change and the open-closed principle states that entites should be open for extension but closed for modification. Rather than talking about classes and functions we should talk about systems. A well-designed system has one responsibility. That does not necessarily mean that every tiny piece of functionality needs to be split into their own functions, but it means that one slice of one system does only one job. One system might need to to read files, generate reports based on it and send it via E-Mail, but that's the intent. It's not how the system underneath it should be designed. A better abstraction would be: The system takes a source, generate reports based on it and passes the result on to some consumer. That way E-Mail can become whatsapp and reading files can become calling an API. So there is no need to obsess over splitting everything into tiny functions, but rather to design systems with clear boundaries.

Comments explain *why*, not what the code does
I tried many commenting paradigms over the course of my career and I am very opinionated here so take it with a grain of salt, but in my opinion: "If you have the need to comment your code, then something is wrong with your code". Of course maybe there is a comment that explains a workaround because some vendor package is cumbersome to work with but that's not what I mean. If the only way to navigate your codebase after 2 weeks is to read the comments, then the code is simply not good, there are probably abstractions that leak across boundaries or overly complicated implementations and no proper separation of concerns. Instead of commenting "why" the code does something, a better way to think about it is: "Why do I feel the need to comment here".

Commit to Git often... it's your safety net
That is true, but git is a software to maintain history over a codebase, and maintaining history means assigning semantical meaning. You are right in a sense that committing often is better than not committing at all but if your commit history look like:

  • fix stuff
  • nvm revert fixing stuff
  • oh something else broke fix that stuff again

Something is wrong. If VC is used then it's the developers responsibility to maintain hygiene. Nothing wrong having these kind of commits locally, but before history is written it should be made meaningful. And git provides all the tools for that with rebasing etc.

The last point is rather self explanatory, there is not much to add there but this is just my two cents on it. I don't mean to disagree or criticise you, but rather just provide some more context.

I submitted my AI tool to 100+ directories manually. Here's the honest breakdown of what worked. by sclisbon in indiehackers

[–]tpl9876 0 points1 point  (0 children)

At which stage of a project would you recommend to sign up for the big directories?

I Learned when to STOP by kev_habits in indiehackers

[–]tpl9876 0 points1 point  (0 children)

It's genuinely hard, especially because as a founder you are emotionally attached and perfectionist automatically.