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 should you 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 do we make sure it lands?
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.
Which band is the budget in?
A band is not a quote, and picking one does not commit anyone. It saves a week of email: it tells us whether the work fits before we write a scope, and it tells you whether this is a conversation worth starting.
Under $500
A defined fix, a landing page, a single workflow on a schedule, or an audit of what is stopping the site being indexed.
Not in this band: a store build, or a migration with a large URL map.
$500 to $1,500
A landing page with speed work behind it, a migration, the first version of a store, or one workflow plus the reporting around it.
Not in this band: a pipeline that has to stay correct every week with alerting.
$1,500 to $3,000
A scraping or enrichment pipeline with monitoring, an integration between three to six systems, or a small catalog that takes orders.
Watch for: each extra source adds time, and anti-bot pressure is what moves a collection price.
$3,000 to $5,000
Multi-source work with alerting and a runbook, a build that has to survive its first quarter, or a store plus the care plan around it.
What it buys: fewer assumptions. More time goes into acceptance criteria and testing, not more features.
Over $5,000
A program rather than a task: build, migration and monitoring together, a larger catalog, or work split into milestones you approve one at a time.
How it runs: half up front and half on handover, milestones above $3,000, each one approved before it starts.
No band yet
Write that. Half the briefs that arrive have no number in them, and the honest answer is usually that the scope is the thing that is missing.
What happens next: if the scope is still unclear after one exchange, we quote a small paid discovery instead of guessing at a large number. That fee comes off the build if you go ahead.
What do we 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 [email protected], 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
These are the questions that come up before a brief is written, answered in the order they arrive. Each one is settled before quoting, so the number at the end of the brief is the number on the invoice.
- 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.