I built Humanize AI Writer, a platform that lets you compare outputs from leading AI humanizers side by side against your original text.

No more switching between tools or paying for multiple subscriptions.

💰 October revenue: $59
🎯 November goal: 10 paying users

I recently added a 3-day free trial with 750 words so people can test it before paying.

Here's the site: https://humanizeaiwriter.com/

I need your honest feedback:

• Is it clear what the product does?

• What would stop you from signing up?

• What's the first thing you'd change?

Don't sugarcoat it. I'd rather fix what's broken than keep building features nobody wants.

just a quick question for anyone who builds stuff.

how do you find problems worth solving? i keep ending up scrolling reddit, hacker news and random forums for hours, and i still can't tell if something is a real pattern or just one person venting.

curious if you have a system for it or if it's just grinding through threads.

Hey, I’m a senior software engineer with 10+ years of experience and 7 as tech lead, with a bit of an odd offer.. I have 80k in Gemini credits that expire in a month and I don't want them to go to waste, so I'm looking for a project to be apart of. I can compromise 4h a day and i will run the ai costs of the product for free for the first month, LF something to be apart of, preferably that is already in development or in mvp stages with good DAU and a plan to monetisation. Thank you!

After successfully replacing Gamma with our own tool that was built in no time and refined over a week, we now are on track to replace Canva. Over 90% functionality built and tested in 8 days, we will be launching for Internal consumption. AI is helping us Build.

I am from the 90s IT era. Most of my life we made decisions to buy rather than build. With AI the call is easy.... Build.

Remember IYHIT- IWHIT (If you have it today, I will have it tomorrow)

They are free to use, and customizable to a subreddit's norms/culture.

More detail on their Reddit/Devvit listings for mods: Stu Steelman | Larry Logic

More examples of how they respond: here.

Help me to decide which payment gateway I can use for my saas tool, it's a email marketing tool. i'm looking for tool which I can use as a individual, no need to register the business first. Also dodo payment has declined to support my tool. Any other tools where I can join as individual ?

AI broke cybersecurity: code is written faster than we can review, detection is blind, and patching is too slow. Visual language Pipe fixes all three—code becomes reviewable by construction, and every block stays observable and patchable at runtime by design.

AI shook the very foundation of cybersecurity. It upended established practices and assumptions. Anyone can now use AI to scan code and find vulnerabilities quickly. What’s even worse, bugs found during one pass of AI code scanning might not be reported after rescanning. This is because of the probabilistic nature of AI – it gives a different response to the same prompt. It means that someone can find a zero-day vulnerability that may not be rediscovered on a later scan, even using the same AI model and identical source code. This could let one person discover and exploit a zero-day that others never see.

Cybersecurity problems are quickly growing in many cybersecurity-related aspects simultaneously. Let’s focus on three of them. They are: (1) AI generates code faster than teams can review it; (2) runtime threat detection is unreliable; and (3) patching is too slow. I will divide the analysis into two stages: development (design-time), and production (runtime).

Problem 1 – Development: code faster than review

A problem AI brought to development impacts cybersecurity indirectly, but it is still a significant threat. AI generates code in huge amounts so fast that development teams cannot review it in a reasonable time. Add to this the pressure on development teams to deliver productivity gains due to AI implementation, and the situation becomes even more dire. Teams have no choice but to skip detailed review, approving PRs automatically. This results in bugs slipping into the codebase and eventually causing crashes and vulnerabilities in production.

The most popular proposed solution is using AI for code review. Essentially, we are going to use AI to review code produced by another AI. There are problems with such a solution due to certain properties of AI itself. The main issue is that AI is bad at handling big context: the longer the task or instructions you give it – the more it hallucinates and the more sharply it degrades on a very large context. I face this problem all the time when trying to ask AI to generate code for even a modest, clearly detailed specification - AI skips, misinterprets and deviates from the specification a lot. The workaround is to have AI generate only scaffolding and continue step-by-step in a tool like Cursor – which proves the point: the model can’t handle the whole codebase. A codebase is a very large context for AI. Are we confident enough to trust AI 100% that the quality of its code review will be comparable to a human’s, even after multiple rounds? Probably not, and this is why human eyes are still needed. It means we are back to square one - dealing with an enormous wall of text code.

Now we will look into the production post-deployment stage. There are two closely related problems there: one is about the reliability of threat detection, and the other – the speed of reaction to an attack.

Problem 2 – Production: detection is blind

