DEV Community: beatsprom

Your Product Has 30 Features and 0 Paying Users. Here's the Clinical Reason.

beatsprom — Thu, 14 May 2026 11:21:13 +0000

You have a to-do app with Kanban boards, calendar sync, recurring tasks, dark mode, team collaboration, CSV export, and an API.

Nobody uses it.

You already know the next step: add AI summarization.

This isn't engineering. This is a clinical pattern. And it has a name.

The Pattern: Feature Stack as Protection

Here's what you're actually doing.

Every feature you add before getting 10 paying users serves one function: it makes your product harder to evaluate. A product that does "one thing" can be judged in 5 seconds. A product that does "everything" is too complex to dismiss quickly.

That complexity is not a business advantage. It's a psychological shield.

Your brain figured this out before you did. A clear, focused product invites a clear, binary verdict: useful or useless. Your nervous system registers that binary verdict as a survival threat. So it avoids the verdict entirely by making the product impossible to judge simply.

This is not laziness. This is not perfectionism. This is your threat-detection system operating exactly as designed.

The Mechanism: Why Your Brain Prefers 30 Features Over 3

Neuroscience research on ambiguity tolerance shows a consistent finding: when humans face situations with unclear outcomes, the amygdala activates in patterns similar to physical threat detection.

Launching a focused product creates maximum ambiguity. Will people pay? Will they ignore it? Will they publicly criticize it? Your brain treats all three scenarios as the same category: unpredictable social evaluation.

Adding features is your brain's solution. Not your business strategy. Your brain's strategy.

Each feature accomplishes three things simultaneously:

1. It delays the evaluation moment. "I'll launch after the API is ready." Then after the mobile app. Then after integrations. The launch date moves at exactly the same speed as your feature velocity.

2. It creates plausible deniability. If the product fails after 30 features, you can blame market timing, competition, or distribution. If a 1-feature MVP fails, there's nowhere to hide. It was your idea. And it wasn't good enough.

3. It generates safe dopamine. Closing a Jira ticket activates the same reward circuit as actual market validation. Your brain can't distinguish between "I shipped a feature" and "I shipped a product." It marks both as completed goals. You feel productive. You feel progress. You feel safe. You are none of those things.

The Test: 3 Questions

Answer honestly.

Question 1: How many of your features were requested by a paying user? Not a friend who said "that would be cool." A person who paid money and then asked for something specific.

If the answer is zero, your feature list is a monologue. Not a conversation.

Question 2: Can you describe what your product does in one sentence without using the word "and"?

If you can't, your product doesn't have a positioning problem. You have a protection problem. The "and" is the shield.

Question 3: If you deleted 80% of your features tonight and launched tomorrow with only the core, what feeling comes up?

If the answer is relief: you're ready.
If the answer is panic: the features are doing something for you that has nothing to do with users.

The Uncomfortable Math

Here's a number most builders don't calculate.

Take the total hours you've spent building features. Multiply by your hourly rate. That's the dollar amount you've invested in avoiding market feedback.

Now compare it to the time you've spent talking to potential users.

The ratio is the diagnostic. Not the features. Not the code quality. Not the architecture. The ratio.

Most solo founders I've observed run at approximately 50:1. Fifty hours of building for every one hour of market exposure. That ratio isn't a productivity metric. It's a fear metric.

What This Looks Like From the Outside

Your GitHub has mass activity. Your commit history looks healthy. Your CI/CD pipeline is green. Everything signals "progress" to anyone who looks at the surface.

But your Stripe dashboard says $0. Your analytics show 0 organic signups. Your landing page converts nobody because it tries to explain 30 things instead of solving one pain.

From the outside, you're an active builder.
From the clinical perspective, you're running a very sophisticated avoidance protocol.

The code is the camouflage.

One Thing to Try

Delete your feature roadmap. All of it.

Write one sentence: "My product helps [specific person] do [specific thing] that they currently can't."

If you can't write that sentence, adding more features will not help. You don't have a feature problem. You have a clarity problem. And clarity is the one thing your threat-detection system will fight hardest to prevent.

Because clarity makes you visible.
And visibility is what you've been engineering around this entire time.

Stop Calling It "Engineering Excellence". You're Just

beatsprom — Sun, 10 May 2026 14:24:46 +0000

If you look at your GitHub right now, you likely have a graveyard of half-finished, "next big thing" projects.

