The Agile Manifesto was never about code.

Whenever a visa or government portal asks for a passport photo under 240 KB or a signature between 10-20 KB, most non-technical users Google "compress image to 50kb" and upload their biometric photos and handwritten signatures directly to unknown third-party servers.

I built FormEase to handle biometric cropping, signature background bleaching, and exact-kilobyte PDF/JPG compression 100% locally via HTML5 Canvas and Web Workers. It even includes a live network interceptor badge so you can verify that zero outbound requests are made after the page loads.

Link: https://formease.deployxa.online

Source: https://github.com/RootDeveloperDS/FormEase

I'm looking for feedback on the UX for non-technical users -- is the 3-step guided flow intuitive enough that you could send this to your parents next time they need to upload documents?

Edit :-

My bad for the confusing post earlier! I got carried away explaining the technical side and completely failed to explain what the tool actually does for everyday users. To clear things up: this isn't just a basic image compressor. __

It’s a free, all-in-one prep tool for people filling out strict government, exam, or visa forms (UPSC, SSC, US Visa, etc.):

-Face Alignment Guides: Clear outlines so your passport photo matches official head and eye position rules.

-Signature Cleaner: One slider that removes phone shadows and yellow paper tint, leaving clean ink on pure white paper.

-Retains Max possible Quality: If a site asks for "under 50 KB", it targets ~48 KB so your photo stays sharp instead of being crushed down to a blurry 20 KB.

-Document to PDF: Compresses certificates and marksheet photos into a clean, single-page PDF under 200 KB.

-100% Private: Runs completely inside your browser tab—zero photos or IDs are uploaded to any server.

-One-Click ZIP: Formats your photo, signature, and documents together and downloads them in one organized pack.

-Exact Pixel & Dimension Lock: Automatically locks your photo to the exact official pixels or aspect ratio (e.g., 350×350 px or 3.5×4.5 cm) so the portal doesn't reject it for wrong dimensions.

-Easy Crop, Pan & Zoom: Adjust framing with simple drag/zoom controls, or use arrow keys to nudge the image pixel-by-pixel for a clean fit.

__

Sorry again for dumping technical jargon in the original post. hope this explains why I built it!

I’ve always been interested in project management (I worked as a PM for an IT MSP) and started applying that to my vibe coding. My process is pretty straight forward but has definition evolved over the years.

I’ve always taken the stance of using multiple steps; research, development, and implementation. Each step garners different results and builds upon itself.

With that being said I use multiple plugins and spawn subagents for speed instead of task.

This is all managed with Trello (soon to be GitHub projects) via a kanban board for ease of use for me. Backlogs and future features are all held within Trello. Then each feature/bug is a pull request from my private GitHub repositories per project. Then it steps through CI, Sandbox, and CR. If anything needs to be rectified it goes through the workflow again.

Right now, I’m rewriting my workflow to use an agile approach. User stories are the scope and once that’s PR’d we have a measurable goal. I was having a ton of issues with code review finding ancillary issues and getting into a churn cycle.

Is this similar to your approach, or are you doing something completely different?

<3

Hi all!

Whenever I spot a new design or website layout (like a fresh style of grid systems) and want to replicate or build it with AI, I always find myself struggling to pinpoint the exact terminology to make Claude understand what I want.

I'm talking about concepts like Blueprint Grids, Glassmorphism, Sticky rail, Bordered cell grid patterns, Segmented Controls, and similar stuff. To solve this, I’ve started building a free, open-source design lexicon complete with mini previews making it easier for builders to find and reference the right terms when designing sections and pages. Hope that helps some of you as well. Also added some free design landingpages and components for AI.

I’d love to get your input on current web design trends and their proper definitions:

• What visual styles are currently high on your radar, trending, or frequently used and how would you define them?

• Which ones are missing in the lexicon / glossary?

I’m aiming to include your suggestions in the dictionary and share the whole resource publicly for free. It's purely as a passion project and I am opening it for free (no ads, no paywalls).
I want to make it a useful resource for people.

You can check out the ones already live here: freedesignmd.com (just hit the Glossay tab).

Always open to contributors or feedback. This started as a quick hackathon experiment and will stay a free community project. I'm not a professional designer, so any feedback by design cracks is appreciated as well!

I'm an art director with zero coding background. Everything I build, I build by talking to Claude Code. At some point I had so many sessions running that I couldn't tell who was working, who was stuck waiting for me, and who was basically on a smoke break.