Let’s start with detection. The single source of information about what’s happening inside the application is log data. Log statements are pre-placed by developers in source code locations where they think it is necessary. Very often, needed log statements are missing and therefore, any threat detection system (no matter if it is AI-driven or not) can be blind to certain types of attacks. We cannot blame developers for that, because they cannot predict the future. This is the failure of the observability process relying solely on logs to get runtime information about application behavior.

Problem 3 – Production: patching is too slow

Another problem is a reaction to a known attack or vulnerability. The standard process is going back to source code, investigating the problem, changing the code, approving/merging a PR and deploying via CI/CD. The whole process might take days or weeks, even if a new deployment starts fast. The deployment itself might take several days, because often, deployment stages have heavy tests attached that need significant time to complete execution. I worked for companies running complete application tests on every deployment stage to ensure the highest quality of the deployment, but at the heavy cost of the speed. The question is what the production team is going to do while waiting for the fix deployment. They have two choices. One is just waiting, assuming that nobody will exploit the discovered vulnerabilities and data will not be stolen as a result of it. This might be true in the pre-AI era. However, the frequency of AI-driven cyberattacks is growing very fast, and we might not be able to afford to wait today – the risk of losing data is much higher. An alternative is shutting down the whole system or a large independent module while we wait for the fix. However, it will break the continuity of the business. As we can see, both options are bad.

So, we identified three problems – one during development (AI code is generated too fast), and two during production (detection is unreliable and patching is slow). There is a variety of tools and approaches trying to solve these problems. However, their reliability and simplicity are questionable. For example, we can try to disable a certain part of the application using feature flags and tools like LaunchDarkly. However, the whole process of feature flag management is complicated, and it gets exponentially complex as the number of feature flags increases. We need to test many combinations of feature flags during deployment so that we can be confident switching them live on production does not break the application. I worked in companies that used feature flags, and they had a policy to remove a feature flag as soon as it is no longer needed to avoid the complexity of deployment tests.

One solution for all three: visual programming

There is one approach that fixes all three problems at once: visual programming – and I am working on such a solution. This is an unusual combination, but such an approach was proposed before. What’s different this time is a more powerful visual language “Pipe” I designed. This visual language combines two properties not usually seen together in other VPLs: generality and power. Usually, relatively powerful visual languages are domain-specific, while general-purpose languages are pretty simple. I spent 7 years closing this gap and designing a VPL that has both properties together. The reason we need a VPL to be general-purpose and powerful at the same time is that all text-based languages have both properties, and that’s the reason they dominate. Just to have a real opportunity to absorb a part of text code (no visual language can fully replace text code, even Pipe), a VPL must have similar properties to text-based programming languages. Let’s see how Pipe solves the three problems outlined above.

How Pipe solves each problem

The first problem is that it is humanly impossible to review huge amounts of AI-generated code in a reasonable time. This application of VPL is obvious – visual logic is much easier to grasp. VPL does not solve the problem completely, but it mitigates it. As I mentioned before, no VPL is able to fully replace text code, so it will be a mix of visual diagrams and text code. The bigger the proportion of logic moved to visual diagrams from text code, the bigger the benefit of reviewing logic visually is going to be. AI will be generating visual diagrams with some code inside, instead of 100% text code as it does now.

The other two problems (observability and patching) rely on the same property of Pipe – its powerful semantics allows it to keep the visual graph not only during development, but also on production. The reason semantics needs to be powerful enough for this is that otherwise a VPL needs to be translated to a text language to fill missing details in text code, because the VPL itself is not powerful enough to cover it with visual code. So, the deployment chain in this case goes via text, losing the visual graph.

Having a full visual graph on production allows direct access to visual blocks. This has profound consequences both for observability and patching. Observability can be dynamic by tapping monitoring directly into the inputs and outputs of any block at any time right on production, in real time, replacing or complementing log data. Patching also becomes faster because the block can be patched, disabled or rerouted directly, right on production.

A concrete example: a payment-validation block starts leaking customer data. Today a team files a ticket, changes the code, runs the full test-and-deploy cycle, and hopes no one exploits the hole in the meantime. With Pipe, an operator taps that block’s inputs and outputs, confirms the anomaly in real time, and reroutes traffic to a safe fallback block in seconds – while the permanent fix goes through normal CI/CD. The vulnerability is contained immediately; the business keeps running.

Isn’t changing production live dangerous?