You know the cycle:

You get a massive burst of inspiration.
You build the core logic in a single weekend.
You get 95% done... and then you stop.
Instead of deploying the app and sharing the link, you suddenly decide the CI/CD pipeline needs optimizing. You swap out your CSS framework. You tell yourself you just need to add "one more feature" before it's ready.

You call this engineering excellence. Clinically speaking, it is cowardice disguised as hustle.

The Closed Loop vs. The Open Loop
A fellow developer recently articulated this neurological trap perfectly: Watching code compile is a closed loop. Talking to the market is an open loop.

Your nervous system is biologically wired to seek safety and instant reward. The IDE is a completely safe environment. It provides a guaranteed, fast dopamine hit every time a unit test passes or a UI aligns perfectly.

The market is not safe. The market provides ambiguity, indifference, and painful silences.

When your project gets too close to launch, your ego panics. To protect you from the pain of the "open loop" (market rejection), it tricks you into returning to the "closed loop" (writing more code). I call this Productive Hiding.

The "Feature Stack" Defense
Another major symptom of Productive Hiding is keeping your product's core value intentionally vague.

Instead of saying, "This tool solves X problem for Y people" (a concrete claim that the market can actively reject), developers tend to say, "This is an AI tool with 8 integrations, 3 UI styles, and an infinitely scalable architecture."

Why do we do this? Because a list of features cannot be rejected. If you never take a concrete position, you can never be told you are wrong. Your feature stack acts as a psychological panic room. You get to feel highly productive without ever committing to a market reality.

Breaking the Loop
If you suffer from this, you do not have a discipline problem. You have an exposure-tolerance problem.

Introspection and journaling will not save you here, because your ego will simply manipulate your thoughts to justify writing more code. "Motivation" won't save you either, because motivation is what got you addicted to the closed loop in the first place.

You must stop measuring your success by "lines of code written" and start measuring it by "number of times I felt exposed to the market this week."

Stop looking for the perfect tech stack. Stop waiting for the fear of judgment to disappear (it never will). Close the IDE and ship the ugly version.

The market's judgment is exactly what your nervous system needs to break the loop.

Let me know in the comments: what is the most ridiculous feature you've built just to avoid launching?

I built a local AI tool to analyze why I abandon 90% of my GitHub repos (Source Code included)

beatsprom — Fri, 08 May 2026 11:06:21 +0000

If you look at my GitHub, it looks like a graveyard of "next big things."

I have over 20 private repositories that follow the exact same lifecycle:

I get a massive burst of inspiration.
I spend 3 days over-engineering the perfect architecture.
I hit the first boring/hard part (usually auth or marketing).
I abandon the project and start a new one.

For a long time, I thought the problem was my tech stack or my discipline. But after reading some clinical psychology papers on behavioral sabotage in high-performers, I realized it wasn't a code problem. It was an Ego Threat Response.

So, being a developer, I did what developers do: instead of going to therapy, I built a local JavaScript profiling engine to diagnose my exact behavioral flaw, and then engineered an AI System Prompt to act as a clinical intervention.

Here is how I built it, and how you can test it on yourself.

The Architecture of Sabotage

I needed a way to map specific developer behaviors to clinical psychological profiles. I started by building a scoring engine in Vanilla JS.

Instead of asking generic personality questions, I mapped specific failure states. Here is a snippet from my app.js logic:

const questions = [
    {
        text: "Think about the last meaningful goal you genuinely cared about but never finished. What actually happened?",
        options: [
            { text: "I kept refining it, but it never felt ready enough to show anyone.", profile: "perfectionist" },
            { text: "I had a clear vision, but the gap between where I was and where I needed to be felt too large.", profile: "visionary" },
            { text: "I started strong, got excited, then quietly drifted toward something new.", profile: "dopamine" },
            { text: "I needed more research before I felt genuinely ready to begin.", profile: "researcher" },
            { text: "I finished it. I just never really showed it to anyone.", profile: "invisible" }
        ]
    }
    // ... more questions mapping to clinical archetypes
];

The engine tracks the user's responses and tallies them against 7 specific "Builder Archetypes".

