Business websites
A public-facing structure for an offer, its proof, its content and the enquiry route. It is not a signed-in account area.
Websites that work. Interfaces that make sense.
Business website development, customer portal development and internal business tools for people who need a clear build and a useful route back in after handover.
Discuss a request
TervuqScope before polishSupport after release
Signal / 01Offer: digital products for businessInquiry-only / USD estimates
Build the work. Leave a clear way back in.
A public website should explain the offer and make an enquiry easy. A permissioned portal should decide who sees a record before it presents an action. An internal tool should show what failed instead of leaving staff to guess.
Maker's markReadable interfacesPractical aftercare
Tervuq is a small digital studio in Austin. The work is scoped after an inquiry. There is no cart, checkout, payment screen or binding online quotation.
02 / Work we do
Four places where a confusing screen costs time.
Choose the kind of work closest to the problem. Public pages and account workflows need different scope questions. If you are unsure which applies, describe the action that is getting in the way.
See how an inquiry becomes defined workCustomer portals
A client portal development brief begins with roles, invitations and record visibility. The menu is not the authorization boundary.
Internal tools
Internal business tools put queues, filters, task states and useful failure messages around a real working process.
Technical support
Website technical support starts with a page address, a reproduction step and the distinction between a fault and a requested change.
What needs to move?
Static example / decimal units
100 visits/day × 3 page views/visit × 1.5 MB/page × 30 days ÷ 1000
The result is an estimate of page transfer generated by the entered page views. It is not server capacity, concurrency, a speed test or a price quote.
Edit the inputs30-day transfer13.5 GB
9,000 page views at the default inputs. Daily transfer is 0.45 GB.
The calculator excludes uploads, extra API traffic, bots and media outside the entered page weight. Caching is represented only if measured transferred bytes are entered.
04 / Handover and aftercare
Delivery is a point in the work, not the end of the conversation.
Signal / handoverAccess namedNext step visible
The useful support request is concrete. Send the page address and tell us what stopped working. Do not send passwords or confidential client records.
Define the first useful boundary.
We separate a new public website from a permissioned portal, and a visible fault from a change request. The distinction controls the questions we ask and the work we estimate.
Read the inquiry processReview the states a visitor will meet.
Empty results, invalid fields, denied access and failed saves need a place in the interface. A happy path alone is not a handover.
See website structureLeave a route for a later change.
For website maintenance in Austin, tell us which page needs attention. Investigation and later changes are agreed work, not an unlimited plan. Availability and response arrangements belong in the scope.
Understand support scope05 / Buying clearly
Ten screens are not ten equal pieces of work.
The count matters less than the permissions, content rules, integrations and states behind each screen.
A small business website may need a handful of public page types, redirects from an existing site and a content editing boundary. A customer portal may need invitations, recovery, role checks and a record that is unavailable to the wrong account. Those are different jobs even when both are called “a website” in a first message.
Tervuq will not turn an inquiry into an online order. The estimate basis is agreed scope in USD after the facts are clear. Any figure discussed before that is a working estimate, not a binding quote.
This is not for a buyer looking for a guaranteed revenue result, a fixed uptime promise or a generic template installed without a content decision. It suits a business that can describe the page, workflow or failure that needs to become less awkward.
06 / Start with the problemTervuq / inquiryOne useful next step
before any estimate
Tell us what should work differently.
Give the affected page address or the intended workflow. Describe the point where a person gets stuck. Do not include passwords or confidential records.
Tervuq / inquiryOne useful next stepbefore any estimate
Inquiry / 01Reply route required
Working example / request to result
A useful interface leaves fewer questions between actions.
Consider an illustrative request: a customer wants to know whether a submitted change has been received. The public website can explain how to ask. A portal can show the relevant account record. A staff interface can put that request into a queue. Support can investigate when the expected state fails to appear.
Those are related pieces of work, not an automatic package. The starting point is the smallest boundary that actually solves the problem.
One request, two views.
- Customer intention
- Ask for a change and understand whether the request reached the business. The interface must not label an unsaved message as received.
- Staff intention
- See the request in the appropriate queue and decide what action the role is allowed to take. Opening a record and changing it are separate permissions.
- Receipt state
- Show confirmation only after the system confirms storage. A network interruption needs a visible uncertainty state, not an optimistic check mark.
- Review boundary
- The business identifies what constitutes a complete request. Missing information should be named, and the person should not have to re-enter unrelated fields.
- Later support
- Report the action and the visible outcome without sharing private records. A reference and a safe reproduction description help separate an interface fault from an upstream delay.
This exercise describes interface decisions. It is not a client case study, a delivery promise or a scope automatically included with an inquiry.
Decision notes / before a build
Keep the source of truth out of the guesswork.
An interface can display a record without owning it. That distinction affects editing rights and what a support investigation can change. It also affects the estimate.
Where does the value come from?
A public service description may be entered directly into website content fields. An account status may come from an existing operational system. The same visual label can conceal very different responsibilities.
If an existing service supplies a record, the scope needs to say what happens when that service is unavailable or returns an older value. A loading indicator should not remain indefinitely without explanation. A stale value must not look like a newly confirmed update.
There may be no need to replace that existing system. A smaller interface around a defined workflow can be the right discussion, provided the connection and its limits are understood before development is estimated.
Who is allowed to change it?
The person who can read a status does not necessarily have permission to edit it. A customer can submit a request without directly modifying the underlying record. A staff member can review work without having account-management privileges.
Write these distinctions as actions, not broad job titles. “Can approve an assigned request” says more than “staff access.” The difference becomes especially useful when testing a rejected action or explaining why a control is unavailable.
For custom admin dashboard development, that working definition is more valuable than choosing how many summary panels should fill the first screen. Counts and charts only help when the underlying records mean something consistent.
Review notes / everyday use
Check the screen after the first click.
A good first impression cannot rescue a lost request. The review needs ordinary content and awkward content, not just the shortest label that happens to fit.
- Read the page without the photograph.
The offer and next action should still make sense. Photographs on this site illustrate interface concepts; they are not evidence of a named client delivery and they never carry the instructions a visitor needs to complete a task.
- Use the longest likely label.
A control that clips “Decline optional storage” has failed even if a short “OK” label fits. Layout decisions need room for meaningful text, and the narrow view must keep the label inside the control rather than treating overlap as a styling detail.
- Leave a required field incomplete.
The page should identify the field, preserve the useful input and explain the correction. Making a person reconstruct an entire inquiry because a reply address is missing creates work for no reason.
- Try the route without a pointer.
Keyboard order should follow the page's reading order. A visible focus state is part of the working interface, not optional decoration. Any pointer preview must leave the service link understandable when the preview is unavailable.
- Ask what a failed connection means.
An interrupted request must not be presented as a stored request. The page needs a truthful state and a direct alternative. Automatically retrying can create duplicate work, so recovery behavior belongs in the scope rather than being improvised after launch.
Practical aftercare / ownershipTervuqBuild with boundaries
Change with context
A later change needs a known starting point.
TervuqBuild with boundariesChange with context
A site can continue to look correct while an external dependency changes underneath it. An account invitation can stop arriving even though the acceptance page still works. Website troubleshooting needs to distinguish the visible symptom from the component that owns the failure.
Describe what you expected and what happened instead. If the behavior changed after an edit, name the edit. You do not have to diagnose the system before asking for support, and you should not send credentials in the first message to prove that the problem exists.
Investigation and subsequent changes are agreed work. A support inquiry does not silently authorize a rebuild, and a rebuild does not silently include every future maintenance task. The written scope is where the responsibility belongs.
For a full account of review responsibilities and acceptance boundaries, use the inquiry-to-handover process. For a fault in an existing page or interface, use the technical support route.
07 / Clear boundaries
Good interface work makes the awkward parts visible.
People do not experience a project as a sitemap or a component list. They experience a button that is hard to find, a form that clears itself, an invitation that expires, or a support request with no useful next step.
That is why the scope asks about states before decoration. It asks what a person can edit, what they can see, and what happens when the underlying connection refuses the request.
Public information stays public.
Websites explain. They carry page structure, editorial content, search-friendly headings and an enquiry journey. They do not pretend that a hidden menu makes private information safe.
For small business website design in Austin, start with the existing pages and who edits them. Then decide what needs to move and where an enquiry should land.
Account visibility is an explicit decision.
Portals restrict. Customer portal development starts with roles and records. Staff access needs the same checks. An account may see one record but not another, or read a state without being allowed to change it.
That distinction keeps a portal from becoming a public website with a password field attached.
Failures need language.
Working interfaces report. A failed save needs a message, not a mystery. A filtered queue needs an empty state. A support handover needs the browser, page address and reproduction step rather than a vague request to “check the site.”
These details are small to describe and expensive to ignore once people depend on them.
Built for a real business question.
The offer is websites, portals, internal tools and support. It is not hardware, hosting infrastructure, computer repair or an advertising campaign.
Scoped in USD after inquiry.
A price basis follows the work. Page structure and editing for a website. Roles and connections for a portal. States and integrations for an internal tool.
One clear next action.
Use the same route throughout: discuss a request. A submitted inquiry lets Tervuq understand the problem; it does not create an order or a binding quotation.