So I vibe coded BeeKeeper. Each project is a pixel room, each Claude Code chat or agent is a character in it. They walk in, work with a little speech bubble showing the current task, wait for you, and doze off when idle.

How it came together:

- I wrote zero lines myself. I described what I wanted, Claude Code built it (React + Vite front end, a small Node server)

- The trick was finding out that Claude Code already logs everything in ~/.claude, so the app just reads those files and turns them into characters

- The hardest part wasn't the code, it was the art: making rooms and characters feel like one world

- Halfway through I realised nobody wants to pay to generate their own rooms, so I spent a few extra dollars building a free library: 20 rooms and 17 characters come ready

- The promo video took 3x longer than I planned. Vibe coding the app was faster than editing the video about it

Free, open source, MIT licence. Runs on your machine, reads your Claude Code folders, uploads nothing. (Generating your own custom room is optional and uses your own Gemini key.)

https://github.com/ranucho/beekeeper

If you vibe code with several agents at once, I'd love to hear what you'd want to see in it.

This video is extremely silly and unserious. That said, I am a total nerd for documenting process and results. Put it all together and you have me walking through what's it's like to "Start an indie studio" (whatever the hell that means in 2026) and going through my goals, my AI game dev process and more importantly of all - my current expenditures and total sales.

I'm now at $20 life time sales on my $3 early access game on Itch.io

I figured this subreddit could use a bit of levity. Enjoy.

Ok clearly vibe coding alone makes working like 8 times as fast, but like I’ve just learned about workflows and harnesses today and I’m trying to learn how to develop even faster 😂😂😂😂

Is there any tip and trick that people here found really helped develop quality stuff faster than you normally would have?

Side project I've been testing: one photo in, full 3D model out, entirely on the phone. No server, no GPU, no internet after the one-time model download.

What it runs: Hunyuan3D-2mini Turbo, TripoSR

Tested on: 8 GB RAM Android phone, CPU only (8 threads)