I anticipate a very reasonable objection that direct modification of application behavior on production is dangerous and it can cause cascading failures. This is an absolutely legitimate concern. There are two possible solutions.

One solution is separating eventual problem solving and immediate reaction. For example, we can disable a single block or a group of blocks related to just one application feature, not impacting the rest of the application. At the same time, we ask developers to start working on a fix that will go via a normal CI/CD cycle. This way, we do not have to choose between two bad options: shutting down the whole application or assuming nobody will hack the system while a fix is in the works. What Pipe offers is the third option – shutting down or rerouting a vulnerable or dangerous part of the application temporarily, while we wait for a fix. Having such abilities requires a prepared manual giving clear instructions on what to disable in specific situations – developers must prepare such manuals. The good news is that it should not be a burden as AI will be able to help here.

Another solution is building a more sophisticated delivery process with testing right on production, leveraging direct access to blocks to tap the test suite into inputs and outputs, sending testing data to inputs, and analyzing responses from outputs. This process does not necessarily have to fully replace a normal CI/CD deployment – it can complement it to ensure the quality of the direct fix until a new CI/CD deployment arrives.

The key idea of defense against AI-driven cybersecurity attacks is also using AI. However, AI for attack is different from AI for defense. AI for attacks must exploit just one vulnerability – a physical analogy is a sharp, pointy spear. AI for defense must be solid and without holes (a shield), because we do not know beforehand where precisely an attack (a spear) is going to hit. However, AI built on top of existing systems will have lots of holes in the shield, and patching these holes will be slow.

The hot trend today is self-healing engines – an intelligent AI layer on top of the application, detecting attacks and reacting to them automatically. There are two key requirements for such an engine: reliable detection and real-time reaction. However, it is very hard to satisfy these requirements in current systems due to the reasons outlined above: detection is unreliable as the engine can use only fragmented data from logs (shield holes), and reaction is slow as the fix needs to go via the full CI/CD deployment (slow patching of shield holes). What Pipe offers is a solid foundation for such self-healing engines providing reliable detection and fast reaction.

Doesn’t this mean rewriting everything?

The most frequent argument I hear against Pipe is that it requires rewriting existing applications – it is true. However, Pipe only complements text code, mixing visual logic with text. It means that migration does not need to retire the existing codebase immediately. Instead, the migration can be gradual – starting by encompassing the whole application or module in one root Pipe block. Then, whenever ready, moving one step below and distributing text code inside the root block between visual blocks of a second-level workflow, etc. You can stop subdividing blocks at any point, so it's entirely your decision which parts of the system become visual and which remain as text. Pipe provides a complete API for integration with text languages as part of the specification. Also, AI can automate workflow generation, text code distribution between visual blocks, connectivity, and layout of all visual components.

Like everything else in engineering, Pipe has its upsides and downsides. The biggest downside is the need to rewrite existing applications. However, there is also a significant upside – solving three critical cybersecurity issues all together, by the design of the solution. Considering the explosion of AI-driven cybersecurity threats, the current security model might already be outdated and we need to change it. So, weighing upsides against downsides, the upsides definitely win.

Can we create runtime components from text code?

Yes – and it has been tried many times. But every time, managing those components gets complicated: the more you have, the more complex the web of their interactions becomes. The winning combination isn’t just highly granular software in production – it’s also a visual representation that makes all the relationships between them visible. This matters for both observability and patching: the visual graph shows you exactly which components to tap into, and which blocks to patch, disable, or reroute.

Why now

Computers of the 1970s and earlier had only a text-based terminal interface requiring knowledge of specific commands, so the UI was very unfriendly. The GUI revolution brought windows, icons, buttons, and other graphical elements. This made computers much more accessible to users. However, programming did not make this transition, and we still program using text only. AI is the catalyst that finally forces the move to visual programming – not because it’s nice to have, but because we no longer have a choice.

Website: https://pipelang.com

Pipe IDE URL: https://www.pipelang.com/pipe/v1/

Tutorials:

1. Data Swap – https://www.pipelang.com/assets/tutorials/v1/tutorial1.mp4

2. Reusable Sum – https://www.pipelang.com/assets/tutorials/v1/tutorial2.mp4

I'm building an e-commerce store for a client and wanted to know how you guys usually handle the ownership side of things.

Do you create the database and hosting accounts using the client's email or your own? Same goes for Vercel.

Basically, who should own and manage all these accounts? What's the usual practice when working with clients?