My personal diagnosis came back as The Dopamine Chaser (also known as the First-Mover Fugitive). It turns out I don't abandon projects because I'm lazy. I abandon them because the moment the "novelty" wears off and the project gets close to being public, my brain perceives public evaluation as a threat. Fleeing to a new project is a defense mechanism to avoid the reality of finishing one.

The Intervention: Engineering the AI System Prompt

Knowing the problem is only half the battle. I needed an intervention.

I decided to leverage LLMs, but a standard ChatGPT prompt like "Act as a therapist" gives terrible, generic advice. To get clinical-grade results, I had to architect a highly structured System Prompt based on ACT (Acceptance and Commitment Therapy) and IFS (Internal Family Systems).

I structured the PROMPT.html payload to force the AI into a strict state machine:

<!-- Snippet from the core engine -->
<p><strong>CRITICAL RULE: Ask exactly ONE question at a time. Never list questions. Never move forward without a real answer. If the answer is vague or defensive, use a single follow-up before proceeding.</strong></p>

<h2>PHASE 2 — CLINICAL PROFILE</h2>
<p>Synthesize everything you've heard. Identify the pattern with precision. Use the following format:</p>
<ul>
  <li>The primary intervention for this pattern is: [specific technique]</li>
  <li>When you notice [specific avoidance behavior], I will name it immediately</li>
</ul>

By forcing the LLM to ask exactly one question at a time and evaluating the user against the 7 archetypes, it creates a deeply uncomfortable, highly accurate clinical mirror. It doesn't motivate you; it exposes the exact mechanism you use to hide.

The Results

When I ran myself through the engine, the AI didn't tell me to "work harder." It told me: "You are using technical complexity to hide from the vulnerability of shipping. Stop building. Publish what you have right now."

It hit so hard that I actually shipped the tool.

Try it on your own brain

If you have a graveyard of half-finished Next.js/React projects and you want to know the actual psychological reason why you keep abandoning them, you can run your brain through the engine I built.

I deployed the JS quiz to a static site so you don't have to run it locally.

🧠 Take the diagnostic test here: psychoprompt.netlify.app

It takes about 2 minutes. At the end, it will give you your specific clinical archetype and the exact System Prompt you can paste into ChatGPT to start debugging your own behavioral blocks.

Let me know what archetype you get in the comments. Be honest. We all have that one repo we are hiding from.

My AI Psychologist Asked Me 7 Questions. I Wasn't Ready for Question 4.

beatsprom — Thu, 07 May 2026 12:00:06 +0000

I built a psychological profiling prompt for developers.

The idea was simple: ask 7 questions, uncover why someone keeps abandoning their projects, give them a pattern to work with.

Last week I finally tested it on myself.

I wasn't ready for what came out.

The session

It started normal enough.

"Think of a project you care about that hasn't moved forward the way you wanted. Don't explain why yet. Just describe where it lives right now, how long it's been there, and what it means to you that it isn't done."

I described PsychoPrompt — an AI tool I've been building for months. Solid idea. Real audience. Going slower than I want.

Then question 2:

"Imagine someone important to you is about to look at this work. Before they say a word — what happens in your body?"

I noticed I immediately started composing an explanation. "It's not finished yet, this is just the early version, don't judge it by—"

The prompt was already there. That reflex. The pre-emptive defense.

Question 3 hit harder:

"If this project failed publicly — not the project, but you — what would that mean about you?"

My mind offered the reasonable answer first: "Nothing, it's just a product."

Then the quieter one came up.

I'm a loser.

Not a new thought. An old one. The kind that's been collecting evidence for years.

Question 4 is where it got uncomfortable

"There's a part of you that stops you from fully committing to this. If that part could speak honestly — what is it protecting you from?"

The question asks you to talk to that part. Not fight it. Not analyze it. Actually address it.

I sat with it for a while.

Then: "It's protecting me from judgment and public shame."

And then the follow-up: "What does that fear feel like in your body right now?"

I noticed: left side of my head. Pressure in my chest. Body like a string pulled too tight.

"If that sensation could say one sentence — what would it say?"

I didn't expect what came out.

"I'm tired."

Not "I'm afraid." Tired.

That's a different thing. Fear says: the threat is out there. Exhaustion says: I've been at this a long time and it hasn't mattered yet.

What came out of the full session

By question 7, the pattern was clear.

I don't abandon projects because I lose interest.

I move to new territory the moment a space gets competitive — because I've already decided I'll lose in a fair fight. Not from laziness. From a specific belief: "anyone who just learns the same things I know will outpace me."

