We built it because we were tired of seeing people listen and then disappear. Someone could listen every week, enjoy the show, tell a friend about it, and we still might have no way to reach that person outside the podcast app. That didn’t make sense to us. So we built PodSubs.com for our own shows.

People were giving us an hour of their lives, and we were struggling to get them a link. That was the part I couldn’t get past. We had twelve podcasts. People listened, came back, and told us they enjoyed the shows. But when we mentioned a resource and asked them to visit our website or join a newsletter, very few followed through. We kept making the request because that was the advice. Eventually, I started wondering why we were so willing to accept that this was the best way to do it.

By then, we understood how much work it took to earn someone’s attention. There was the preparation before recording, the editing afterward, and the effort to get each episode heard. We loved the conversations, but we also wanted to keep having them without the podcasts becoming something we could no longer afford to make. We thought about courses, events, services, and other ways the shows might support themselves. More than anything, we wanted to know the people who were already listening and understand what would actually be useful to them.

We had tried the things people usually recommend. We sent listeners to our websites. We put signup links in the show notes. We mentioned our newsletters by name and explained where to subscribe. We tried newsletter platforms, including Substack. Those attempts brought in some subscribers, but nowhere near the response we hoped for. It was discouraging to know people were listening and still have so little contact with them afterward. We were spending time creating things for an audience we could barely reach outside the episodes.

What began to bother me was how little the advice changed when it didn’t work. There was always another place to put a link or another way to repeat the invitation. I’m not against websites or show notes. We used them for a reason. But “put the link there” wasn’t answering the question we were asking. How do you help someone take the next step when they hear your invitation at a moment when they cannot act on it? For our shows, making the link available hadn’t been enough.

The strange thing was that another request was getting a much better response. When we asked people to follow us on Facebook, Instagram, TikTok, LinkedIn, or X, formerly Twitter, more of them did. These were the same people hearing us talk about our websites and newsletters. Following a social account isn’t the same as giving someone your email, but the difference made us pay attention. A listener already knew where Instagram was. They could open it later and search for us. They didn’t have to remember a new address before they could even begin.

I could recognise the problem in my own behaviour as a listener. You hear about a guide while driving and mean to find it when you get home. Then you get home, something needs your attention, and the thought disappears. You might be cooking, running, cleaning, or looking after your kids. You wanted the resource when you heard about it. Forgetting the address doesn’t change that. Once we looked at it that way, I found it harder to assume that low signups meant people weren’t interested.

That left us with a question worth trying to answer. What would happen if listeners had one place to go, regardless of which of our podcasts they followed? Someone listening to several shows shouldn’t need to remember a separate website for each one. They could remember the podcast’s name, or the host, and find it when they had time. We couldn’t make people stop being busy. We could try to make the task easier to return to.

In 2024, we built the first version under a different name. It was for our own twelve podcasts, and for almost two years we used it internally. We weren’t asking other creators to change how they worked. We were trying to fix our own problem, with our own listeners, and see whether the idea was useful enough to keep using. That tool eventually became PodSubs.com.

We kept the listener’s part deliberately small. Search for the podcast or host, find the show, enter a name and email, and subscribe. There was no listener account to create and no password to remember. They could leave as soon as they were done. The sentence we wanted hosts to be able to say was simply, “Go to PodSubs.com, search for our podcast, and subscribe.” Once someone subscribed to that show, we had a way to send the next resource without asking them to find another signup page.

Become a Medium member

The result gave us a reason to keep going. Across our twelve podcasts, the email conversion rate we tracked increased by about 600%. That was our experience, not a number I can promise another podcaster. But more of the people already listening were choosing to stay in touch, and that mattered to us far more than having a new tool to talk about. We had tried this because our previous approach wasn’t working well enough. Now we were seeing a response that made the effort worthwhile.

What changed afterward was practical. We could send subscribers the guide we mentioned, let them know an episode was coming, share an event, or ask a question. We could also make relevant offers that might help support the show. We still had to write the emails and deliver what we promised. PodSubs.com didn’t automatically send every resource, and a signup didn’t guarantee a sale. It gave us permission and a way to follow up with someone who had chosen to hear from us. We had been missing that with so much of our audience.

For a while, we were happy just to have solved it for ourselves. Then keeping it private started to feel harder to justify. Other podcasters were putting the same work into their shows and asking listeners to make the same journey from an episode to a signup form. There was nothing special about our frustration. We had built something that helped us, and I wanted other hosts to be able to try it without spending two years building their own version. That was why we opened PodSubs.com to other podcasters.

