u/Dinanath_Dash

I need to vent and warn others about Rapoo’s atrocious warranty replacement process, specifically at their third-party centers. The Timeline & Facts:

• The Device: Rapoo E9050L (White/Silver).
• The Issue: The on/off switch became loose after 9 months of use, requiring effort to actuate and losing its tactile click.
• April 18: Submitted the keyboard to the authorized third-party service center in Bhubaneswar. Was told it would be replaced under warranty. The Replacements:

1. Attempt 1 (10 days later): They tried to hand me an E9050L, but it was the Mumbai Indians (MI) branded edition. My setup is strictly minimalist. I did not buy a sports-branded peripheral. I refused it.
2. Attempt 2: They agreed to replace it again. This time they brought out an entirely different model—the E9050G—which has an altered layout and highlighted blue icons. Refused again.

The Customer Service Response: When I contacted their representatives to ask why I wasn't informed about the stock shortage before I surrendered my device, and why they thought sending random models was acceptable, their verbatim response was:

"Sir, this is just a keyboard and only buttons are changed, what's the big deal?"

The big deal is that I paid for a specific aesthetic and model. If a company does not have the exact replacement, standard practice is to communicate the stock issue, not quietly shove leftover promotional stock or entirely different models at the customer and expect them to just accept it.

I've been traveling back and forth to this center for weeks just to be handed the wrong hardware. Has anyone else dealt with Rapoo's RMA process in India? How do I escalate this past the local center to someone who actually understands consumer rights and basic customer service?

Do you have the direct contact details for the regional service head, or have you only been dealing with the front desk staff at the local center?

I’m building a dev-tool Micro SaaS called Envault. It's a secret management platform to stop .env file chaos and fix the "alert fatigue" problem caused by context-blind security scanners.

To make it as secure as possible, I engineered it with a True Client-Side Encryption (CSE) model.

• It has a Go CLI that handles the AES-256-GCM encryption locally on the developer's machine.
• The Next.js/Supabase backend acts purely as a zero-knowledge store. It only ever sees ciphertexts.
• I even built an MCP server to strictly fence AI agents (like Cursor/Claude) with Human-In-The-Loop approvals so they can't blindly mutate environment variables.

The architecture is solid, and the problem is real. But here is the massive wall I'm hitting, and I want to know how other Micro SaaS founders in B2B handle this:

How do you build trust when you are small?

Selling a marketing tool or a generic productivity app is one thing. But selling a security infrastructure tool as a solo developer/small team is incredibly hard. Enterprise companies want SOC2 and massive corporate backing before they hand over their credentials.

For those of you building dev tools or security-adjacent Micro SaaS products:

1. How did you acquire your first 10 B2B users?
2. How do you overcome the objection of "you're too small for us to trust"? Did you just target other indie hackers first?

(If you want to see how I positioned the security architecture to try and combat this, my link is in my bio, or I can drop it in the comments. Would love any brutal feedback on the landing page messaging).

Hey everyone,

I’m wrapping up my final year engineering project and wanted to share what I've been building.

While researching automated secret scanning, I noticed a massive problem with alert fatigue. Most industry security tools are completely context-blind; they flag everything, and developers end up ignoring the alerts, which eventually leads to real credentials leaking into GitHub or Slack.

Instead of just building another scanner, I decided to build the actual infrastructure to prevent the leak in the first place. It’s called Envault. It's a secret management platform designed around a strict True Client-Side Encryption (CSE) model so that .env files never touch a hard drive in plaintext.

The Architecture:

• The CLI: Written in Go (zero dependencies). When you run envault pull, the Node API sends the unwrapped Data Encryption Key and the AES-256-GCM ciphertext to the CLI. The decryption happens entirely in your local memory.
• The Backend: Next.js and Supabase. The server acts as a zero-knowledge store and only ever sees ciphertexts.
• The AI Fencing: I built an MCP server (Model Context Protocol) so you can give local AI agents like Claude Desktop or Cursor access to your environment. But to prevent the AI from mutating things blindly, it issues a delegated, short-lived JWT that forces a Human-In-The-Loop (HITL) approval in the terminal before any secrets are modified.

The Ask: I’m currently testing the CI/CD headless execution flows (using read-only service tokens to inject variables into process memory) and the CLI developer experience.

If anyone is dealing with .env file chaos across their team or wants a safer way to let AI agents interact with their environment variables, I would love some brutal, technical feedback on the implementation.

Envault