So I move first. I find the undiscovered ground. I work hard there — sometimes for years (I spent 2 years building a beats community on Instagram by hand).

And then when it gets crowded, I leave before confirmation of failure arrives.

It's not a character flaw. It's a strategy.

A strategy that keeps me safe — and keeps me broke at the same time.

The trap that most builders don't name

Here's what makes this specific pattern so expensive:

The protection works. You never lose publicly. You always have the next idea, the next angle, the undiscovered space no one else has found yet.

But the "loser" voice doesn't care. It keeps collecting evidence anyway — privately, quietly, compounding.

Every unfinished thing. Every project that didn't convert. Every year that passes without the thing becoming real.

You're protected from public failure. But you're not protected from yourself.

How to find your own version

You don't need the prompt to do this. You can ask yourself these 4 questions right now:

1. What's the project you keep returning to mentally — but not physically?
Not the one you're excited about this week. The one that's been in the background for months or years.

2. What's the most honest version of why it isn't done?
Not the polished explanation. The one you tell yourself at 2am.

3. If there's a part of you that stops you — what is it actually afraid of?
Not "failure." That's too abstract. Specifically: what experience is it trying to prevent?

4. When you imagine that fear happening — what does your body do?
This question matters because the body doesn't lie in the way the mind does.

Whatever comes up when you answer these honestly — that's the real work.

Not the productivity system. Not the framework. Not the next tool.

That.

The thing that stays with me

At the end of the session, I realized something:

I've been building in the space between starting and committing for years.

It's a comfortable space. Creative. Full of possibility. Nothing can fail there yet.

The thing is — nothing can succeed there either.

If you've ever said "I just need to find the right idea" more than twice, or if you have a folder of finished things that nobody has seen —

you might be living in that space too.

The first step isn't a new system.

It's just naming what's actually happening.

Which of these patterns sounds most like you? Drop it in the comments — I read every one.

I have 20 unfinished side projects. Here's the honest psychological reason.

beatsprom — Wed, 06 May 2026 11:52:02 +0000

Not 5. Not 10. Twenty.

That's how many folders I counted in my Projects directory last month. Each one with a README, a few commits, sometimes a deployed demo. All of them dead somewhere between "this is the best idea I've ever had" and "I should really get back to this."

For a long time I blamed discipline. Then I blamed my job being too draining. Then I blamed context-switching. Then I read four books about habits and built elaborate productivity systems that I also abandoned.

None of it touched the actual problem.

The actual problem was that I had never identified which specific psychological mechanism was generating the abandonment. And without knowing that, I was treating symptoms.

Here's what I found after going pretty deep into behavioral psychology research.

The pattern I was actually running

I'm what the research calls a "Paralyzed Visionary." High idea-generation rate. Genuine excitement at the start of projects. Tendency to keep multiple options open instead of committing to one.

The mechanism underneath: choosing one project felt like closing the door on all the others. And the brain reads irreversible choice as loss. So it keeps generating new ideas — not because it's creative, but because new ideas reopen the optionality. They're a defense against commitment.

I didn't have too many ideas. I had an aversion to finality disguised as creativity.

The other 6 patterns

Once I understood mine, I found 6 others that cover essentially every developer I've talked to since:

The Perfectionist — never ships because the bar keeps moving. The real driver is fear of judgment, not standards.

The Dopamine Chaser — starts everything, finishes nothing. The brain got its reward from solving the core problem. Why ship?

The Over-Researcher — is always learning, never applying. Research is socially safe avoidance.

The Impostor — comparison as a veto. "Someone else is doing this better" as an excuse not to start.

The Invisible Player — builds things nobody ever sees. Ships privately to a vault.

The Loyal Prisoner — circumstance as a permanent excuse. Real constraints, functioning as a permission structure for inaction.

What actually helped

Not a productivity system. Not a new habit tracker.

Understanding which pattern I was running — specifically, not generally — and addressing the psychological function it was serving.

When I stopped trying to "get more motivated" and started asking "what is this avoidance protecting me from," the answer was uncomfortable and also useful.

I built a 7-question diagnostic to identify which pattern is yours: psychoprompt.netlify.app

Curious — what's in your project graveyard?

# Why You Abandon Every React Project You Start (And How to Fix It)