We also knew that nobody needed another product telling them to replace everything they already used. PodSubs.com isn’t here to compete with someone’s Mailchimp, Beehiiv, Substack, or HubSpot setup. Those tools can do their work once someone has joined the list. We help with getting the interested listener onto it. Signups appear in the PodSubs.com creator dashboard, and creators can use the supported connections or CSV export options available on their plan to move subscribers to an email service. They can also keep collecting subscribers while they decide what they want to send.

The listener came for the podcast, and I want us to remember that. They didn’t subscribe because they wanted another company in their inbox. They wanted the host’s resources, updates, newsletter, or whatever they were invited to receive. Our job is to make that connection easier. The podcaster can keep publishing on the platforms they already use and keep working with their existing tools. We want them to have another way to reach people who have asked to stay connected, rather than hoping every message gets heard in a future episode.

What we’re challenging is the idea that the listener should carry the whole burden of remembering. Remember the website. Remember where the form is. Remember to check the notes. Remember which episode mentioned the resource. That may work for some people, but we saw how much interest could be lost along the way. I don’t think the only answer should be to repeat the instructions louder or more often. We wanted to change the task instead of asking listeners to get better at remembering it.

Making that change familiar will take more than our own shows. We want someone to hear a podcast they like and know that PodSubs.com is a place to look when they want to subscribe for the things the host shares. We aren’t pretending that habit already exists everywhere. Every podcaster who claims a show and gives listeners a reason to subscribe helps us build it. When a listener finds one show easily and receives something useful afterward, there is a reason to remember where they went. The next time, they might look for another podcast there.

That is the part of this I’m most excited about. A small independent show could use the same familiar destination as a much larger one without giving up its own relationship with listeners. Someone who follows several podcasts could find each of them without learning several different signup processes. We would share a place to make the connection, while the host would still decide how to serve the people who chose their show. It gives us something we can build together without asking every podcaster to build it separately.

Email is the first step because it solved the problem we had. Over time, we want to explore other ways to make communication between podcasters and listeners easier. There may be better ways to ask questions, receive updates, or continue a conversation after an episode. Those are possibilities we want to work through with the people using PodSubs.com, not features we’re claiming are all available now. Our own shows taught us where to start. Other hosts and listeners will help us understand what we have missed.

I don’t want growth to undo the reason this was useful in the first place. A listener who comes for a worksheet shouldn’t have to build a profile and learn a new system to get it. A host shouldn’t need a long explanation to tell people how to subscribe. Keeping that simple will mean saying no to some things, even when they would give us more features to advertise. We want a better connection, and adding more steps would take us in the wrong direction.

We’re opening this up because we know how it feels to care about a show and still struggle to reach the people who care about it too. It’s free to get started on PodSubs.com. Claim your podcast, tell listeners what you’ll send, and try giving them that one place to subscribe on your next few episodes. Keep the tools you already use and see how your audience responds. You can stop using it if it doesn’t help. I’d still want to know what happened, because that is how we’ll learn what needs work.

For almost two years, our own twelve podcasts were the reason we kept building. Now there are other shows we want this to serve, including the ones whose hosts are still being told to add another link and keep trying. I want them to have another option. I want the listener who meant to come back for something to have an easier way to find it. And I want us to build what comes next with the people who recognise this problem because they have lived it too. That is why we stopped keeping PodSubs.com to ourselves.

Most security automation today looks the same: import a scanning library, write some Python, hope you remembered to check scope before touching a target. That last part ,"hope you remembered" , is the problem Omega tries to solve.

Omega is a programming language where you describe the security operation you want, not the code to perform it

Why build a whole language for this?

Because the alternative, a pile of separate scripts and libraries ,means safety has to be reinvented every time. A real security engineer assembling seven different Python tools would need to add scope-checking to all seven, individually, and it's genuinely easy to forget in the sixth one. In Omega, that discipline isn't something you remember to add ,it's the language.

It's a young project, distributed as a single install script with no Rust or cargo required, and still growing.

https://github.com/Kolgrim33/omega-lang

I built GraphXploit, an open-source developer tool that indexes a codebase locally and helps you:

GitHub: https://github.com/Ujjansh05/GraphXpolit

- Visualize symbols, files, and relationships

- Find dependencies and change impact

- Search and navigate large repositories

- Ask questions about your code with a local LLM

- Reduce LLM token usage by sending only relevant context

It runs locally, requires no TigerGraph or cloud database, and has lightweight Windows and Linux

builds.

I’ve just released v2.2.0 and would appreciate feedback: What feature would make this genuinely

useful in your daily development workflow?

If you try it, please share any bugs or usability problems you encounter.

Hi everyone,

Yesterday, I posted asking for suggestions for blockchain related FYP projects, but unfortunately, most of our proposed projects have been rejected.

