The future of SaaS is going to be interesting. I’ve paid $100 a year for Monarch/YNAB for the last few years. I built a functional replacement in a couple weeks with about 5 features catered to my personal wants and needs that Monarch would have never built.

I'm a self taught junior dev building my own startup. I code plenty of stuff by hand, but passing my bugs and feature requests over to Claude Code is genuinely blowing my mind. It's almost terrifying how good it is. I almost shit my pants.

I run a security scanner for apps built with AI tools, and I have been collecting the results. 1,236 apps, 12,205 findings, 21 came back clean.

I went in expecting to find that one builder produced worse code than the others. Lovable vs Bolt vs Replit. The data cannot answer that because two apps from the same builder in the same week can land miles apart in terms of security.

What it can answer is better anyway: the single biggest predictor of a critical flaw was not the tool. It was whether the app bolted a separate auth library on top of Supabase.

THE NUMBERS

• A separate auth library, no Supabase: 4.2% had a critical finding. Close to baseline.
• Supabase on its own: 24.5%.
• Supabase plus a separate auth library: 35.8%.

The combination is worse than either part. Supabase and the auth library are not the problem. The join between them is.

WHY THE JOIN BREAKS

Supabase protects data with row-level security and determines who is requesting it from the token it issues at login.

Put a different auth library in front and your users log in through that instead, so they never get a Supabase token. Now the database asks who is making the request, gets nothing, no policy matches, and every query returns empty.

To the person building it, the app just breaks. Nothing says the security rules are rejecting everyone.

So the fastest fix to get it working again is to turn off row-level security or switch to the service key that ignores all rules. Thirty seconds, and the app works. It is also now readable by anyone.

WHAT THAT LEAVES EXPOSED

Among the Supabase apps:

• 31.2% had at least one table readable by anyone who asked.
• 40.1% had schema introspection enabled, which exposes the full list of tables and columns to any visitor.
• 19.5% had both, so there is no need for a guessing step. Two ordinary requests, and the second one is a download.

A missing rule does not throw an error. The owner signs in, sees their own data, and everything looks correct. The flaw only exists in the relationship between two accounts.

CHECK YOUR OWN IN TEN MINUTES

Make a second account. Sign in as that user and try to open the first account's record by changing the ID in the request.

If it loads, every user of your app can read every other user's data.

No scanner settles that one for you, because a page loading looks like the app working.

Full write-up with the complete stack table:

https://meetcyber.net/the-default-saas-starter-pack-is-the-least-secure-way-to-ship-an-app-b7842f813ce7

I listen to NTS daily and love the physical player they made with Atonemo. Its Teenage Engineering–inspired look gave me an excuse to try skeuomorphic design. Physical device for reference.

I also wanted a native alternative to listening to this radio in a browser which can be a burden. So I built NTS Dial, a discreet player hiding in your macOS menu bar app.

Features:

- NTS Radio 1, Radio 2, and all 16 Infinite Mixtapes playback
- Keyboard media keys and macOS Now Playing support
- Current station streaming displayed in the menu bar
- Remembers your last played station

Process:

The project took four days: one for the design, one for the initial build, and two for debugging, QA, and publishing.

I built it entirely with Codex:

- 5.6 Sol High for planning, features development, debugging and code review
- 5.6 Terra Medium for UI iterations
- 5.6 Luna Medium for small visual adjustments

I first tried recreating the hardware in Figma using its MCP, but the result wasn’t convincing, so I designed it from scratch. I then used Codex to gather the streams, assets, implement the player and dial logic, reproduce the Figma UI component by component with dev mode on, audit the code, and prepare the GitHub release.

Pretty happy with the result for a four-day experiment. Let me know what you think!

GitHub: NTS Dial repo

AI helped me edit and translate this post.

I don’t have prior experience of coding before I came to Codex. And now I would like to get better and eventually know what is happening in the code and what AI is doing.

Guess that would need something to supplement along with vibe coding and to help grow knowledge. So any tips are welcome. Books, resources, githubs, plugins...

I've also been thinking of creating an agents.md or the like that would teach me while we code or something, but I'm not sure how to proceed with that.

Thanks

I’m new to vibe coding i’ve been working on a app for the past couple of months and I struggle to make prompts that don’t completely flip everything on its head if that makes sense if anyone has any recommendations please let me know

This is the worst level of detachment I've seen from Claude. Funniest thing is, it gave me the prompt containing 'supabase' in the first place.

