For people choosing an app
You do not need to read code or connect GitHub. When a founder approves an observation for publication, it becomes part of the app’s capability profile. That gives you additional context for judging whether the app fits your task.
- Find specific capabilities: published observations can help an app appear in relevant searches, including features its short description may leave out.
- Make a more informed comparison: see whether a feature is claimed, observed in code, tested, or still planned.
- Focus your follow-up: check the observation’s scope, date, limitations, and declared availability before choosing.
For developers
A source review has two outputs: a private maintenance report for you, and optional product observations for your listing. You can use the report without publishing any observations.
- Locate maintenance work: the included scan flags repeated functions, long functions for review, and circular imports in JavaScript and TypeScript. Findings include source locations, suggested changes, and behavior checks.
- Explain what you have built: review a limited set of recognizable feature patterns and publish accurate observations with the scope and availability customers need to understand.
- Share evidence selectively: your code and private report are not exposed to buyers. Access is optional, read-only, and revocable. Connecting a repository does not require making it open source.
An example: finding an app with CSV export
A scan may find a pattern associated with CSV export. The developer reviews what it covers and whether customers can use it, then chooses whether to publish the observation. Someone searching for CSV export can see that evidence alongside the declared availability. The observation itself is not a successful export test. This is an illustrative example, not a finding about a listed app.
Start with the task
Search matches your requirements to app descriptions, platforms, and published capabilities. Platform, pricing, and release filters narrow the results. The first version uses task keywords and related terms; it will show partial matches and missing terms instead of claiming to understand every request.
Evidence has different strengths
- Founder or project claim: supplied information that has not been independently checked.
- Implementation observed: an identified source revision contains evidence of an implementation. Its scope and release availability still need review.
- Behavior tested: the behavior was checked in a particular version and environment. The current source scan does not run these tests.
- Planned or unknown: a feature is not established as available.
Source code and a released app are different
We record the analyzed revision. A feature in source code may be unfinished, disabled, or absent from the customer release. The MVP does not automatically verify a production deployment. Founder release declarations remain labeled as such. A source scan does not certify security, reliability, or overall product quality; its maintenance suggestions still require developer review and testing.
Ranking follows fit
Task relevance comes first. Evidence supporting available capabilities can provide a small tie-breaker. We do not currently score maintenance quality. Raw commit counts and repository connection alone do not buy a ranking boost. Missing evidence is uncertainty, and a mature app does not need frequent commits to be useful.
Private code stays private
Repository access is optional. Authorized source is read for a bounded analysis and is not executed. Raw source files are not retained after the job; private reports contain evidence locations and findings. They are accessible only to the owning account. We never send source to an external AI provider in this version.
Disconnecting a repository deletes its private reports and connection record, stops queued work, and removes published source-derived capabilities. The app remains listed using its other product information. Deleting the app removes its associated records.
Your saved requirements
Saved requirements are private to your account. Relevant catalog changes create in-app updates. Email alerts require your explicit choice, a verified email, and enabled email delivery. Public requests are separate: posting one intentionally shares the problem and description. A vote means interest, not a purchase commitment.
Planned premium: customer-demand alerts
A recurring premium membership is planned to notify developers when relevant customer needs match features their app offers or could add. Published capability evidence can help make those alerts more specific. The goal is to help developers spot interest in their app and decide which improvements to investigate next.
Today, the founder workspace shows recurring feature topics after at least three distinct people save related requirements. Proactive developer alerts are not yet available. Premium alerts will preserve that protection for private demand: individual searches and contact details will stay private. Interest is a research signal, not a guaranteed lead or sale. Membership pricing is still being developed.
A pilot catalog, labeled honestly
Founding examples from Christia Labs are labeled as pilot entries until release availability is established. No sample reviews, ratings, customer counts, or completed evaluations are presented as real.
List your app