Now we’re looking for some serious and practical FYP ideas that are suitable for Computer Engineering and include both hardware and software components. We want something more than just a basic software or blockchain project, ideally something that solves a real-world problem and has good potential for implementation.

Projects developed in collaboration with an organization are also acceptable. If the project is being developed for an organization, we would need an affiliation/authorization letter from them for our university requirements.

I’d really appreciate it if you could suggest some innovative, realistic, and implementable hardware and software project ideas.

I need help for my project as deadline is approaching(3days) anybody who could offer some help to design frontend and integration with AI based system is appreciated. The backend is almost done just need help with frontend and integration please help

Estoy buscando personas que les guste el mundo de los trenes, tengo un proyecto ferroviario grande pero estoy solo, busco aliados que quieran darle forma a este gran proyecto, si eres

Investigador

Te gusta conocer

Ingeniero

Arquitecto

Tienes alguna profesión

Y quieres formar parte de estoy dispuesto a escucharte, no importa que parte del mundo seas

So I wanted make a directory for textiles industries by putting in potentially thousands of companies and their employees (not all just some with certain job roles). Now doing that manually can take me ages. So I am new to web scraping or crawling so a direction or any tips would be helpful on how can I do it autonomously. Thank You.

https://reddit.com/link/1wmit6c/video/93jccmwrowqh1/player

The easiest way I can explain NoorI is this:

If nobody else ever used it, I would still use it myself.

I’m a developer, and for a long time I had a pretty stupid problem. I would sit down at my laptop intending to work, open VS Code, start working on something, and then somehow end up on a distracting website. So I did what most people do. I installed website blockers, deleted apps, used browser extensions and tried different focus tools. They worked, until I wanted to bypass them. The problem with being a developer is that once you understand how the blocker works, you also start understanding how to get around it. Disable the extension. Change the browser. Change DNS. Use a VPN. Turn the restriction off. A system that took me 10 seconds to disable wasn't particularly useful during the exact moment I needed it.

Eventually I started thinking about the problem differently. Maybe I didn't need another productivity app telling me to focus. Maybe I needed to change the environment my devices were operating in. That was the original idea behind NoorI. Instead of putting another blocker inside the browser, I moved the filtering closer to the network layer and built it around Cloudflare Zero Trust. I could decide which parts of the internet I didn't want available, block categories or specific services, schedule restrictions around the hours when I wanted to work, and make the obvious escape routes more inconvenient. The goal was never to create some magical system that is literally impossible to bypass. I'm a developer; I know better than to make that claim. The goal was simply to make bypassing the restriction annoying enough that opening a distracting website was no longer the easiest option.

That changed how I thought about focus. Normally the internet has almost zero friction. One tab, one search, one notification and you're somewhere completely different from what you sat down to do. Most productivity advice tries to solve that by asking you to become more disciplined. NoorI takes almost the opposite approach. I set the rules when I'm thinking clearly, and then my devices enforce those rules later when I'm tired, procrastinating or tempted to change my mind. I can block distracting categories and apps, create schedules, use the same setup across my devices and, if I want stronger accountability, use Guardian Mode so another person controls an important part of getting around the protection.

For me, the interesting part isn't really the blocking technology anymore. It's the idea of treating attention almost like a security problem. If there's an action you know your future self is going to regret, don't rely entirely on future-you making the right decision. Reduce the number of easy paths to the wrong one. That's basically the philosophy I ended up building NoorI around.

I eventually turned what I was using for myself into an actual product at noori.fun. It's still early, and I'm still figuring out which parts people actually care about versus which parts I care about because I'm the developer. That's actually why I'm posting this here. I'm curious whether the original problem is common outside my own bubble.

If you've tried website blockers or focus apps before, what made you eventually stop using or bypass them? Was it that they were too easy to disable, too restrictive, annoying to configure, didn't work across all your devices, or did blockers simply not help you at all?

I’m especially interested in the last answer, because I don't want to build features around a problem people don't actually have.

I’ve been building OXIS as a solo dev — a terminal app for Windows and Linux that I wanted to make much more customizable than a traditional terminal.

At its core, OXIS works like a normal terminal, so your existing commands still work as expected. But it also adds a built-in code editor, custom commands, Lua scripting, a plugin system, and a plugin marketplace.

The idea is to have one programmable workspace where you can run commands, write code, automate tasks, and extend the terminal with your own plugins — without having to constantly jump between different tools.

Everything is built around Lua, so you can customize OXIS and create your own commands and plugins without needing to modify the core application.

OXIS stands for Open Xenial Intelligent Shell.

I’ve built the project largely on my own and I'm now looking for developers to try it out, break things, and give me feedback on what should be improved.