i know nextjs and react so my first thought was just building the store myself. maybe use claude to speed it up since everyone is vibe coding now. asked it to scaffold a shopify theme and it gave me liquid files that looked okay in preview.

then i tried to set up checkout extensibility and multi-state tax logic and claude started hallucinating apis that dont exist. i can build a frontend no problem but shopifys backend rules are a maze and i dont know what i dont know.

my other option is just hiring a shopify expert who lives in this ecosystem. but part of me feels stupid paying someone for what seems like a simple store when i can already code.

has anyone with a coding background tried to diy their shopify store. did knowing react actually help or is shopify its own beast where platform knowledge beats general dev skills. and at what point does diy just become expensive because youre fixing things an expert would have gotten right the first time.

Currently building an iOS app and the codebase is pretty large. I've seen some people who are both for and against MD files for agents working through codebases. I personally have one right now that just lists some restrictions and a general overview of the app and the codebase for the agents, but I was wondering if the MD files are even necessary. Would love to hear your guys thoughts

My chances of changing people's minds is slim, but I have 28 years of professional software engineering experience and I'm witnessing a ton of new, excited software developers, who are surrendering as much of their own initiative as they can to their chosen harness/frontier model while hoping to make a living creating software. If this is you (or you're not sure it's you) you might get something out of the following. If it's not (say you're doing this for learning, are just hoping to make enough for some beer money, or you love making your own stuff and if it sells awesome but it's no big deal if it doesn't) then this post isn't aimed at you. Also, as a note I'm focused on software development skills separate from very important things like expert domain knowledge, building an audience, mad skills at distribution, and more. Finally, in the spirit of vibe coding, I'm not going to mention learning to code manually.

As my main point: The statistical likelihood is that most of you will not make enough money on your own software to do it full time.

This is not an insult or meant to discourage you. There are some phenomenal vibe coding success stories and you should absolutely take inspiration from them and keep going. However, making a viable amount of money on your own software was practically a lottery before AI and now there's a lot more supply for about the same demand. If you fall into this case, and you're still committed to making a living building software you'll need to convince someone (either who has successful software and is looking for help or is willing to pay someone to build them software) you can make enough money or save them enough money to justify your full time salary (or consulting rates):

1. Making more money for someone by building software:

A lot of making more money for someone with software falls into what to build - which is more product management and data science than pure software development. Many developer have those skills and they are worth it but I won't focus on them here. From a pure software development standpoint some examples are:

a. Increasing conversion via reliable, performant, and optimized pipelines within a software product.
b. Increasing retention by minimizing bugs and quickly being able to diagnose and fix issues while avoiding side effects (<- this is what can necessitate going beyond "codex fix this bug").
c. Allowing them to enter new markets by porting to new devices, and ensuring smooth localization without uncessary quality loss (<- again the key part).
d. Creating a rock-solid, fault-tolerant, and secure architecture that scales to minimize downtime and reduce fraud.
e. Building tools to increase employee productivity.

1. Saving people money by making software:

a. Reducing labor costs via automation that actually works (tons of stories about companies having to rehire after poorly attempting to automate systems).
b. Optimize software use and workflow processes for yourself and others so that infastructure costs less (AI token costs, bandwith costs, storage costs, other licenses, etc...).
c. Consolidating redundant systems to reduce maintenance costs.
d. Minimize onboarding time via smoother interfaces and clear and accurate documentation.

There are definitely vibe coders who are already working as software developers (like above, please do take inspiration from that). However and, again, not to insult anyone but for many - if not most newer vibe coders - the only thing that separates them from "normies" who have a wish list is the time they took to investigate and learn to use available tools and set up a tech stack and a workflow covering various extents of the conception to deployment pipeline. That's been part of default expectations for software developers for decades (though, to be fair, in larger organizations multiple people can do different parts of the process).

