FAQ
Questions worth answering before the build.
Clear expectations reduce rework. These answers describe the default approach; the project contract and proposal govern any specific engagement.
Common questions
Practical answers, no invented promises.
Timing and deliverables depend on actual scope and content readiness, so this page avoids fixed turnaround claims that may not apply to a specific project.
How long does a website take?
Timing depends on scope, content readiness, review speed, integrations and migration complexity. A focused information site is generally simpler than a store or integration-heavy build, but the agreed project plan should set the real expectation.
Will the website be mobile-friendly?
Yes. Mobile is treated as a primary layout and tested as part of acceptance rather than being reduced from desktop at the end.
Can I update the site myself?
When self-editing is part of the brief, the implementation should support it with an appropriate maintained platform or editing model. The ownership requirement should be agreed before the stack is selected.
Do you provide hosting and support?
CubeGraphiX can help configure deployment, DNS, launch and ongoing care where those items are included. Accounts and ownership should remain clear and documented.
Can you redesign an existing website?
Yes. A redesign should preserve what already works, identify measurable friction or maintainability problems and replace only the parts that justify change.
What if I need changes later?
A maintainable site should support future changes. Small content/design changes are different from new functionality that materially changes scope, dependencies or the project contract.
Do you guarantee search rankings or sales?
No. The website can improve technical foundations, clarity, conversion paths and measurement, but rankings, traffic, sales and business outcomes depend on factors outside the website alone.
Can you use my existing hosting, domain or tools?
Often yes. Existing tools should be evaluated before replacing them. If they are maintained, secure and suitable for the required contract, keeping them may be simpler and lower-risk.
Do you build custom systems?
Only when the requirement cannot be met adequately with native platform capability, the existing stack or a maintained solution. Custom code is treated as a maintenance cost and used for the unsolved remainder.
What do you need from me to start?
At minimum: the business objective, audience, services/products, existing site/domain context, available content/assets, required actions and any known constraints. The discovery step identifies what else is genuinely necessary.
Still unclear?
Ask the specific question that changes your decision.
We can answer it before you commit to unnecessary scope.