CYVEXLY STUDIOAt a glance
A complete project in four stages
The exact deliverables change with scope, but every proposal should make these stages understandable.
- Stage
- Plan
- Primary decision
- What the site must accomplish
- Typical evidence
- Goals, audience, sitemap, content plan
- Owner involvement
- Confirm priorities and source material
- Stage
- Design
- Primary decision
- How the journey communicates
- Typical evidence
- Responsive layouts, hierarchy, interaction states
- Owner involvement
- Review the real content and decisions
- Stage
- Build
- Primary decision
- How the experience works
- Typical evidence
- Functional pages, forms, integrations, testing
- Owner involvement
- Supply account access and test key flows
- Stage
- Launch
- Primary decision
- What is ready to publish
- Typical evidence
- QA record, approvals, analytics, handoff
- Owner involvement
- Approve launch and retain account access
Cyvexly names the exact pages, features, review rounds, timeline, price, and acceptance points in the proposal for each project.
Stage 1
Planning turns a request into a buildable scope
A custom project should begin with the business decision the website needs to support: explain a service, build trust, generate inquiries, accept bookings, sell products, or coordinate a more complex workflow. That goal shapes the pages, content, features, and primary calls to action.
Cyvexly's baseline includes a defined goal and primary action plus a sitemap or page plan. Larger projects may require deeper discovery, content inventory, migration planning, user roles, acceptance criteria, or phased delivery.
Audience and decision
Who is the page for, what do they need to understand, and what useful next step should they be able to take?
Page and content plan
Which pages or reusable templates are needed, who supplies the source material, and what must be written, edited, migrated, or created?
Functional requirements
Which forms, accounts, booking, commerce, data, or integrations are truly required for launch?
Approval and acceptance
Who makes decisions, how review rounds work, and what evidence shows each stage is complete?
Stage 2
Design includes decisions beyond appearance
Custom design should organize real content, not decorate placeholder blocks. It defines hierarchy, navigation, page rhythm, trust signals, calls to action, and the states a visitor sees when something succeeds, fails, expands, or changes.
Cyvexly's package baseline includes custom styling aligned to the brand, responsive desktop/tablet/mobile behavior, and an accessible interaction and content target. Visual identity development, advanced motion, original photography, or illustration can be added when the project needs them.
Responsive behavior
The design must deliberately reflow across screen sizes rather than simply shrink a desktop composition.
Readable hierarchy
Headings, supporting copy, proof, and actions should help a buyer scan first and understand more when they continue.
Accessible interaction
Keyboard use, focus, labels, contrast, error explanation, motion preferences, and semantic structure belong in the experience—not in a last-minute checklist.
Stage 3
Development makes the promised journey real
The build should reproduce the approved system with maintainable components, real content, working navigation, functional forms, and honest success and failure states. Integrations should be tested against the accounts and permissions that will exist in production.
Cyvexly's baseline includes functional forms, clear confirmation and error states, essential page titles and descriptions for agreed pages, favicon and social-sharing direction, and an analytics connection when the client supplies or authorizes the account.
Content-complete pages
Real headings, images, links, forms, policies, and calls to action should be present before acceptance—not hidden behind a promise to finish later.
Production states
Loading, empty, invalid, successful, unavailable, and provider-failure states need understandable behavior where they apply.
Quality checks
Responsive layout, keyboard operation, form correction, metadata, links, performance, and key buyer paths should be tested in proportion to project risk.
Stage 4
Launch should include ownership and a clean handoff
Publishing is a controlled transition, not the moment a developer first discovers how the production environment behaves. Domain routing, security, forms, analytics, search controls, redirects, and third-party settings should be checked for the agreed scope.
Cyvexly's baseline includes a pre-launch review, client approval, handoff and ownership terms, launch support, and 14 days of post-launch defect support. Ongoing content, maintenance, and improvements are separate unless the proposal or a care plan includes them.
Accounts and access
The client should know which accounts they own, which credentials remain private, and how to reach the domain, hosting, analytics, content, and provider settings they need.
Definition of a defect
Post-launch defect support should cover agreed behavior that is not working; new pages, changed requirements, and ongoing content are different kinds of work.
Improvement path
A useful handoff identifies sensible next work without pretending every future idea belongs in the launch scope.
Read the exclusions
Items that often need separate scope
Full copywriting, large migrations, brand identity, original photography or video, translation, advanced animation, customer accounts, custom applications, accessibility remediation beyond the agreed build, and complex booking, commerce, CRM, email, or automation work are not safe to assume from the words “custom website.”
Domain, hosting, fonts, assets, provider subscriptions, payment-processing fees, and specialized legal or compliance work may also be billed by outside providers. A clear proposal names these boundaries and the person responsible for each prerequisite.
Keep in mind: If a proposal is silent about an important item, treat it as a question—not as an inclusion.
Before signing
Seven questions your proposal should answer
You should be able to answer these without reconstructing the project from emails or sales calls.
Outcome
What business goal and primary visitor action define success for this release?
Deliverables
Which pages, templates, features, integrations, and content services are included?
Responsibilities
What must the client and studio each supply, decide, approve, or configure?
Schedule
What are the stages, dependencies, review windows, and target launch conditions?
Price
What is the project fee, what is billed separately, and how are out-of-scope changes approved?
Ownership
Who owns the finished work and provider accounts, and what access is handed over?
After launch
What defect support, training, maintenance, and future improvement options are included or available?