Inspiration

“Would you leave your job for this?” is a question you might ask yourself long before you’re ready to announce your next move.

Finding a cofounder usually means making yourself public: your name, your background, your idea. We wanted to reverse that order. Could a personal agent help you discover someone worth building with before either of you reveals who you are?

That became Would You Jump? (WYJ): founder matchmaking built around private processing and mutual consent.

What it does

Tell WYJ what you want to build, what you bring, and what you need in a partner. Its browser-local models help improve your idea, suggest skills and interests, and give your project a playful nickname.

You review the exact pseudonymous brief before publishing it. Your pasted background stays on your device. Matching uses your approved brief to find people with a shared direction and complementary skills.

An introduction requires two independent approvals. Only then does WYJ reveal the name and contact details each person chose to share.

Once connected, founders can propose a working trial, agree on contributions and a deliverable, and build a joint pitch.

Optional cloud enhancement and public research require separate approval. DeepSeek enhancement receives only the approved brief fields, while research uses an explicitly approved topic query.

How we built it

We built WYJ with Next.js, React, TypeScript and TanStack Query, backed by Supabase Postgres.

Laya runs locally in a browser worker through ONNX Runtime Web to suggest classification labels. Bonsai 1.7B provides local generative assistance through Transformers.js and WebGPU. Model files load from the laptop-hosted app for our demo; inference happens inside each visitor’s browser.

Matching is deterministic, using reviewed topics, offered skills and partner preferences. The server enforces publication ownership, pair-specific identity approvals and versioned working-trial agreements.

For optional cloud assistance, the browser submits an approved idea reference rather than private questionnaire text. The server checks ownership, publication status and version before constructing the provider request.

Challenges we ran into

Our biggest challenge was making privacy part of the product’s behavior. Hiding a name is not enough: a distinctive idea can still identify someone. We use pseudonymous briefs, make the sharing boundary explicit, and let founders unpublish their ideas.

Browser inference brought real constraints: large downloads, GPU compatibility and model initialization. We added background warmup, cancellation and a manual path that remains usable while models load.

We also had to make consent work across two independent sessions. One person’s approval must never reveal the other person’s contact details, and editing a trial must invalidate approvals for its previous version.

What we learned

A useful personal agent does not need unrestricted access to everything about you. It needs a clear purpose, a narrow data boundary and a way to ask before sharing.

We learned that classification output needs human review, compatibility needs more than similar interests, and a small shared experiment is a better next step than an unexplained match score.

Accomplishments we’re proud of

Browser-local assistance without sending pasted background to a cloud model.
Exact-brief publication, unpublish and republish controls.
Mutual identity reveal verified across independent sessions.
Shared working trials and joint pitch creation.
Real DeepSeek enhancement and public research with separate approvals.
207 automated tests and 41 end-to-end acceptance checks passing.

What’s next

We want to improve matching quality using feedback from real founder introductions, reduce model download sizes, and make the first shared working trial easier to complete.

Our goal is to help someone move from “I have an idea” to “I found someone worth building it with”—on their own terms.