beatsprom — Sun, 03 May 2026 07:16:24 +0000

If you look at your GitHub repositories right now, how many unfinished React projects do you have? Three? Ten? Fifty?

You start with a massive surge of motivation. You run npx create-react-app or set up a new Vite project. You spend three days perfectly configuring Tailwind CSS, setting up Redux, and carefully architecting your folder structure.

And then... you get bored. You hit a minor roadblock with authentication, or you realize the scope is too big, and you quietly abandon it.

Here is the brutal truth: You don't have a discipline problem. You have a psychological defense mechanism.

The "Paralyzed Visionary" Trap

In the developer world, we often confuse "architecture" with "execution." When you spend 20 hours configuring a React project before writing a single line of business logic, your brain gets a dopamine hit. You feel productive.

But subconsciously, you are doing this to avoid the actual risk of launching. As long as you are "optimizing the React state manager," your app isn't live. If it isn't live, no one can judge it. No one can tell you your idea is bad.

This is a clinical pattern known as the Paralyzed Visionary. You see the perfect 5-year version of the app in your head, and the massive gap between your current empty repo and that vision terrifies you into inaction.

Stop Blaming the Tech Stack

The biggest lie developers tell themselves is: "If I just switch to Next.js or learn a better state management library, I'll finally finish this project."

The tech stack is not the bottleneck. Your ego is the bottleneck.

How to Break the Cycle

To break this pattern, you need to apply artificial, extreme constraints to your workflow.

The 3-Feature Limit: Your MVP is legally not allowed to have more than three features. Write them down. If a feature isn't one of those three, you are not allowed to build it until after launch.
The "Ugly" Rule: Force yourself to deploy a version of the app that visually embarrasses you. If you aren't embarrassed by your first release, you launched too late.
Use a Clinical Prompt: Your brain needs an external boss to prevent over-engineering. I built a custom AI prompt called PsychoPrompt specifically designed to diagnose your builder flaws and force ChatGPT to act as a strict manager that prevents you from going down the React rabbit hole.

Stop hoarding empty repositories. Fix the psychology, and the code will follow.

