product
Why Naseeg Is Round-First
A single manually operated funding window gives creators, Fund Accounts, and supporters a shared, inspectable lifecycle.

Naseeg is designed around a funding round, not an endless feed of loosely connected campaigns. The round is the operational window that tells participants when Funds can form, when projects can be submitted, when support can count toward matching, and when allocations are finalized.
The lifecycle is explicit
An administrator opens a round. Fund Accounts create Funds. Creators publish reusable projects and submit them to active Funds. Fund owners review and curate those submissions. Supporters purchase project Artifacts. After the round closes, the system stores the resulting matching and prize allocations.
There is no separate automated curation phase and no countdown that quietly closes a funding window. A planned end date can inform participants, but a human administrator operates the actual lifecycle.
Projects survive a round
A project is not thrown away when a round ends. Projects and Artifacts persist, while Fund participation belongs to a dedicated round-specific submission record. That means a project can participate in later rounds without being reduced to its treatment by one Fund in one moment.
Round-first coordination makes timing and responsibility clear. It creates a system that can be explained to a creator before they publish, to a Fund Account before they curate, and to a supporter before they contribute.
A round is an explicit state machine
Naseeg's current backend does not infer a round transition from a clock or a browser countdown. A planned end time can be shown to participants as information, but an administrator operates the lifecycle. That protects the platform from a common funding-product failure mode: a page suggests that an opportunity is open while the backend has already moved to a different state, or an automatic deadline changes eligibility without a clear operational decision.
01 / open
Curate + support
Funds curate published projects and paid contributions count.
02 / closed
Stop intake
New eligible support is no longer accepted for that round.
03 / finalized
Store results
Calculated allocations become the round's recorded outcome.
The application uses an open round as the authorization context for the work that follows. Fund creation, project submissions, Fund review, checkout eligibility, and allocation recalculation all take their meaning from the round record rather than an unstructured date comparison.
// The backend asks for the current operational state, not only a timestamp.
const openRound = await requireOpenRound(ctx, fund.roundId);
if (normalizedRoundStatus(openRound.status) !== "open") {
fail("INVALID_STATE", { resource: "open round" });
}
The implementation keeps reusable work separate from the window
Projects and Artifacts are durable product records. A Fund submission attaches a project to a Fund and one round. It is this fundSubmissions record—not the project itself—that carries the round-local status such as submitted or curated.
project
├─ has public publication state
├─ has reusable Artifacts
└─ can appear in multiple Fund submissions
fundSubmission
├─ references one project
├─ references one Fund
├─ references one round
└─ carries that Fund's local decision
This design allows a creator to bring the same project into a later round or another Fund without quietly carrying a previous local rejection as a global property. It also narrows authorization: Fund Accounts deal with submissions to their Funds; administrators hold the explicit global override.
Checkout uses the round as an eligibility boundary
Naseeg's contribution preparation does not trust the state that was visible when a supporter clicked. It reads the open round, verifies the project is published and the Artifact is live, finds the project's submissions, and requires a curated submission for the same round before creating a contribution.
const eligible = isProjectSupportEligible({
roundStatus: openRound.status,
projectStatus: project.status,
submissionStatuses: submissions
.filter((item) => item.roundId === openRound._id)
.map((item) => item.status),
});
if (!eligible) fail("INVALID_STATE", { resource: "curated project" });
The contribution receives the roundId at creation. That makes later allocation work inspectable: the funding system does not have to guess which window a payment belonged to, and a later round cannot silently reuse it.
Close before finalizing
When a round moves out of the open state, the platform stops treating new support as eligible for that window. Allocation rows can then be calculated and stored rather than continuously shifting beneath users. The current allocation mutation also requires an open round when recalculating a Fund, keeping changing curation and matching inputs inside the operating window. Result pages are for stored outcomes after the lifecycle has advanced, not a live public promise that every number is final at every moment.
open round
-> curations and eligible paid contributions change
-> administrator closes the round
-> allocations are stored and payouts are handled operationally
-> administrator finalizes the round
The precise operational tooling may evolve, but the product constraint should remain: the lifecycle transition must be clear enough that a creator, Fund Account, supporter, and operator can all identify which actions are still allowed.
Why a round is better than an endless feed here
An endless campaign feed encourages loosely scoped eligibility: it becomes difficult to know which curation decision applies, when a matching budget is fixed, and whether a support action changed a final result. A round creates a shared window for that coordination. It gives Fund Accounts a bounded set of submissions, gives creators a clear opportunity, gives supporters a defined relationship between a paid Artifact and matching, and gives administrators a concrete moment to close and report results.
Naseeg is Coming Soon. The round-first model and its backend checks describe the current implementation direction; they do not represent a public invitation to contribute before the product is opened.