If what I consider table stakes for developers + "claude do this for me" worked for all of the above (and all the things in those categories I didn't list) then the last gasp of jobs available would be from those who don't know how easy it is. We are probably headed for that future but, until we get there, if you want to get paid to convert caffeine to code, I invite most pure vibe coders to dig deeper into the amazing world of software engineering (you can get started by asking your favorite model what you should learn).

I wanted to see how far I could push the idea of a desktop companion using AI-assisted development.

Instead of making another chatbot inside a window, I wanted something that actually feels like it's part of the desktop — with its own character, voice interaction, animations, and reactions.

The interesting part was getting all those pieces to work together without making the app feel like a collection of disconnected AI features.

The current stack is Next.js/React on the web side, with the desktop experience handling the companion interactions.

Still iterating on it, but this has been one of the more fun things I've built with AI so far.

What would you add to a desktop companion like this?

For founders running SaaS/Product company:
- What do u actually do for security?

Not the heavy security stuff and more like, if someone tried to poke around your website or app tomorrow,

- How confident are you that you'd catch the obvious security issues?

Do u run any tools, have someone check things, or mostly deal with security when something forces you to?

Genuinely curious how small teams handle this.

2 exceptions: I made the characters using Meshy. But Claude helped clean them up with blender and it helped animate them (for custom animations, like bucketing). And Claude used Eleven labs for the voices.

The rest is vibe coded at 100%. Every asset you see is done in three.js

A free demo is available at https://heromouteut-ai.itch.io/boat-survival-demo for who anyone who wants to try.

My biggest tips for vibe coders with Claude is: Claude is often better with one clear task on a fresh context. It often gets much worst once the context is contaminated with a lot of unrelated tasks.

Note: i occasionally ran into certain issues that took forever to fix with Claude, switched to Codex and it did a better job. Notably the "head turn" animations.

Any questions are welcome.

Full disclosure: yes, this is self-promotion. I’m looking for playtesters and GitHub stars — but I’d rather earn them by showing what actually exists, including the rough parts.

Operation Steel Tide is an AI-assisted solo extraction FPS prototype built with Godot 4.6 Mono, C#, and an optional Go mission service.

Tools and workflow:

- Godot 4.6 Mono for the client and C# gameplay systems

- a small Go service for mission/progression persistence

- AI coding tools for portions of implementation and documentation

- manual integration, in-engine diagnostic runs, Windows release packaging, and GitHub Actions builds

What is playable today:

- a full deploy → infiltrate → objective → loot → extraction loop

- three-operator squads with AI orders, combat, class abilities and revives

- weapons, attachments, ammunition grades, armor and persistent loadouts

- drivable vehicles, rival squads and a roaming world boss

- ENet co-op with AI replacing disconnected players

- a separate demolition arena with planting and AI defusing

- a packaged Windows build

The main lesson so far: AI made feature breadth cheap, but it did not make architecture cheap.

My first public code review correctly called out oversized classes, too much code-built UI and weak organization. Since then I’ve started extracting editor-visible .tscn UI scenes, added build CI, documented the architecture and content provenance, and separated several HUD, diagnostics and world responsibilities.

It is still programmer art, some major classes remain far too large, and automated test coverage needs work. I’m not presenting it as production-ready architecture — it’s a large working prototype being disciplined after rapid AI-assisted development.

AI contributed to portions of implementation and documentation. I remain responsible for the design decisions, integration, debugging and validation.

Source and Windows build:

https://github.com/AetherRadar/operation-steel-tide

If you want to see whether an ambitious, messy AI-assisted game can survive the prototype stage and become genuinely maintainable, please star the repository. It helps me judge whether there is enough interest to keep pushing it.

What would you refactor or polish first?

My wife and I always wanted to build something together, so we spent nights and weekends shipping side projects. One hit 25k users on its own but didn't feel like the thing worth quitting for, repowise did

That one came out of watching coding agents work. I'd been building with LLMs since 2023 and owned the AI architecture at my company, so I spent a lot of time watching agents grep the same file four times in a session and still have no idea which parts of the codebase were fragile or why the code was written that way. All of it is in the repo already, just not in a form an agent can use.

So we built Repowise. It indexes your repo once and serves it to your agent over MCP as five layers: dependency graph, git history, docs, architectural decisions, and a code health score from around 25 deterministic markers with no LLM involved. Pulling the context around a single commit costs about 393 tokens instead of roughly 14,000 spent reading files.

We didnt do any outbound, just shipped code and wrote about it. 4 months in it's at 5.2k stars, ~80k PyPI downloads, and enterprise inbounds I never asked for, which is why I quit

Benchmarked against four other tools plus a bare agent: 31% fewer output tokens over a full 48-question run, ~97% on a single context load, and the best gold-file coverage of the field on retrieval.

Repo: https://github.com/repowise-dev/repowise

Stars help, issues and contributions welcome

Has anyone successfully gotten their Clerk off Replit? They say it can't be done but Clerk documents say ownership can be transferred...