StealthMatch

A secure opportunity-matching app for founders, helping to research investors, accelerators, grants, and pilot programs without uploading any confidential facts that determine fit before an NDA.

Comment

Inspiration

I have long been interested in the entrepreneurship and startup world. Through conversations with founders and investors, I kept seeing the same early-stage tension: only a limited set of information can be shared safely before an NDA. A founder can publicly say they work in climate, AI, or health, but the details that determine whether an investor, accelerator, grant program, or pilot partner is actually suitable, such as runway, capital position and named strategic conflicts, often cannot be shared yet.

Without those facts, opportunity search becomes a broad, manual exercise. Founders can spend scarce time on conversations, applications, and research that were never likely to fit their real operating constraints. Time is especially expensive in a startup: every week spent pursuing a poor-fit path is time lost in building, growing, or reaching out to potential clients.

Existing public filters can find a broad set of candidates, but they cannot responsibly use that private mandate. I wanted to make the first research step more useful without requiring a pitch-deck upload or an early disclosure event: better matching and ranking, so founders can direct limited resources toward the opportunities most worth pursuing.

What it does

StealthMatch starts with public filters for vertical, company stage, and opportunity type. The founder then enters a private mandate locally: six numerical constraints, optional named conflicts, and eligibility signals.

The app encrypts the mandate on the founder device, scores it against a public opportunity catalog, and returns encrypted component scores. The founder device decrypts and ranks the results locally into a research shortlist with deterministic reasons, cautions, and official links.

The scoring service never sees the founder’s secret key, plaintext mandate, conflict names, or decrypted scores. The public catalog remains public in this MVP.

How we built it

StealthMatch has a clear three-step data flow. First, on the founder’s device, the browser collects the mandate and the local FHE client creates keys and encrypts the inputs. Second, the scoring service receives the ciphertexts plus public and evaluation keys; it then evaluates them across the public catalog using SIMD packing and returns encrypted component scores. Third, back on the founder’s device, the local client decrypts, ranks, and turns those scores into the shortlist.

We built that flow with CKKS fully homomorphic encryption through the supported Niobium DSL → generated C++ → client/server/decrypt workflow. The design of the app was based on the design skill in link, and the DSL knowledge was through link.

Codex, using GPT-5.6, accelerated the work from the FHE scoring design through implementation, portability, testing, and documentation. GPT-5.6 helped reason through the privacy boundary, FHE scoring approach, and paired evaluation cases. Codex helped implement the supported Niobium path, make the build reproducible, and verify the result. The founder problem, privacy boundary, and evaluation standard remained human-led decisions.

Challenges we ran into

  • Machine-specific build setup and SDK integration choice: the project had hard-coded local paths and fixed ARM compiler settings. It was also using local checkouts of Niobium client repo, meaning another developer could not build it. After exploring options, we replaced that with a pinned Niobium submodule and a portable bootstrap path.

  • Keeping FHE essential, demonstrating the product differentiation: the challenge was not merely displaying encrypted values; it was showing that the founder’s private numerical constraints and conflicts are materially meaningful. GPT5.6 helped a lot with researching relevant data, going through different websites offering matching services and looking at what information is available from the different opportunity providers. These research info efficiently backed up information/fields used in our app, and we were able to create paired scenarios that actually show the value of having these confidential information when searching for opportunities.

  • Turning cryptography into a founder-facing product: raw ciphertexts, score vectors, and error values are not useful to a founder. We converted decrypted component results into deterministic reasons, cautions, and official research links.

  • Repository hygiene: tracked files and history contained local/personal environment traces. We removed them, sanitized the repository history, and verified a fresh standalone build.

Accomplishments that we're proud of

  • A genuine local-encrypt → blind-score → local-decrypt workflow completed within a short period of time.
  • A founder-facing interface that avoids raw ciphertext, approximate-error values, and unexplained distances.
  • Plaintext-versus-encrypted score and ranking agreement through make test.
  • Three paired scenarios through make compare that demonstrate the value of private inputs beyond public filters.
  • A clean, reproducible project with a pinned SDK and fresh-clone bootstrap verification.

What we learned

Privacy features are only useful when they change a real decision. The most valuable private inputs are not broad labels a founder would willingly publish; they are the concrete operating facts and conflicts that change opportunity fit.

We also learned that an FHE prototype needs ordinary product discipline: a clear privacy boundary, useful results, reproducible setup, and a plaintext reference before claiming that encrypted computation works. CKKS is approximate, so verification belongs in the product-development process even when it is not shown to the end user.

What's next for StealthMatch

Today, the opportunity catalog is public while the founder mandate is encrypted. Next, investors, accelerators, grant programs, and pilot partners could encrypt their own confidential information, enabling two-sided private matching before either party decides to disclose more.

We would also expand the source-backed catalog, improve coverage review for conflict signals, measure performance across a wider range of realistic mandates, and introduce controls for output leakage and request metadata.

Built With

Share this project:

Updates