(If you are serious about curing your launch paralysis, you can take the free diagnostic test at PsychoPrompt and unlock the full Psycho-Builder's Toolkit).

Why Developers Abandon 90% of Their Side Projects (And How I Used AI to Fix My Brain)

beatsprom — Tue, 28 Apr 2026 22:59:59 +0000

Update: I just built a brutalist interactive Web App for this psychological test! Try it here for free: https://psychoprompt.netlify.app/
If you’re a developer, indie hacker, or just someone who builds things, you probably have a folder on your computer right now filled with half-finished projects.

You bought the domain. You set up the boilerplate. You worked on it passionately for one weekend. And then... nothing. It sits there, collecting digital dust, adding to your growing sense of guilt.

I have a massive graveyard of unfinished projects. For the longest time, I thought the problem was a lack of discipline, or maybe I just hadn’t found the right "productivity framework." I tried Pomodoro, Kanban, Notion templates—you name it.

Nothing worked. Because the problem wasn't the tools. The problem was my own psychology.

The Flaw in AI and Productivity Tools

We live in an era where AI can write code for us in seconds. ChatGPT and Claude are incredible accelerators. But they all share a fundamental flaw: they treat every user exactly the same.

When you ask an AI to help you build a SaaS, it gives you a massive, 10-step generic roadmap. For some people, that’s great. For me, looking at a 10-step master plan causes instant paralysis.

I realized that we don't all get blocked the same way. We all have different psychological traps.

I spent time analyzing why builders quit, and I found that almost all of us fall into one of 6 psychological patterns.

The 6 Psychological Profiles of Builders

Which one of these sounds the most like you?

1. The Paralyzed Visionary

You have huge, world-changing ambitions. You can see the final product perfectly in your head. But because the gap between "where I am" and "the final masterpiece" is so huge, you are terrified to take the very first step. You don't want to ruin the perfect idea with a bad first draft.

2. The External Executor

You are an absolute beast at your day job. If a boss gives you a deadline, you crush it. But the second you sit down to work on your own personal side project, your brain freezes. Without external pressure and validation, you can't force yourself to execute.

3. The Perfectionist Trap

You actually write code, but you never ship. You spend three weeks adjusting the border-radius on a button. You rewrite your entire backend in Rust because you read a blog post about performance, even though you have zero users. You polish infinitely to delay the terrifying moment of launch.

4. The Over-Researcher

You feel like you "don't know enough yet" to start building. So you watch 40 hours of YouTube tutorials, read 15 books, and buy 3 courses. You confuse learning with doing. You feel productive, but your codebase is empty.

5. The Dopamine Chaser

You love the thrill of starting. Buying the domain and setting up the tech stack gives you a huge dopamine hit. But the second the project gets difficult or boring (like setting up auth or writing documentation), your brain checks out and you start looking for a new, shiny idea.

6. The Detail Drowning

You jump straight into the code without a plan. You get completely lost in a tiny, irrelevant feature (like building a custom rich-text editor from scratch instead of using a library) and lose sight of the big picture. Eventually, you get overwhelmed by the spaghetti code and give up.

The Solution: PsychoPrompt

Once I realized I was a classic Paralyzed Visionary mixed with a bit of Dopamine Chaser, I knew generic AI advice wouldn't work for me.

I needed an AI that knew my flaws and actively prevented me from falling into my traps.

So, I built what I call PsychoPrompt.

It’s a system prompt you paste into Claude or ChatGPT before you start working. Before it helps you write a single line of code, it asks you 7 specific intake questions to diagnose which of the 6 profiles you fit into.

Once it builds your psychological profile, the AI completely changes its behavior:

If you are a Paralyzed Visionary, it refuses to give you big roadmaps. It only gives you one tiny, microscopic task at a time to force momentum.
If you are an External Executor, it acts like a strict manager, demanding daily updates and setting artificial deadlines.
If you are a Perfectionist, it actively interrupts you when you spend too much time on details and forces you to hit 'deploy'.

It has completely changed how I build. Instead of fighting my own brain, the AI manages my flaws for me.

Try It Yourself

I decided to package the entire PsychoPrompt system, along with examples of how the AI adapts to each profile, into a clean PDF guide.

I’ve put it up on Gumroad for free (you can literally just type $0 and grab it).

👉 Grab PsychoPrompt Here

If you use Claude or ChatGPT for coding, writing, or building businesses, I highly recommend pasting this into your System Instructions.

Let me know in the comments: Which of the 6 psychological profiles do you resonate with the most? (I'd love to know I'm not the only Paralyzed Visionary out there!).

I built a free GitHub README Generator — no sign-up, no BS

beatsprom — Sun, 26 Apr 2026 17:36:46 +0000

Every time I start a new project, I dread the same thing: writing the README.

Not because it's hard — but because it's tedious. You Google "readme template", copy some random markdown, spend 20 minutes tweaking it, and it still looks mediocre.

So I built a tool to fix that.

🔗 README Generator

It's a free, open-source tool that lets you build a professional README.md in minutes — with a live preview.

How it works

Toggle sections you need (Title, Badges, Features, Installation, API, etc.)
Fill in your details using simple form fields
See the live preview update in real-time
Copy the markdown or download as .md file

That's it. No sign-up. No email required. No "premium tier".

Why I built it

I was tired of:

Googling "readme template github" for the 100th time
Copy-pasting from old projects and forgetting to update things
Spending more time on the README than on actual code

So I made a visual builder where you just fill in the blanks.

Tech stack

The entire app is a single HTML file. No React, no Next.js, no npm install. Just:

Vanilla HTML/CSS/JS
marked.js for markdown rendering
Deployed on Vercel (free tier)

Features

✅ 12 toggleable sections (Title, Badges, Description, Features, Tech Stack, Installation, Usage, Env Variables, API Reference, Contributing, License, Author)
✅ Live markdown preview
✅ Copy to clipboard with one click
✅ Download as .md file
✅ Dark mode UI
✅ Fully responsive
✅ Works offline after first load

It's open source

The full source code is on GitHub:

trobasuj-cpu / readme-generator

Feel free to fork it, improve it, or steal ideas from it. PRs welcome!

What's next

I'm thinking about adding:

Drag & drop to reorder sections
More badge presets (npm version, downloads, coverage)
Template presets (library, CLI tool, web app)
Export as PDF

What features would you add? Drop a comment below 👇

🔗 Try it: readme-generator-xi-one.vercel.app
⭐ Star it: github.com/trobasuj-cpu/readme-generator