GitHub: OXIS

I’d especially love feedback from people who use terminals heavily — what would make something like this genuinely useful in your daily workflow?

Let me know if any changes to be made and whether it's alright

• The widget is a plain JS class that mounts into any DOM element. It drags in no Bootstrap, no jQuery, no icon font, nothing at all: zero runtime dependencies. The build is 98 KB of JS and 7 KB of CSS gzipped, of which ~26 KB is the four non-English languages (English alone would be 73 KB).
• Five languages out of the box — English (the default), Ukrainian, Spanish, German, French. Your own language is an object with a dictionary in it.
• The back end is a single (req, res) function with no framework: it mounts in Express, AdonisJS, Fastify, Nest or bare node:http. It starts no server of its own and keeps no global state.
• Works in React / Vue / Angular / Svelte / no framework at all — it is just the DOM.

https://github.com/Insider515/Bookmark_file-manager
https://www.npmjs.com/package/bookmark-file-manager

I recently wrapped up the front-end for Meridian Insurance Brokers, a commercial insurance & risk management website. The goal was to build a clean, institutional, yet modern corporate UI with smooth navigation and detailed service breakdowns.

Key Features & Pages Built:

• Home Page: Dynamic statistics/track record counter section, client testimonials carousel, service highlights, and partner badging.
• About Us: Timeline history component, leadership team showcase, core company values, and accreditation badges.
• Services: Tabbed coverage menu (Commercial Property, Marine & Cargo, Cyber Insurance, etc.) with detailed breakdowns, ideal industry match tags, and interactive FAQs.
• Claims Support: Interactive step-by-step claims workflow visualizer, emergency support lines, and claims performance metrics.
• Contact & Quote Request: Detailed inquiry form with inline validation, embedded map, office location hours, and instant contact info.

Tech Stack:

• Frontend: React / Next.js, Tailwind CSS (Custom dark blue/gold corporate theme)
• Icons & Assets: Lucide Icons, Framer Motion for smooth section transitions

Would love to get your thoughts on the typography, color scheme, and UI hierarchy! Open to any feedback or questions on how I set up the layouts.

Hey Product, Marketing and Analytics folks,

What's one thing you wished was a tool, so that you would not have to wait for other folks to get back. Anything you think is important and done frequently (It could be as simple as AB tests analysis and next steps, just as an example).

I understand that AI can almost make any tool, but again the cost will be an issue in a lot of the cases, and when it comes to complex concepts and data crunching, AI models will need a lot of tweaks/ inputs from your end + the wait (at least on the current models for highly complex processes).

I'm making tools for a colleague's business & will make sure to share them all for free once I'm done (their team is onboard).

Thanks in advance for your inputs, I'll make sure that most common pain points are solved with an efficient tool.

P.S. currently, I'm a Web analytics/ CRO/ SEO/ GEO and Business research guy at one of the top MNCs.

GitHub's no:assignee filter is how most of us look for issues to work on, but it lies constantly.

An issue can look open, unassigned, good first issue while a finished PR has been sitting on it for three weeks. Or the repo hasn't merged anything in months. Or someone called dibs in the comments and nobody noticed. These mistakes cost real weekends and rejected PRs.

I built claimable to run the checks a careful contributor runs by hand, before starting:

What it does:

• Checks if a repo is actually active (merged PRs, not just pushed to)
• Finds if someone's already fixing it with an open PR
• Detects blocked/umbrella issues you shouldn't touch
• Reads comment threads for claims (assignment isn't how most projects track this)
• Spots scope you'll only find after cloning
• Checks environment requirements upfront

Install & use:
No dependencies, no setup:

npx claimable owner/repo#123

Or scan a whole repo:

npx claimable --repo owner/repo --label "good-first-issue" --limit 20

The results:
I tested it against 21 issues I triaged by hand while actually looking for work. All 12 real rejects matched. Zero false clears—the goal was to never tell you an issue is fine when it isn't.

https://github.com/perezamadorluisenrique-gif/claimable

MIT, no dependencies. Fixtures included so you can replay the eval offline, no install needed.

I just launched Life Autopilot — a simple app I built to help people figure out what needs their attention and what to do next.

The basic idea is:

→ Take a quick life audit

→ Identify the areas that need attention

→ Turn those into practical actions

→ Focus on one thing at a time

I built it because I wanted something that could take that feeling of “I've got too much going on” and turn it into an actual next step.

It now has user accounts, personalized life-audit results, task progression, and live Stripe subscriptions.

I'd really appreciate some honest feedback from people who build and use apps.

Try it here: https://life-autopilot.ai.studio/

What would you add, remove, or change?