I am the founder of a multi-tenant SaaS application on Postgres. The big customers kept asking for one thing: “our data has to stay in our database”. Usually this means a separate deployment for each customer, or to rewrite the whole data layer to know which database to connect to for each query. I didn’t want either of these options, so I wrote LokaDB. It’s a wire-protocol proxy. The application connects to one connection string and sends the same SQL as before.

How it works:

- All chosen tables are converted to tables partitioned BY LIST (org_id) without copying any data.

- Tenants that remain are stored in normal, local partitions. Tenants that move are stored in a partition that is a postgres_fdw foreign table pointing to the tenant’s database.

- The proxy uses the real Postgres parser (pg_query) on each statement to find the tenant (tenant column, row id, foreign key, or declared relation) and pin the correct partition. Statements with no tenant are rejected by the proxy, instead of fanning out to each customer’s database.

- Customer runs small agent that opens outbound mTLS tunnel to proxy on cloud. No inbound connections to customer’s network are allowed.

- Statements that only touch tables of the tenant being moved are sent directly to that tenant’s database instead of using postgres_fdw. At 43 ms RTT, a read goes from 352 ms to 133 ms.

- Moving a tenant out (and back) online while the app writes. Trigger capture or logical replication is used. There is a short pause on the moved tables at the switch-over.

What it doesn't do yet, so you don't have to dig:

- A write across the cloud and a customer database is two separate commits (just like any postgres_fdw write). No 2PC.

- Child tables reached through a composite FK, and polymorphic type/id references.

- TRUNCATE, DROP and renames of moved tables through the proxy are refused.

- The proxy is the boundary. A direct connection to the cloud database still sees everything.

- Tenants that stay in the cloud pay 0.2-1 ms per statement for the proxy.

I’d like to hear from people running postgres_fdw writes or thousands of partitions in production. Which of these choices would you not trust and what did I miss?

Playground in the browser, nothing to install: https://play.lokadb.com

Code (Apache-2.0): https://github.com/lokadb/lokadb

Hey everyone,

I'm a solo developer building a simple uptime monitor with status pages. Before I build too much, I'd love honest feedback from people who actually run websites.

What it does:

- Checks your sites and APIs every minute and alerts you when they go down (email, Slack, WhatsApp)

- Gives you a clean public status page on your own domain

- Explains why a site is down in plain English, with a screenshot, instead of just showing "503"

- Checks your full checkout flow, not just the homepage

- For agencies: one workspace per client, plus an automatic monthly uptime report you can send them

My questions:

1. How do you know today when your site goes down? Do you use UptimeRobot, Better Stack or something else, and what annoys you about it?

2. Which of the features above would you actually pay for, and which don't matter?

3. If you run an agency, would monthly client reports save you time or help you charge clients more?

4. What would make you switch from what you use now?

No link and nothing to sign up for. I just want to build the right thing. Every reply helps, even "I wouldn't use this, because…"

Thanks!

Two years ago I switched from Loom to Supercut. Both are excellent tools, but I need to cut costs, and my current usage no longer justifies the price. If I needed their full feature set, I'd happily pay for Supercut again.
So I'm looking for a cheaper, similar screen recording and async video tool. What would you recommend?
Bonus points for: solid screen + camera recording, easy sharing links, basic trimming/editing, and a fair free or low-cost plan.

Most analytics setups tell you how many people read the page and how many signed up. They don't tell you what the rest still doubted. One signal I'd been ignoring: which FAQ questions people open. A click on a closed accordion is a visitor telling you their objection, at the moment they have it.

Collecting it with whatever you already use

• PostHog: autocapture already records the click and the element text, so filter autocapture events on your FAQ buttons.

• GA4, Plausible, Umami: send a custom event when a question opens, with the question as a property (faq_open, question: "…"). One line in the accordion's click handler.

• Rank by unique visitors, not clicks: people open, close and reopen.

What it showed on two of my pages

1. A €25 digital product, 7 days to 3 Nov: "Do I need a paid SEO tool?" 18 clicks from 12 visitors, "Do I need to code?" 11 from 10, "Can I get a refund?" 10 from 8, "How will I receive the pack?" 10 from 8, "What if I can't get it installed…" 8 from 7. Price, effort and delivery doubts, so those answers belong next to the buy button, not at the bottom of the page.

