What we need to know, and how we make sure it lands
A fixed price is only honest if the scope is understood. This page is the brief we work from: send answers to the first five lines plus one sample and you will get a number, not a discovery call.
What to send us
Eight lines. Half of them you can answer in a sentence. If a line does not apply, write "not applicable" and move on. The completeness matters more than the length.
1. The outcome
What should exist or stop happening when this is done? One sentence, in your words, is enough: "prices on 400 products update nightly instead of a spreadsheet every Friday."
Why it matters: it is the line the acceptance criteria get written from. Without it we are both guessing, and guessing is how projects drift.
2. Who does it today
Who does this by hand now, how often, and roughly how long each time? What breaks, or what happens, if it stops for a week?
Why it matters: a task that takes four hours a week and a task that takes four hours a day are different jobs and different prices.
3. The input
Where does the data or content come from? A URL, an API, a CSV export, a login-walled dashboard, an email, a physical file? How many records or pages, and how often do they change?
Why it matters: this is the biggest price driver. An export we can read is a different job to a site that logs you out mid-crawl.
4. The destination
Where must the result live? A sheet, a CRM, a database, a static site, an email, a folder? Who owns that account, and can we get access to it?
Why it matters: if the destination is your platform, its setup and permissions are on the critical path, and better known now than in week two.
5. What "working" means
How will you know it works? "All 400 rows land with the right price by 7 a.m." beats "it should be automatic", and it becomes the acceptance test.
Why it matters: this is the single line that prevents the "this is not what I imagined" conversation at the end.
6. Failure and access
If it breaks at 2 a.m., what should happen, and who reads the alert? What access can you grant: read-only to the source, admin on the destination, a staging copy?
Why it matters: alerting and access are part of the build, not afterthoughts. Both change the price line, not the timeline.
7. The real deadline
Is there a date that cannot move, and what depends on it? Or is the constraint the cost, or the order of the changes?
Why it matters: we will tell you honestly whether the date holds, before you plan around it.
8. After handover
Who runs it once it is live: you, a team, or us? Does anything need to keep being watched, and who changes the rules later?
Why it matters: it decides whether the handover pack matters most, or the care plan does.
Add one sample to the brief: a URL, a CSV, a spreadsheet export, a screenshot of the admin screen, or the page that must exist. One real sample removes more ambiguity than a paragraph of description.
How we make sure it is what you wanted
Most disagreements at the end of a project are not about quality. They are about a scope nobody wrote down. Four habits prevent nearly all of them.
1. Acceptance criteria, written first
The scope is a list you can test: which fields, how many records, by when, with which alert. "Done" is that list going green, not a feeling at the end of a fortnight.
2. A working version early
You see the thing running against your own data before the last stretch, not a slide describing it. Corrections are cheap then; they are not later.
3. Change control with a line in the sand
Anything that does not match the criteria is a bug and is fixed at our cost. Anything that adds or alters the criteria is a change: its own scope and number, agreed before it is built.
4. A handover you can act on
Repository, credentials, a runbook written for the next person, and 30 days of fixes after delivery. If we have to be called to keep it alive, that is a design flaw, not a business model.
If the brief is unclear, we will say so and quote a small paid discovery instead of guessing at a big number. That fee comes off the build if you go ahead.
What we will not need
- A discovery call before you can see a price: ranges are already published.
- Your whole life story, or a 40-page brief. Eight lines and a sample.
- Credentials by email for anything you can grant as read-only or as a staging copy.
- A commitment to a retainer to get a project quoted.
Send it
Email the eight lines to hello@quietmason.com, or paste them into the form. You get a scope and one fixed number within one business day, or a plain "we are not the right fit" if the work is outside what we do.
Common questions
- What if I cannot answer all of these questions? Answer the first five and send a sample. Missing detail gets asked once, in writing, before a number is quoted — not discovered halfway through the build.
- How quickly do I get a quote? Within one business day of receiving the brief and a sample. Ranges are already published on the pricing page, so a fixed number is usually a refinement rather than a surprise.
- What access do you need? Read access to what the work depends on: an export, an API key or a read-only login, plus admin on the destination system. Credentials are never stored in source code and are rotated or revoked at handover.
- What counts as a change rather than a bug? Anything that does not match the written acceptance criteria is a bug and is fixed at our cost. Anything that adds or alters the criteria is a change: it gets its own scope and number before it is built.
- How do we know the finished work is what we asked for? The scope is written as acceptance criteria you can test, you see a working version before the last stretch, and acceptance is agreed against that list rather than against an impression.