Asking for Guidance

[Umesh042005]

Hey everyone! 👋
I'm Umesh, a full-stack developer from India. I work with MERN stack and Java backend. I've previously contributed to OWASP Dependency Check and have 2 merged PRs there.
I'm really excited about Flowise and want to start contributing here. I went through some issues but wanted to connect with the community first before jumping in.
A few questions:

Which areas need the most help right now?
Any good first issues you'd recommend for someone new to the codebase?
Any tips for setting up the dev environment quickly?

Looking forward to contributing and learning from this community!

[yudin-s]

For a MERN/Java background, I would start with areas where you can contribute without needing to understand the entire Flowise internals on day one:

1. documentation gaps from real setup/use
2. small UI fixes in the node configuration forms
3. new examples/templates for common RAG or agent flows
4. tests or bug fixes around existing nodes/connectors
5. validation/error-message improvements for credentials and node inputs

For first issues, I would look for problems where the expected behavior is already clear. Good examples are:

• a node accepts invalid config and fails later
• the UI error message does not explain which credential/input is missing
• docs are missing one required env var or setup step
• an integration works but lacks a minimal example

Those are usually better first contributions than adding a brand-new integration, because a new node often touches UI schema, credentials, runtime execution, docs, and tests at the same time.

For setup, I would do this first:

git clone https://github.com/FlowiseAI/Flowise.git
cd Flowise
pnpm install
pnpm build
pnpm start

Then pick one existing node close to what you want to work on and trace it end-to-end:

credential definition
node UI inputs
runtime execution
docs/example
tests if present

Given your OWASP Dependency Check background, security-adjacent contributions could be especially useful: safer credential validation, clearer handling of missing secrets, dependency/update notes, or examples that avoid leaking keys in logs.

The best first PR is usually small and boring: one reproducible problem, one focused fix, and a short before/after explanation.