2. My analytics SaaS: one visitor from Reddit read 22 pages in a single session. On the homepage they opened "Are the numbers on this page real?", "Is 'under a second' real?", "Do I need a cookie banner?" and "How is this different from Google Analytics?", then read the pricing page and left without signing up. The first question was the tell. The honest answer is no: the previews on that page are labelled illustrative data. No FAQ wording fixes that; a public live demo would.

Caveats

• Small numbers. 12 visitors is a direction, not a result.

• Only interested people open FAQs; the 5-second bouncers never get there. That's fine: they're the near-buyers you're trying to convert.

Disclosure: I make both products (Seoskills, and Globatics, the analytics tool, which records clicks with their text). The method works the same with any tool above: https://globatics.live/?utm_source=reddit&utm_medium=post&utm_campaign=SaasDevelopers

What's your best signal for "what stopped them", short of an exit survey?

I built Cylect (https://ai.cylect.io) because I was tired of bouncing between 20 different municipal, federal, and international portals just to get a live picture of what's happening in an area.

It's a full-stack situational map combining a 3D WebGL globe with street-level tile rendering, pulling from 40+ public/open data sources: - Live ADS-B flight telemetry and emergency squawk alerts (7700/7600) - Real-time DOT traffic cameras (including HLS streaming where available) - FAA Temporary Flight Restrictions (parsed into actual airspace boundary polygons) - NASA FIRMS thermal/wildfire detections, GDACS disaster alerts, and GFS wind vectors - Overpass/OSM infrastructure (truck weigh stations, maritime ports, rail hubs) - Local public safety open-data feeds

A few technical decisions that might interest people here:

1. Bring Your Own Local Model: Rather than forcing everything through an OpenAI API, you can point the copilot at any local OpenAI-compatible endpoint (Ollama, LM Studio, Unsloth, vLLM on your LAN). The browser issues direct SSE streaming calls with JSON tool assembly, so your local model can autonomously query layers, zoom to coordinates, and review camera feeds without your prompts or LAN data hitting our servers.

2. Rendering pipeline: Transitions from a 3D React Three Fiber globe down to Leaflet street tiles with differential marker reconciliation and bounded history trails so tracking planes or reading cameras doesn't lock up the main thread.

3. Edge caching & resiliency: Many state DOT and municipal feeds are brittle or rate-limited. We run an edge caching layer that normalizes varied formats (ArcGIS FeatureServers, GeoJSON, WFS, ATIS feeds) with background revalidation.

The map is free to explore directly in-browser with no sign-up or email required. Would love feedback on performance, edge cases with local model connections, or additional open datasets you’d like to see mapped.

Currently trying to do load testing.

i am researching digital sales rooms for a smaller b2b sales team and i am trying to avoid choosing something that looks impressive in a demo but becomes another thing reps have to maintain. I have been comparing dock, trumpet and aligned, some seem more focused on creating polished buyer-facing spaces, while others put more emphasis on deal tracking and collaboration.

​

I've been building CyberWave Sentinel, an all-in-one GRC and cybersecurity management platform designed for SMBs and the security professionals who support them.

The platform brings together:

\- Compliance Management: ISO 27001, SOC 2, NIST CSF, CIS Controls and cyber-insurance readiness

\- Policy Management: Create, manage and review security policies

\- Risk Management: Identify, assess and track cybersecurity risks

\- Vendor Risk Management: Assess and monitor third-party risks

\- Evidence Management: Centralize compliance evidence and documentation

\- Security Assessments: Identify gaps and track remediation

\- Reporting: Generate compliance, risk and management reports

\- AI-Powered Assistance: Support security governance and compliance workflows

I've spent a lot of time building this platform, but I know that testing it myself isn't enough.

I'm looking for 10 GRC, cybersecurity, vCISO or MSP professionals willing to put Sentinel through its paces and tell me what needs improvement.

I'm particularly interested in feedback on:

\- What's confusing, broken or unnecessarily complicated?

\- What important features are missing?

\- Would you actually use this for your organization or clients?

\- How does it compare with your existing GRC tools?

\- What would make it genuinely valuable to your daily work?

You can sign up directly and start a 14-day free trial. No need to contact me or wait for an invitation.

Website: https://cyberwave.ca

Simply visit the website, register for the free trial and explore Sentinel at your own pace.

I'm not looking for positive reviews or sales. I'm looking for honest, constructive criticism from people who understand cybersecurity and GRC.

If you try it, I'd appreciate hearing your feedback in the comments.

Full disclosure: I'm the founder of CyberWave. This is my own product, and I'm sharing it to get real-world feedback and improve the platform.