A two-sided marketplace · schools issue · studios respond
rfp.software gives a school one place to issue a request for proposal — the scope, the budget, the due date, and the weighted criteria it will judge on — and gives studios one place to find that request and respond. Every studio sees the same brief. Every response is scored on the same criteria. The award decision, and who is allowed to make it, is enforced by the server.
Early access. rfp.software is being built. Scoring, awarding, and access are server-owned; this page describes the model honestly and shows no sample volume, no invented activity, and no testimonials we did not receive.
What it is
rfp.software is a two-sided marketplace for one job: choosing a studio on one shared rubric. A school writes a request for proposal — the scope of work, a budget, a due date, and the weighted criteria it will judge on — and issues it. Studios find that request, read the whole brief and the exact criteria, and respond with a proposal and a price. The school scores every response on the same rubric and awards a single one.
The whole model turns on an ordering rule: the rubric is written once, before any response can be read. Every studio answers the same brief; every response is scored on the same criteria; and who is allowed to score and award is owned by the server, not by the browser. That is what makes a ranking something a school can put on the record and explain, rather than a preference it has to defend after the fact.
It is deliberately narrow. rfp.software is the outward step of picking a studio; it is not a school’s internal purchasing paperwork, and it does not try to be. It runs no payment, publishes no prices, and posts to no public bidding register. Honestly, where the build is: the issue, discover, respond, score, and award flows are early access and being built. Where a step is not live yet, this page says so rather than showing invented activity.
How it works
The same request moves through five steps. Two belong to the studios, three belong to the issuing school, and the server keeps each side to its own.
Step 1 of 5 · School
A school posts a request for proposal: a title, the scope of work, a budget, a due date, and the criteria it will judge on -- each criterion with a weight the school sets. The rubric is written once, before any response is visible.
School
Step 2 of 5 · Studio
Studios browse the open requests. Each one shows the full scope, the budget, the due date, and the exact weighted criteria the school will score on -- so a studio can decide whether to bid before it writes a word.
Studio
Step 3 of 5 · Studio
A studio submits one written proposal and one price against the published criteria. It is on the record: the same brief every other studio answered, judged on the same rubric.
Studio
Step 4 of 5 · School
The school scores each response on each criterion, using the same rubric for every studio. The weighted total is plain arithmetic -- a ranking you can put in front of a business office or a board.
School
Step 5 of 5 · School
The school awards a single response. Who may score and award is enforced by the server: only the issuing school, never a studio, and never the browser.
School
The lifecycle
One request travels from a drafted rubric to a single award, and reading it back gives a plain-language state a person can act on. Two of these stages are early access and labeled as such; one is a state the flow is built not to force on the school.
The school writes the request -- a title, the scope, a budget, a due date, and the weighted criteria it will judge on. This is where the rubric is set. Nothing is public, and no studio can see it yet.
The request is issued to studios. Every studio sees the same scope, budget, due date, and the exact weighted criteria -- and only now can it decide whether to respond.
Studios submit their proposals and prices against the published criteria. Responses are on the record and judged on the same rubric; the school reads them to score, not to rewrite the criteria after the fact.
The school scores each response on each criterion using the one rubric, and the weighted total sets the ranking. This surface is being built -- no invented scores appear until it is live.
The school awards one response and each responder's status is set, with the issue-score-award history standing as the on-the-record trail. Award execution and a downloadable audit trail are early access.
A request the school pulls before it awards, or one whose window closes with no award, ends here. There is no hidden state that pushes a request to a decision on the school's behalf.
Built vs early access
These are the model’s rules and their build status, split honestly. Built in marks a rule the product is organized around — it holds by construction and a busy office cannot switch it off. Early access marks a surface still being built and not live yet. The interactive product as a whole is early access; a Built-in rule is a design commitment, not a claim you can log in and run it today.
Built in
The load-bearing rule of the model: the weighted criteria are fixed when a request is issued, and no response is visible to the school until they are. This ordering is built into how a request works -- it is not a setting a busy office can forget to switch on.
Built in
Scope, budget, due date, and the weighted rubric are published once and read identically by every responder. There is no private addendum that reaches one studio and not another.
Built in
Scoring and awarding belong to the issuing school and are enforced by the server, never by the browser. A studio can respond and read its own status; it cannot score, award, or read another studio's proposal.
Built in
Submitted, under review, awarded, or not selected -- the status a studio sees is the status the school recorded, shown as-is. The page never infers or invents a status on a studio's behalf.
Early access
The per-criterion scoring screen -- where a school enters a score for each response on each criterion and the weighted total is computed -- is being built. Until it is live, the page shows no scores.
Early access
Recording the single award and moving each response to its final status is being built. The page does not show an award that has not happened.
Early access
Signing an award, or the agreement that follows it, is not built. When it is, it will be its own gated step and will say so; the page claims no signature capability today.
Early access
An on-the-record export of who issued, scored, and awarded -- and when -- is being built. The page describes the audit trail as part of the model; it does not offer a live export yet.
For schools
A school writes the brief and the rubric a single time, reads every response against the same criteria, and awards the one that earns it. The decision, and the right to make it, stay with the school.
Scope, budget, due date, and the weighted rubric are written once and shown to every studio identically. No side channels, and no re-explaining the same job to five different studios.
Decide what matters -- price, turnaround, references, sample quality -- and how much each is worth, at the moment you issue the request. The weights are set before a single response can be read.
Every response is scored on the same criteria, so the ranking follows the rubric rather than a hunch. The weighted total is written down and holds up to a business office, a principal, or a board.
The award decision belongs to the issuing school and the server enforces it. A studio can respond and watch its status; it cannot score, award, or read another studio's proposal.
For studios
A studio finds the open requests, reads the scope and the exact criteria before bidding, and submits one proposal and one price. The status it sees afterward is the status the school set -- nothing guessed.
The scope, budget, due date, and the exact weighted criteria are on the request. You decide whether to spend the hours writing a proposal with the rubric in front of you, not after.
Submit one written proposal and one price against the published criteria. No back-and-forth chasing what the school actually wants -- the brief already says it.
Submitted, under review, awarded, or not selected -- the status you see is the status the school recorded. It is display-only, and the page never guesses a status on your behalf.
A studio sees the open requests and its own responses -- nothing else. That boundary is enforced by the server, not by what a page happens to render.
How the scoring works
The school writes the rubric when it issues the request. Each criterion carries a weight, and every response is scored against every criterion. The weighted total is the ranking -- the same arithmetic applied to every studio.
As an illustration only, a school commissioning yearbook photography might list four criteria and weight them so that price, turnaround, references, and sample quality together add up to one hundred. Whatever the school chooses, the weights are fixed at issue time, the studios see them before they respond, and each response earns a score on each criterion. The response with the highest weighted total sits at the top of a ranking the school can explain to anyone who asks.
The weights and scores are numbers the school owns. rfp.software does not tilt them, does not add a house score, and does not surface a ranking the school did not compute. The example above is a worked illustration, not activity from the marketplace.
Fairness
Fairness here is not a promise in a brochure; it is the order the model works in. The weighted criteria are written once, when the request is issued, and no response is visible to the school until they are set. Because the rubric is locked before any proposal can be read, the criteria cannot be quietly re-weighted after the responses arrive to fit a studio the school already had in mind. Every studio answered the same brief and is scored on the same rubric.
The same idea runs through who is allowed to decide. Scoring and awarding are server-owned: the issuing school scores and awards, a studio never does, and the browser never does. A studio reads only the open requests and its own responses — never another studio’s proposal — and that boundary is enforced by the server, not by what a page happens to render.
And the decision is meant to be shown, not just made. The issue, the scores, and the award are recorded on the one rubric, so a ranking can be put in front of a business office, a principal, or a board and explained by the criteria rather than a hunch. A downloadable audit trail — who issued, scored, and awarded, and when — is early access; the page describes it as part of the model and does not offer a live export yet. rfp.software records the criteria and the decision; it does not detect or adjudicate a conflict of interest on the school’s behalf — a conflict-of-interest policy is the school’s to set and disclose.
What it holds
This is adult, business-to-business procurement between a school’s adviser or administrator side and a studio. A request carries a scope, a budget, a due date, and weighted criteria; a response carries a proposal and a price. No student records, no minor data, and no consent gating are part of a request or a response. There is no roster here, because the job does not need one.
Access is scoped. A studio sees the open requests and its own responses, and nothing else; the school sees the responses to its own requests. That boundary is server-owned — enforced where the data lives, not by what a page chooses to render — so a bug in a page cannot turn into another studio’s proposal on screen.
To be plain: this is not a ‘we hold no data’ claim. A request and a response are data. The honest version is narrower — it is business procurement data between adults, carrying no student identity, with each side scoped to what is its own.
Where it stands
Early access. The issue, discover, respond, score, and award flows are being built. Where a step is not live yet, the page says so rather than showing invented state. There is no sample volume, no invented activity, and no testimonials we did not receive anywhere on this page.
Built into the model. The rules the product is organized around hold by construction: the rubric is locked before any response is read, one brief reaches every studio identically, who may score and award is server-owned, and a studio’s status is display-only.
Honest-off. Money is off: no pricing, no checkout, no fee schedule, and no card is charged anywhere in this flow. There is no public-bid register, no e-signature on an award, and no live audit-trail export today — each is early access and named as such, not shown as if it were already live.
Questions
Two sides of one procurement. On one side, schools that need to commission creative or service work -- yearbook, photography, printing, design -- and want a structured, on-the-record way to compare studios. On the other side, the studios that do that work and want the full brief before they invest hours in a proposal.
Something the school will judge responses on, plus how much it counts. A school might weight price, turnaround, references, and sample quality differently. Every response is scored on each criterion, and the weighted total sets the ranking. The criteria and their weights are fixed when the request is issued, before any response can be read.
Those two are the internal side of a school's own purchasing -- filing a purchase request and signing off on it against the school's budget. rfp.software is the outward step that can come before any of that: it is where a school compares outside studios on one shared rubric and picks one. Same neighborhood, different job -- this page selects a vendor; those pages handle the school's internal purchase-and-approve paperwork.
No. Scoring and awarding are restricted to the issuing school and enforced by the server. A studio can respond to an open request and see the status of its own response; it cannot score, award, or view another studio's proposal.
The status the school set on that response -- submitted, under review, awarded, or not selected. It is display-only. The page shows what the school recorded and never infers or invents a status.
No. rfp.software structures a school's own request-and-respond process on one shared rubric; it is not a certified public-bidding or sealed-tender platform, it does not post to a public procurement register, and it makes no claim of meeting any jurisdiction's formal public-bid or open-records law. If a school is running a formal public bid, that runs on its official channel; this is a private, structured way to compare studios.
The model keeps the rubric fixed before any response is read and keeps who-may-score-and-award server-owned, so the criteria cannot be quietly re-weighted after responses arrive to fit a studio the school already had in mind. A conflict-of-interest policy itself is the school's to set and disclose. rfp.software records the criteria, the scores, and the award on the same rubric so a decision can be shown to be on the record; it does not detect or adjudicate a conflict on the school's behalf.
No. This is procurement between a school's adviser or administrator side and a studio -- an adult, business-to-business process. No student records and no minor data are part of a request or a response.
No. rfp.software is a for-profit software product built by Stanley Studios LLC -- a way for schools and studios to run one structured, on-the-record comparison. It is not a school, not a district, and not a nonprofit, and nothing here is a donation. We are precise about that because it matters: this is software a school buys, not a charitable gift.
It is early access. The issue, discover, respond, score, and award flows are being built. Where a step is not live yet, the page says so rather than showing invented activity. There are no sample marketplace numbers on this page and no testimonials we did not receive.
What we will not do
Scoring, awarding, and access are server-owned. This page mirrors those rules as an affordance so each side knows what it can do; it never claims the browser enforces them. The status a studio sees is the status the issuing school recorded, shown as-is and never inferred.
rfp.software is early access — the issue, discover, respond, score, and award flows are being built. Where a step is not live yet, the page says so rather than showing invented state. There are no sample marketplace numbers here, no invented activity, and no testimonials we did not receive.
This is adult, business-to-business procurement between a school’s adviser or administrator side and a studio. No student records and no minor data are part of a request or a response, and there is no pricing or checkout on this page. rfp.software is a for-profit software product, not a school, a district, a nonprofit, or a donation.