Service / Scope consultationVexbun / Austin, Texas

Define the web task before you fund the build.

Our website scope consultation gives a business with an unclear web request a written direction for the work. Vexbun is a small digital studio in Austin, Texas. We separate the outcome you need from the adjacent work you do not need to commission yet.

Quotation basis / USDQuoted after the request and existing material are reviewed. The amount depends on what needs examination and the decision the consultation must support. No published flat rate or implementation fee is implied.

Send a brief

Inquiry only. Timing and the consultation boundary are agreed before work begins.

Annotated scope board beside a web page outline
A scope made visibleWorking-method illustration

Website scope consultation: the written direction.

A useful scope note gives you a proposed task to accept or question. It does not hide a redesign inside a diagnosis. The written direction records what can proceed and what still needs an answer.

Consultation output / Written scope direction
PartWhat it recordsWhat you can decide
Proposed taskThe page or route under discussion and the change being considered, described separately from the business outcome.Whether this is the work you actually want to commission.
AssumptionsWhat the direction relies on, including available content, access and the behaviour of connected systems.Which points need confirmation before an implementation quote.
ExclusionsAdjacent pages or activities that sit outside the proposed task, even when they affect the same visitor journey.Whether the boundary is useful or needs to be redrawn.
Next decisionThe unresolved choice that prevents the task from being quoted or accepted as implementation work.Who needs to answer it and what information is still missing.

The record describes the proposed work. It is not a technical specification for unexamined systems.

Review inputs / One route

Point to the decision, not the whole site.

One web user route isolated from surrounding branches
One route, with its neighbours left visibleReview input

“Improve our website” leaves every decision open. “Help visitors understand which inquiry form to use” gives a one-off web design consultation a place to begin.

Send an existing URL if there is one. Say what a visitor should be able to do and where the current route stops making sense. A screenshot can show a visual fault, but a route description explains how someone arrives at it. We need that distinction before calling a layout change the answer.

Include a real deadline and explain what sets it. A campaign date is a constraint; a hoped-for launch is a preference. Neither becomes a delivery commitment just because it appears in the first message. We agree the timing after the material has been reviewed.

Existing material
A public URL, a page outline or relevant screenshots. Remove private information before sharing.
Intended outcome
The visitor action or internal decision the short website project needs to support.
Fixed constraint
A deadline, a platform that must stay in use or a piece of content that cannot change.
Sign-off owner
The person who can accept the boundary, rather than a list of people who might comment later.

Do not send login credentials in an inquiry or chat. If access is needed for agreed work, the access arrangement belongs in that work's preparation, not in a public message field.

Diagnosis is not a build instruction.

A website scope consultation can identify a decision without authorizing a change. Keeping those apart protects a small request from becoming an unfinished implementation.

Observation / Example

A page offers competing contact actions. The visible issue may be the labels, but the underlying decision is whether those actions serve different requests. Moving a button does not answer that question.

Scope direction / Example

Confirm the purpose of each contact route before choosing a layout. Propose work on the relevant page only; leave changes to routing rules outside the boundary until responsibility for those rules is clear.

This is an illustrative distinction, not a client result. A direction can remain conditional where the evidence is incomplete. We name the missing answer rather than turn a guess into a task someone else is expected to implement.

From request to written direction

Agree the review before it begins.

The consultation has its own boundary. You are not authorizing a build by asking for a clearer brief.

  1. Send the request.

    The first message identifies the material and the outcome. We look at whether a defined consultation can address the uncertainty or whether the request needs a different service.

  2. Agree the consultation.

    Before the review starts, confirm what is being examined, the quotation and timing. Any unavailable material is named so the review does not depend on access or content that nobody has supplied.

  3. Review the decision.

    The work separates what can be observed from what still needs an answer. A dependency on a form handler, for example, is not treated as a visual design decision simply because it appears on the same page.

  4. Receive the scope direction.

    The written note states the proposed task and its assumptions, with exclusions and the next decision. Implementation is quoted only against a sufficiently defined request and accepted separately.

Send a brief

Useful when the task is still unclear.

  • You know the outcome but cannot yet describe the work.Separate the business aim from the page change.
  • Several requests are being treated as one small project.Make their dependencies visible before commissioning them.
  • You need a written direction for a decision-maker.Give sign-off a defined object rather than a broad discussion.
  • You want to decide whether implementation is justified.Consultation does not commit you to the subsequent build.

Not an open-ended audit.

This service does not promise a complete review of every route, a legal compliance opinion or a security assessment. A broad product strategy needs more than a bounded consultation. If the useful decision cannot be isolated, the request needs a wider agreement.

A fixed implementation instruction may not need this step. The focused web build covers an agreed page or route. The precision pass addresses a stated issue on an existing page.

Before the inquiry

Practical questions, direct answers.

There is no standard session length hidden behind the service name. What the consultation needs to examine determines the agreement.

Do I need a live website?

No. If there is no existing URL, send the material you have and describe the page or route you intend to create. Missing material becomes an explicit assumption, not a reason to invent the finished scope.

Does consultation include making the changes?

No. The deliverable is a written scope direction. Implementation needs a separate accepted scope and quotation; a diagnosis is not an instruction to change a live website.

The note should make the next decision clearer even if you choose not to proceed. It does not promise production files or authorize changes to connected systems.

How long is the consultation?

There is no published standard duration. Timing is agreed after the request and material are reviewed. State any real deadline and what depends on it so the review can address that constraint.

What if I already know exactly what to build?

A focused web build may be the more direct route. Send the defined page, supplied assets and approval boundary. If the work is a correction to an existing page, consider a precision pass instead.

Compare service boundaries

A defined starting point

Make the next web decision a smaller one.

Send the page you are considering and the outcome it needs to support. We will use that request to establish whether a scope consultation is the right piece of work to quote.

Send a brief