Services / Defined website workAustin, Texas, United States

Website services for one defined piece of work.

Website scope consultation, a focused website build or a website refinement service for an existing business. Vexbun handles contained digital work, with the output agreed before implementation begins.

Price basis / Written quotation

Send a brief

Each service is quoted for the actual request. Consultation depends on the material under review; a build depends on the route and assets; a precision pass depends on the issue list and accepted corrections. No fixed prices are published.

This is an inquiry catalogue, not a package shop. Choosing a service opens a conversation. It does not book a slot, authorize work or create a payment obligation.

Compare the service boundaries

Decision first / Website scope consultation

Scope consultation

One navigation section selected for scope review — Select the decision, not the whole websiteReview method illustration

For a request that is clear about the problem but not yet clear about the work.

A navigation complaint may be a labelling problem rather than a reason to replace the header. An underused page may need its purpose settled before its layout is touched. A one-off web design consultation separates the requested outcome from a proposed solution that has not been tested against the brief.

The material is your current page or outline, not an invented business scenario. We examine the request and write a direction that names the task and the assumptions it relies on. You can challenge those assumptions before deciding whether implementation is the right next step.

Useful input: An existing URL or page material, the outcome you want and a real deadline if one applies. Identify the decision you cannot currently make.
Output: A written scope direction with a proposed task, assumptions, exclusions and the decision needed before an implementation quotation.
Boundary: A defined review, not a full website audit. Design production and code changes require their own accepted scope.
Best fit: A business deciding what a short website project should include before committing to a build.

Quotation basisQuoted after the request and existing material are reviewed. The depth of the decision and the material needed to resolve it shape the quote; there is no published standard consultation duration.

Send a brief Read the consultation scope

Defined implementation / Responsive web page build

Focused web build

Web layout checked at a tablet breakpoint — A layout change is part of the routeResponsive method illustration

For a page or route whose job is already understood and whose limits can be written down.

Designing a one-page website still involves content decisions and interface behaviour. A long heading changes the composition. A form needs a useful failure state, not just an attractive empty field. Those details belong to the named route when they are part of the agreed task.

A focused website build takes supplied material into a contained output. The scope identifies which assets are ready, which content remains your responsibility and who will accept the finished work. Responsive treatment is included in the defined build; additional routes are not implied by a link appearing in the design.

Useful input: The named page or route, approved or draft content clearly identified, available visual assets, relevant constraints and the person responsible for approval.
Output: The agreed page, route or small interface change with responsive treatment and content placement, prepared for the handoff described in the project agreement.
Boundary: No silent addition of hosting, continuing maintenance or subscriptions. A new route or changed requirement needs an explicit scope decision.
Best fit: A business that needs a specific piece built, rather than an ongoing product development arrangement.

Quotation basisQuoted against the named route, assets, and approval boundary. A small page count is not a flat-rate promise: interaction states and content readiness can change the amount of work.

Send a brief Read the build scope

Existing interface / Targeted website fixes

Precision pass

Spacing inspection around a web page action — Inspect the fault at component scaleCorrection method illustration

For an existing website that needs a particular fault understood and a correction kept in bounds.

A button can look correct until its label wraps. A menu can work with a mouse but leave a touch user without the same choice. These are examples of concrete interface faults, not evidence that the entire site needs replacing.

This website refinement service begins with the page and stated issue. A targeted UX review for an existing website records the relevant findings; the changes you accept are a separate part of the scope. Finding another issue does not authorize its correction or turn the engagement into a full audit.

Useful input: The page URL, what you expected to happen, what happens instead and the device or interaction involved. A screenshot can clarify a visible issue without sharing private account data.
Output: Findings about the stated issue and the corrections expressly agreed, with the requested change separated from unrelated observations.
Boundary: Not a complete accessibility or security audit, a legal compliance certification, or an undertaking to improve search rankings.
Best fit: A business keeping an existing site and seeking targeted website fixes rather than a fresh build.

Quotation basisQuoted against the page, issue list, and correction boundary. Access constraints or a dependency on an existing component can affect what can be corrected within the request.

Send a brief Read the precision pass scope

Scope record / Compare before inquiring

Different requests need different outputs.

Use the unresolved decision as the dividing line. If you cannot define the work, consultation is the place to begin. If the route is agreed, consider a build. If the page exists and the fault is specific, look at the precision pass.

Service comparison: input, output, excluded work and quotation basis
Request type	What to send	Decision or output	Excluded work	Quotation basis
Scope consultation	A current URL or outline, desired outcome and any fixed deadline.	Written direction naming the proposed scope and the decision still needed.	Implementation and a whole-site audit are not included by implication.	Request and existing material, reviewed before quotation.
Focused web build	A named route, available assets and content, with an approval owner.	The agreed responsive page or interface change and its handoff.	Additional routes, ongoing maintenance and hosting unless explicitly agreed.	Route, assets and the accepted approval boundary.
Precision pass	A page URL and issue list explaining the expected and actual behaviour.	Relevant findings and only the corrections accepted into scope.	Unrelated fixes and full accessibility, security or legal audits.	Page, issue list and the correction boundary.

On a narrow screen, scroll the comparison horizontally inside its frame. All services require a written scope and quotation; this table is not a binding offer.

Agreement / Before the work

The sequence starts with a review, not a purchase.

Submit the request.
Choose a service if one fits. Otherwise explain the problem without forcing it into a label. The inquiry is material for review, not approval to start.
Settle the boundary.
We identify what can be addressed and what depends on missing material or a decision from you. This is where a vague request becomes a task that can be quoted.
Agree the work and timing.
The written scope sets the output and the quotation. A requested deadline is considered alongside content readiness and dependencies; it is not automatically accepted.
Review the agreed output.
The work is handed over against that scope. New requests are distinguished from any correction obligations set out in the project agreement.

Fit / Keep the commitment proportionate

A narrow brief is useful. An artificial one is not.

If several connected routes need rebuilding, dividing the description into small phrases does not make it a short project. The same applies when nobody can approve the content. We would rather clarify that dependency than quote a task whose finish keeps moving.

You do not need polished technical language to inquire. “This action disappears on my phone” identifies a real issue. “Make the site modern” still leaves the output undecided and is better approached as a scope question.

Existing design and code can be part of the material under review. Whether a change can be made within that system depends on access and its constraints, not on a promise that every existing platform is suitable.

No service carries a site-level delivery-time or commercial-result guarantee. The guarantee terms explain that distinction; the accepted project agreement governs the actual obligations.

How Vexbun keeps projects bounded

Your request / No package purchase

Bring the problem. We can discuss the right scope.

Use the inquiry form to share the relevant URL and what needs to change. Selecting a service only identifies your interest; it does not accept terms of work or permit optional advertising storage.

Send a brief