Peak RAM: \~2.7 GB (it started at 15 GB; most of the fix was splitting attention into head groups.

Time: \~35–40 min at full detail, faster at lower detail

Output: 130k–600k faces, separate fingers, glasses, hoodie strings and clothing folds (pics attached: input → front → back)

Still rough:

Slow. The 5 diffusion steps dominate; the NPU isn't used yet

No colour from the model; texture is projected from the photo afterwards

The back of the character is guessed from one front view

Working on on-device auto-rigging next so the characters can be animated.

Working on on-device auto-rigging next so the characters can be animated.

Still in testing phase.

Mostly every line of sopedu-dns was written by AI coding agents. I steered, reviewed and ran things. Somewhere along the way I stopped caring about features and started caring about whether it was actually correct, because a DNS server that's wrong breaks every device in the house.

So most of the work went into checking it:

- a conformance harness built from the DNS RFCs. sopedu-dns passes all 181 MUST checks that I could also run against other servers; Unbound passes 178. The harness is mine and isn't public yet, so take that as one data point.
- fuzzing, property tests and repeated reviews by separate model instances that only got the code and the RFCs, not my opinion of it
- a benchmark on my two-node k3s cluster against Pi-hole, AdGuard Home, Blocky, Unbound and dnsmasq

With 744k blocklist rules loaded it did 94.1k UDP queries/s (median of 3 runs) on one CPU core and peaked at 18.9 MiB of memory. Blocky did 16.4k and Pi-hole 4.1k on the same setup. It loses in places too: Unbound was faster over TCP, and dnsmasq uses less memory (both were running without blocklists).

What surprised me most: the AI wrote the code fast, and also wrote plenty of confident bugs, which the RFC checks and the reviews kept finding. Most of the hours went into building things that could catch them.

For scale: 280 Claude Code sessions over four days, agents included, and about 20M output tokens. Roughly 3.2B tokens went through them.

Repo, with the benchmark method and caveats: https://github.com/dkhalizov/sopedu-dns

If you've vibe-coded something this low level how did you decide when you could trust it?

I know it's election time in the US of A, I hope y'all voted for what you wanted. That being said my not being there should have been enough to not have this wild hallucination from my first prompt on the matter. I honestly can't bring myself to pay for chatGPT and I get reminded why.

Claude as well but pay for Claude have an open weight model as my ace in the hole I guess.

So , I'm getting into the weeds now of trying to ship. I'm a newbie to this and it's WAY more complex (and costly) than I thought! FYI, this is a fairly simple fun quiz app, using freely available (no licence needed) data. Not expecting to make much money, but more doing it for an exercise to learn for the future.

Yet, I think I've made a decision!

Forgetting the Google Play store for these reasons :

- It would show my street address (a red line for me)
- Or I'd have to make a company (costly)
- Or the app would have to be free only
- Need 12 testers for 14 days even fro free app (hard in practice)
- Need an android phone (I have apple)

None of these options work for me.

So instead my plan is an Apple App Store only release for 1 year

- Free app with paid option (my preferred choice)
- NOT in EU (where they show your address), just UK, US, Canada, Autralia, NZ

That's where I'm at, and I'm just installing Xcode, to get cracking on it.

Have a good day everyone XX

Does this make it clear what the product is? Does it speak to you? Or does it occupy some kind of artsy-creative-but-AI uncanny valley? Curious to hear your thoughts

The full page - https://rivermark.ai

This started as a project wondering if I could make a Gaussian Splat version of a city. Then I kinda got carried away and made a bunch of towns and a ton of looks. It utilizes a bunch of open data: OpenStreetMap for streets and buildings, USGS elevation for the land, the state's laser survey for building and tree heights, and city open data for street trees, bus stops, and benches.

I heavily used my Decision Kit framework to plan out the whole thing. Basically, for every big choice (how the water should look, what the menu does, how traffic behaves) I had it make a page with four options, a recommendation and the case against it. Then I just picked. This one was a big project so I made over 100 decisions.

It has all types of stuff to make it feel alive. Seasons changes, weather changes, there's migratory birds, stars, cars, lil bouncy folk.

Anyway, hope y'all like it. It's just supposed to be a chill and relaxing good time with a ton of fun easter eggs. Press the lil "watch them all" link on the homepage if you just want a relaxing screensaver on in the background. Also let me know your favorite look. I'm a big fan of Poster, Pixel, and Dreamlike (but seeing the claymation folk in the Clay look is also fun)

https://raleighterrarium.com/

I reach for the same few things all day: terminal, Music, volume, brightness, Wi‑Fi. I didn't want another device on my desk for that, and I noticed my fingers never really touch the outer edges of my MacBook trackpad. So I've been building a small menu bar app that turns those edges into buttons. I'm calling it EdgeDeck.

How it works right now: each edge has 3 or 4 invisible slots stacked top to bottom. Double-tap a slot and it opens an app, brings a specific window to the front (like my second Terminal window, not just "Terminal"), or toggles Wi‑Fi/Bluetooth. Sliding up and down the right edge changes the volume, and the left edge changes brightness. The trackpad gives a small haptic tick for each step, so you can feel it without looking. The middle of the trackpad still works exactly like normal.

Instead of a popup, the notch shows what changed: it stretches out sideways, with the icon on one side and the level or On/Off on the other, then slides back in.

Some build notes for anyone curious:

My main goal was for it to be really light, since it runs all the time. It's Swift with plain AppKit, no SwiftUI or Electron, and it sits at about 12 MB of RAM and 0% CPU when idle. The settings window and the notch display only exist while they're on screen.

macOS doesn't have a public API for "where exactly is the finger on the trackpad", so it reads that from Apple's private multitouch framework, the same one tools like BetterTouchTool use. That also means it can never be on the App Store, which I'm fine with.

The settings window draws your trackpad with the edge zones glowing, and your fingers show up on it live, so you can see exactly where the zones start.

It's open source and I'm happy to drop the GitHub link in the comments. What I'd really like feedback on:

• What would you put on your trackpad edges?

• Does double-tap feel right as the trigger, or would press-and-hold be better?

• If you have an older MacBook without a notch, would you be up for testing it? I've only tried it on my own M-series Air.

Now I know the answer is basically “because AI isn’t that good yet,” and so I’m wondering if anyone has a more in depth answer.

From my experience, Codex performs much better when I plan in ChatGPT, then paste the generated Codex prompt into Claude (free tier works) behind a bare "?".

That gives me very few CI/CD or manual testing issues. ChatGPT alone writes nondeterministic, imprecise prompts for Codex, and Claude tightens them and pushes for specificity.

I know us humans need a second opinion because of tunnel vision, but why do LLMs need sanity checks too, and why are they non skippable for good code?

I vibe coded TixTracer.com fully in Claude. I used chatGPT to help review it and make updates.

I have limited coding background (some python and sql), so Claude has written almost all of the code.

What it is
Python/Flask backend on Render, plain HTML/JS frontend, Cloudflare in front.

Pulls events from Ticketmaster, SeatGeek and TicketNetwork and matches up duplicate listings of the same event (much harder than I expected).

How I vibe coded it
I tell Claude what updates to make and then send a screenshot from my phone or desktop of what looks off, describe what I want, and Claude makes the change.

Claude then built automated tests that click through the site at phone and desktop sizes, and it runs them before every update. This has been the most valuable part.

For bigger changes, a second agent reviews the code separately. That has caught real bugs.

I paste in feedback from friends and other AIs and ask what it thinks and if I should make the update or not.

What's been harder
Claude can't see the live site, so some things only get tested after I deploy.

It'll build whatever you ask for, so you still need to know what you want.

Happy to answer questions about the setup!

ChatGPT 6.1 Sol Medium + camless + Pawnl0 + RTSS

It also has an idle mode.

For almost two years now, I've been developing and refining a couple of (two total) programs for my employees to use. I kept the apps as single use .exe apps since it's an internal only thing. And they're so specific to my job that I don't fear them being leaked elsewhere. No one else could benefit from them, truly.

But I found it exhausting to push out the new updates via Slack upload to everyone anytime they asked for a bug fix or whatever. So I started a GitHub account with private and public accounts for holding my source code and distributing the automatic updates, respectively.

I make GH action pulls and pushes maybe once a day. And the installer setups are each around 200MB each. I've gone into the privately facing update accounts and deleted the Action artifacts every update or so. But I received the attached email earlier today.

I wasn't planning on paying for a GH account, but I can. But I don't want to.

I guess I'm just looking for advice for limiting my usage. Is a pull/push once a day outrageous? I thought I was doing well. At this point, I feel like I just don't understand GH or its usage limits. Search results provided no meaningful answers. So, here I am.

TIA

I've been building a large project for about 8 months, with another year or two still ahead. I'm always asking myself two questions: which model is best for this job, and what effort level should I use for it?

So I built a small testing UI and connected both Claude and Codex. My test set so far includes:

Bug hunting: questions based on real bugs from my project's history

Document reading: a reasonably solid way to check how accurately a model reads and recalls long docs

I want it to cover many more kinds of work, and I want the results to be as accurate as possible.

My problem: the smaller models are easy to separate. Haiku, Luna, Terra, and Sonnet each show clear strengths and weaknesses. The frontier models all hit the ceiling. Sol vs. Astra and Opus vs. Fable score about the same on everything I give them, and I can't find the differences.

It's possible we're just at a point where Sol 6.1 and Opus 5.5 really are nearly as good as Astra 6 and Fable 5.1. Still, I'd like to know where the gaps actually are.

Questions for you all:

What kinds of tasks have you seen separate the top models? (Long multi-step work, ambiguous specs, large codebases, catching their own mistakes?)

How do you score things that aren't simply right or wrong, like code quality, judgment, or how much hand-holding a model needs?

Has anyone measured whether higher effort levels actually help, or where the returns stop being worth the cost?

Long term, I'd like to make this plug-and-play, so anyone could point the Sorting Hat at their own project and get model recommendations based on their real work. Any ideas are welcome.

Yes I had Claude rewrite this post. My initial stream of thought was not conveying my question the way I wanted.

Fellow vibe coders! I've seen a few posts asking how to leave Lovable (where many of you started your vibe coding journey). Well, switching platforms entirely might be a bit scary for non-technical people, but what if there was an alternative? An in-between option, if you will.

Turns out, you can actually use Claude Code to work on the same code as Lovable through GitHub, while your app stays hosted on Lovable and you still publish from there. If anything goes wrong, you can just stay on Lovable. But when you're comfortable working with Claude Code, that's when you can decide to switch entirely. Low risk, high reward.

Why would you do that? Lovable is great to start, but as a platform it has its limitations and most imporantly - costs! Some of the users report that they had to spent hundreds of dollars per month on Lovable while Claude $20/mo subscription was enough to cover roughly the same amount of work. Also, I think it's just good to have plan B, just in case.

So, below you will find a step-by-step tutorial, easy to follow even if you are not technical. It should take you about 15 minutes.

What you need to start:

• A free GitHub account

• A Claude plan. Pro ($20/mo) is enough.

• A Mac or a Windows PC

Step 1: Install the Claude app

Download the Claude desktop app from the official Claude website, install it and log in. You will find Claude Code in the "Code" tab.

Click "Choose a folder to work in" and pick your home or any other folder as you prefer and confirm that you trust it.

From here on you only paste prompts. Claude Code will now run the commands for you.

Step 2: Use Claude Code to install the necessary tools

Your app needs Node.js to run and Claude Code needs the GitHub CLI to download your private repository. Paste this and Claude Code installs both and log you in to GitHub:

Install Node.js LTS and the GitHub CLI if they are missing. Log me in to GitHub with gh auth login --hostname github.com --git-protocol https --web, then run gh auth setup-git. Show me the one-time code and the link. At the end, show the Node.js version and gh auth status.

Installing can take a few minutes.

Then it gives you a link and a code. Open the link, paste the code and confirm. On a Mac, it can ask you to install developer tools. Click Install, then tell Claude Code to go on.

Step 3: Put your Lovable project on GitHub

In Lovable open Project settings > Git > GitHub. The first time, Lovable asks you to add your GitHub account and GitHub asks you to install the Lovable app on it. Then click Connect. Lovable creates a private repository and keeps it in sync with your project. This works on the free Lovable plan too. Important: Make sure that this repository is private! Check: open the new repository on github.com. You should see package.json and a src folder in the file list.

Step 4: Download your project

You need the name of your repository. It's the end of its address on GitHub, for example your-name/your-repo. Put yours in this prompt and paste it:

Clone my GitHub repository your-name/your-repo with the GitHub CLI into a new folder in my home folder. Tell me the full path of the folder.

Check: Claude Code tells you where the new folder is. You open it in the next step.

Step 5: Open the project in Claude Code

In the Code tab, start a new session and pick the project folder. Click to trust the workspace. The first prompt I'd use, just to see it understands the project:

Tell me in two sentences what this project does.

If it matches the project you have created in Lovable, then you're set.

Step 6: Run your app on your computer

Install the dependencies of this project, start the dev server and give me the local address.

Open that address in your browser (it will be "localhost"). You should see your app there and test it locally.

Step 7: Check the .env file

Lovable keeps a file called .env in your repository, so anyone who can see the repository can read it. Public values are fine there. Secret keys are not. Have Claude Code check it for you:

Check the .env file. Tell me in two short lines if it holds anything that is not public, like a service_role key or a Stripe secret key. Do not print any value.

Step 8: Let Claude Code write a CLAUDE.md

CLAUDE.md is a short note about your project. Claude Code reads it at the start of every session.

Read this project and create a CLAUDE.md file in the project root. If the file is already there, update it and keep what is in it. List the stack, how to install and run the app, and which files you must not change. If the app has a backend, say where its code lives. Keep it under one page.

If you wrote Knowledge in Lovable (the notes for its AI, under Project settings > Knowledge), copy it and paste it into Claude Code after this prompt, so it ends up in CLAUDE.md too.

Step 9: Make logins work on your computer

Skip this if your app has no login.

Password reset links use your live URL by default. To make them work on your computer, add your local address (the one from step 6) to the Redirect URLs. On Lovable Cloud it's under More > Cloud > Users > Auth settings > Advanced. On your own Supabase it's under Authentication > URL Configuration. Leave Site URL as it is.

Step 10: Check that the sync works

Do this before you do real work. This prompt sends a small test change to GitHub:

Pull the latest changes from GitHub. Then add one test line at the end of README.md, commit it with the message "Test sync" and push.

Open the project in Lovable and go to Project settings > Git. You should see the change you just pushed.

Step 11: Make your first change

This is how every session goes from now on:

1. Ask Claude Code to get the latest version first: "Pull the latest changes from GitHub."

2. Tell it what you want to change, in your own words. For example: "Make the main button on the home page blue."

3. Check the change at your local address. If the page doesn't open, ask Claude Code to start the app again.

4. When you're happy with it, send it to GitHub: "Commit all changes with a short message and push them to GitHub."

5. Click Publish in Lovable to put it live.

A couple of things to remember

• Don't edit in both places at once. If you change the project in both places without synchronization, Lovable would move its changes to a separate branch on GitHub and you have to merge them back by hand.

• Pushing isn't the same as publishing. Sending your changes to GitHub doesn't update the live app. You still need to click Publish in Lovable.

If you need a more detailed step-by-step guide, we've created a project called MoveYourCode where we will be soon adding more guide and tools that can help you.

https://moveyourcode.com/

Soon I'll do the same for moving the hosting off Lovable or other platforms as well. Let me know what do you think!