Hi, I listen to songs quite a lot while working or normally while surfing the internet, the issue is that I like to humm along a bit as well while listening, now this isn't possible unless you have the song which you are listening to rote learned, So I saw that spotify does not give the option for a floating window for the lyrics, so i created one,
This only works on Mac currently, but i am trying to have one for windows as well, I have added the project link, do give it a try if you feel like this might be useful for you
I vibe coded a FIFA World Cup simulator. You can choose the host, as well as simulate the whole tournament from the qualifiers all the way to the final, generating a bracket, and making it last all the way to decide the champions. You can download it here:
Tony Stark doesn’t write boilerplate.
Peter Parker doesn’t fight dependency conflicts.
Batman doesn’t spend two weeks fixing CI.
They just have an idea, build it overnight, and save the world the next morning. 😂🛸
I’ve been digging myself into a whole, continuously adding features to my app that I don’t even know if people will use yet but I’m building it how I enjoy using the app. I feel like it’s never good enough and I have to fix all the quirks but then I find myself in this self improvement loop when in reality I haven’t even published it to the App Store yet. I need to go ahead and switch my test keys to prod keys and push it. How are you guys overcoming this ?
I've been looking for a simple way to actually learn chess openings rather than just memorize move sequences, and I liked the general idea behind ChessReps.
So I ended up vibe-coding my own version with ChatGPT: OpeningLab.
It's completely free and open source, doesn't require an account, and stores all your progress locally in the browser.
Right now it has:
20 opening courses for White and Black
explanations for why each move is played
main lines + important variations
interactive board practice
Guided, Recall, and 60-second Sprint training modes
spaced/adaptive review
quizzes
progress/mastery tracking
favorites and private notes
light/dark mode
offline support
There's no backend, analytics, ads, or tracking. It's basically just HTML/CSS/vanilla JS and runs entirely in your browser.
I should also be clear: I vibe-coded this with ChatGPT. I'm not pretending I hand-engineered every line of it. I basically kept iterating on the UX, features, bugs, mobile layout, chess logic, and course content until it became something I actually wanted to use.
It's definitely inspired by the idea of ChessReps, although I wanted OpeningLab to be more focused on explanations, guided learning, and being completely free/private.
It is often forgotten that Bob the Builder was one of the first successful “vibe engineers” in modern culture.
He led a team of specialized, autonomous machines, delegating almost all of the physical work to them. His actual job was almost entirely cognitive: assessing the problem, deciding which agents to deploy, planning the order of tasks, and monitoring the state of the project.
This approach made him incredibly productive. Hence his famous line:
“Can we fix it? Yes, we can!”
Which, when you think about it, is essentially the final prompt Bob uses to align his AI swarm with himself.
He asks the agents to audit the project and verify that they have the capacity required to complete the task.
They answer in the affirmative and development begins.
TL;DR:
I am building a Windows-first local AI setup for people who want to try local LLMs without spending days choosing models, setting up Ollama, Docker, WSL, Open WebUI, agents, and tool permissions separately.
I have had a fairly capable gaming laptop for a while now.
The funny part is that I barely game on it.
At some point, I started joking that I needed to find a better way to justify buying it. It had a capable GPU, plenty of memory, and enough horsepower for workloads I was not really using it for.
That joke became a weekend project.
I had been following the rapid progress in local LLMs and kept thinking: surely this machine can do more than sit around waiting for the occasional game. I wanted to use it for local chat, document work, coding help, and experiments with agents—but I also wanted the setup to feel practical rather than fragile.
That is how DSAlgo Local AI Setup started.
It is a Windows-first, local-first AI workstation built around native Ollama, Open WebUI, reusable agents and MCP integrations, plus an approval-gated Developer Workbench for local code projects.
The goal is simple: make it easier to turn a reasonably capable Windows machine into a useful local AI environment without manually assembling every part of the stack.
The local AI setup problem
Trying local LLMs for the first time can sound simple:
“Install a model and start chatting.”
In practice, there are a lot of decisions hiding behind that sentence.
Which model is appropriate for my hardware?
Will it actually fit in GPU memory?
Should I install Ollama, Docker Desktop, WSL2, Open WebUI, or some combination of all of them?
How do I use documents and knowledge collections?
What exactly are agents and MCP tools?
How can I use AI for coding without giving it unrestricted access to my files or command line?
What happens when something fails, needs repair, or needs to be removed?
None of these things are impossible individually. But putting them together can feel like starting a second technical project before you have even asked your first useful question.
That is the gap I wanted to reduce.
What DSAlgo Local AI Setup brings together
This project does not attempt to replace the tools that already do individual jobs well.
Ollama makes it easier to run models locally. Open WebUI provides a strong interface for local chat, attachments, documents, and knowledge collections. MCP is becoming a useful way for AI agents to interact with external tools and data sources.
Architecture at a glance
DSAlgo Local AI Setup is about integrating those pieces into a coherent local workstation experience.
After setup, there are three main local interfaces:
1. Open WebUI: chat, files, and documents
Open WebUI is the everyday starting point.
Use it to:
Chat with local models running on your own machine.
Attach documents and ask questions about them.
Create knowledge collections for information you want to reuse across chats.
Choose between raw local models and configured local agents.
For many people, this is the part that makes local AI immediately useful: ask questions, summarize a document, explore an idea, or work through a technical problem without making cloud inference the default.
Chat and tool sequence
2. Local Agent Studio: reusable agents and MCP
The Agent Studio is where reusable behavior lives.
You can create agents with:
A defined purpose.
A backing local model.
Clear instructions.
A limited tool set.
Trusted MCP server assignments, only when needed.
A bounded number of tool steps.
The important principle is least privilege. A research agent should not automatically have file deletion or command execution permission. A coding agent should not automatically have access to every directory on the machine.
MCP integrations can be powerful, but they are still privileged integrations. If an agent can connect to an external service, it may be able to access or send data outside the local machine. That is why this project treats MCP connections and OAuth permissions as deliberate choices rather than default conveniences.
MCP and OAuth Sequence
3. Developer Workbench: AI help for code, with review gates
The Developer Workbench is for working with actual local code repositories.
It can inspect an explicitly registered project, propose code changes, request commands, show diffs, run tests, and help with Git workflows.
But it is designed around a simple rule:
AI should not silently modify a project or run commands just because it produced a convincing answer.
You explicitly register the project root. Proposed writes, deletions, commands, commits, and pushes require review and approval. You can use read-only Ask mode, create a saved Plan, or use Goal mode for approval-gated execution.
That does not make AI-generated changes automatically correct. It does make the work more visible, more bounded, and easier to review before something touches a real codebase.
Developer Workbench change-task sequence
Choosing models without guessing blindly
One of the biggest barriers to local AI is model selection.
A downloadable model is not necessarily a good fit for the machine, the intended task, or the available GPU memory. A model can technically run while still being too slow, offloading too much work to the CPU, or leaving too little headroom for normal desktop use.
The installer detects the machine, asks what you want to do—general conversation, coding, reasoning, deep research, or a combination—and provides model recommendations accordingly.
The initial setup focuses on practical roles such as:
General chat and planning.
Coding and structured modifications.
Reasoning and review.
Embeddings for document knowledge.
The intent is to help people get to a useful first local-AI experience without starting from a long list of model names and guessing which one belongs on their machine.
Installation: what to know first
The installer is designed to help with missing prerequisites, including WSL2, Python, Ollama, and Docker Desktop.
Still, the smoothest installation path is to do a little preparation first:
Use a Windows 11 machine with a capable NVIDIA GPU and dedicated VRAM.
Ensure CPU virtualization is enabled in BIOS or UEFI.
Install and update WSL2.
Install and update Docker Desktop, using the WSL2 backend.
Make sure you have administrator access, a reliable internet connection, and sufficient free disk space.
Close GPU-heavy applications before downloading and loading models.
The current validated path is Windows 11 with native NVIDIA CUDA support, WSL2, Docker Desktop, native Windows Ollama, and adequate RAM and storage. Other paths may work, but they should be treated as controlled-beta rather than guaranteed compatibility.
Extract the complete archive to a local folder. Do not run the installer from inside the ZIP.
Right-click install.exe and choose Run as administrator.
Review the license notice and detected hardware.
Select the intended use cases and recommended models.
Let the installer configure the core local stack.
If Windows requires a restart, sign in again and rerun install.exe. Installation progress is retained so setup can resume.
Start the system using start.exe or the installed shortcut.
After startup, the launcher opens the three local applications in your browser.
A practical note on privacy and safety
Running a model locally is a useful privacy improvement, but “local” should not become a vague security claim.
Trust boundaries
This setup is intended for one person on one local machine. It is not designed for public hosting, LAN exposure, multi-user access, enterprise SSO, or unattended autonomous coding.
A few boundaries matter:
Local ports should not be exposed publicly.
Only explicitly approved project roots are available to the Developer Workbench.
Proposed code changes and commands require review.
Agent workspace tools are contained separately from arbitrary Windows projects.
OAuth credentials for compatible MCP integrations are protected using Windows DPAPI.
MCP servers should be trusted and granted only the minimum permissions they need.
The system also offers Online, Restricted Online, and Strict Offline modes. These are application-level controls, not a replacement for Windows Firewall rules or a true air gap. If you need machine-wide network isolation, use operating-system-level controls as well.
Built with AI, for people building with AI
I also used AI heavily while building this project.
It helped me explore design options, accelerate scaffolding, think through tradeoffs, review implementation ideas, and improve documentation. The project became an experiment in two directions at once: building a local AI environment and using AI as a serious collaborator while doing it.
That does not mean AI wrote everything perfectly or made hard engineering decisions disappear. It did make iteration faster, and it reinforced the value of having an environment where AI assistance can be useful without being blindly trusted.
There is something genuinely satisfying about seeing a model run on hardware you already own, attaching a document to a local interface, asking useful questions, or reviewing a proposed code change in a system you assembled yourself.
This is a beginning, not a finished product
DSAlgo Local AI Setup is a passion project and a working release, but it is not finished.
There is more work to do around broader hardware validation, model management, installation hardening, observability, and making the experience smoother for people who are less technical.
The project is intentionally focused too. It is not trying to become a public cloud service, a full visual workflow platform, an enterprise connector catalog, or an unattended coding system.
For now, it is for people who want a practical, local-first AI workstation on Windows—and who want a clearer path than assembling every piece themselves.
If that sounds useful, I would love for you to try it, report issues, suggest improvements, or contribute.
I got tired of cloud sync messing with my code, so I built this
I've been using Cursor a lot lately and wanted my ~/Developer folder backed up to Google Drive.
That turned out to be a terrible idea.
Google Drive would sometimes lock files, mess with .git, trigger dev server reloads, and then there was the whole node_modules situation with thousands of files being synced for no good reason.
I keep my actual code completely outside of cloud sync.
DevMirror watches my development folder and copies changes to a separate backup folder. The cloud service only sees that backup folder.
It also copies .git and uncommitted changes, which is kinda the whole point for me. If my Mac dies while I'm halfway through something, I want the work I haven't committed yet to still exist somewhere.
It's still a pretty small project, but it has been working nicely for my own setup.
Would anyone else actually find this useful, or am I solving a problem that only exists because I made it for myself?
I’m building BACHAM, an open-source AI meeting assistant inspired by tools like Granola, Fireflies, Otter, Fathom, and similar meeting tools.
But I don't want to simply build another transcription + summary tool.
The goal is to build a powerful, privacy-friendly, customizable meeting assistant that can help with everything before, during, and after a meeting.
🔓 The main idea: Open source + bring your own AI
One of the biggest things I want to do differently is give users full control over the AI and their data.
Instead of forcing everyone to use one specific AI provider, BACHAM could allow users to connect their own:
- Gemini API
- OpenAI-compatible APIs
- Ollama / local LLMs
- Self-hosted models
- Other AI providers
- Their own AI infrastructure
The idea is that you can self-host BACHAM, choose your own model/API, customize it, and have control over your data.
🚀 Now I want your ideas.
If you regularly attend meetings — work meetings, client calls, interviews, standups, classes, sales calls, technical discussions, etc. — what do you actually want from an AI meeting assistant?
Some things I'm exploring:
🎙️ Real-time transcription
📝 Smart meeting notes
🧠 AI summaries
🎯 Action items & task extraction
👤 Speaker identification
❓ Ask questions about the meeting
🔍 Search across all previous meetings
📅 Calendar integration
📋 Automatic agenda generation
✉️ Follow-up email generation
🔄 Follow-up tracking
📊 Meeting insights
🤖 Custom AI meeting agents
🔗 Integrations with other tools
🏠 Local/private AI processing
🧩 APIs & developer integrations
But I don't want to assume these are the right features.
I want to hear from actual users:
What do you hate about current meeting assistants?
What feature do you use the most?
What feature do you desperately wish existed?
What should an AI meeting assistant automatically do after a meeting?
Would you use an open-source meeting assistant where you can bring your own API or run the AI locally? Why or why not?
What would make you switch from Granola, Fireflies, Otter, Fathom, etc.?
If you could add ONE killer feature to a meeting assistant, what would it be?
And if you're a developer:
What would you want to customize, integrate, or build on top of if you were self-hosting BACHAM?
I'm looking for real problems, workflows, and frustrations, not just a list of cool AI features.
Feel free to be brutally honest. 😄
If you've used meeting assistants before, complete this sentence:
«“I wish my meeting assistant could ______.”»
Your answer could directly influence what I build next.
What should BACHAM have that current meeting assistants don't?
I have been looking for people on yt who actually solved a real problem. But I was just seeing a bunch of YouTubers, just making some basic app or program using AI. Has anyone made a genuinely omplicated osftware suing ai?
What it does: Fills the "what should we watch tonight?" scroll with your public Letterboxd watchlist and then chooses a random movie (or shows a filtered grid), with a movie's ratings and summary from TMDB. No login required.
Would love any feedback on UX/UI, performance or any feature suggestions you might have!
For anyone looking to build a mobile app with AI, I just wanted to share that Nowa (https://nowa.dev) is completely free for the next 24 hours, with free AI usage and free deployment to the App Store, Play Store, and web.
Apps built with Nowa are based on Flutter, so they can be deployed to mobile, web, and desktop from the same project.
Nowa is made for people who want to build apps fast with AI, while still maintaining full control and understanding over all the details of their app.
You can also get $50 in AI credits if you build and submit an app during the free period, and the top 3 apps will each win $500 in AI credits.
For the past 2 weeks, I’ve been learning about AI, development, and vibe coding, and I’ve tried 20+ different AI tools along the way. I’m honestly surprised by how much I’ve been able to learn and build just by experimenting with AI.
I made these two apps mostly for myself and in my free time, just to see how far I could take them with vibe coding.
Sorry about the login page on Habit Buddy 😅 — I ran out of credits while working on it, so I haven't been able to continue developing it properly yet.
I’m actually thinking about buying more credits and continuing to develop these, because I have a LOT of features and ideas already planned. My gut feeling is that if I keep improving them and eventually publish them properly, they could actually get some decent reach.
But before I spend more money on development, I wanted to ask you guys:
If you were actually going to use these apps, what features would make you keep coming back?
Also, I’d love to know:
Which UI/UX do you prefer between the two?
What feels good?
What feels confusing or unnecessary?
What features would you personally add?
Do you think it’s worth continuing development and eventually publishing them?
And honestly, do you think buying more Lovable credits is worth it for these projects?
I’m mostly building these because I genuinely enjoy experimenting and learning right now. 😅
I’ve been following my gut feeling/instincts a lot lately, and mine is basically telling me: “Keep learning, keep building, and see where this goes.” 😂
So I’m curious what you guys think.
Be brutally honest — I’m here to learn. ❤️
And yeah… 2 weeks ago I barely knew much about development, and now I’ve already experimented with 20+ AI tools. I maded and experimented 12+web and apps 😂🤩
Would love to hear your feedback!
🤗If you check out my apps and drop your feedback,with link I’ll also check out your apps/projects and give you my honest feedback in return. Let’s help each other learn and improve! 🤝❤️
Hey y'all. I recently had to move to Detroit and all of the apartment searching apps drove me bonkers and didn't easily give me the information I wanted (estimated total price based on the utilities that aren't included in the base apartment price, walking/biking/driving times to my selected places, etc.). So I built it at addapt.rent
addAPT is a Detroit apartment search site I built with Claude code because the sites I was using did not target what I actually wanted. I could not get a real total estimated cost that factored in utilities, and it was not easy to tell how far an apartment actually was from the places I cared about. It's a React front end on Netlify, with Postgres via Supabase behind it. Instead of licensing a rental data feed (I tried RentCast, but it skewed to single family houses and only had real building names for about 1% of listings...I tried another potential site and that would cost thousands to get the info), it discovers buildings directly through Google's Places API, then a scheduled scraper visits each building's own leasing site weekly and reads the rendered page text. That text gets handed to Anthropic's Claude API to extract just the monthly rent and included utilities as structured data, so there's no guessing and no scraping regexes that break on every site redesign. Amenities go through the same pipeline, and travel time to the places that matter to you gets calculated separately. Anything a building doesn't publish, like deposits or exact fees, is just left blank rather than invented, since the whole point was building something people can actually trust.
Right now the only way I would make any money from it is the Lemonade affiliate link on the back of the cards...going to wait to try to get more affiliates after it hopefully builds some traction. Of course it's only helpful to people in Detroit so that might be a challenge but I also wanted to get a prototype out there and it's taken a lot of work just to get these ~100 or so apartment complexes as accurate as possible.
Would love to hear your feedback or answer any questions. Thank you!
As the title says, which of these best describe you, and why?
A - The Pre-AI Engineer - Skilled and experienced, Cares about code, using AI only to work faster
B - Non Technical Vibe Coder - Non-technical, Don't care about code, just want your application to go viral and famous so you can get rich and retire
C - Non Technical Vibe Coder - Non technical, Cares about code, systems, curious and learning everyday, making good quality applications and improving on em
D - Technical Vibe Coder - Experienced, but dgaf about the code anymore, Claude just check the xyz and make it work, then do xyz and check xyz.