Questions a CFO Should Ask Before Approving a Website Budget

Website investment approval should rest on clear answers to a short set of questions about total cost, measurable benefit, delivery risk and what happens if the relationship ends. A CFO does not need to judge design or code; the job is to test whether the proposal is complete, whether the benefits are owned by someone, and whether the business can exit without losing what it paid for. This guide lists the questions to ask and what a good answer looks like.

What a finance approver is really deciding

A website proposal usually arrives as a vendor quote plus a short internal note. Behind it sit three decisions that finance is well placed to test:

• Is this the full cost? Build fees are often the smallest part of what the business will spend over the life of the site.
• Is the benefit real and owned? "A better brand presence" is not a benefit anyone can be held to.
• Is the risk understood? Delivery, security, compliance and dependency on one supplier are all financial exposures.

The CFO website questions below are grouped around those decisions, plus a fourth group on ownership and exit, which is the one most often skipped.

Questions on cost

1. What is the total cost of ownership over the expected life of the site?

A good answer separates one time costs (discovery, design, build, content migration, testing, launch) from recurring costs (hosting, software licences, plugins or apps, security monitoring, support, content updates, SEO and analytics) and estimates both over three to five years. It names who pays for each line and which budget it sits in.

A warning sign is a single build figure with "maintenance to be agreed".

2. What is driving the cost?

Website cost is driven by scope rather than by page count alone. The main drivers are the number of distinct templates, integrations with CRM, ERP or payment systems, the number of languages, content volume to migrate, custom functionality, accessibility and security requirements, and how many stakeholders need to approve each stage. A good answer ties each major cost to one of these drivers, so you can see what would change if scope changed.

3. What is fixed and what is variable?

Ask which parts of the quote are fixed price and which are time and materials, and what assumptions sit behind the fixed parts. A good answer lists assumptions explicitly, such as the number of templates or who supplies content, and explains how a change request is priced and approved.

4. How should the spend be treated in the accounts?

Website costs are not all treated the same way. Under IFRS, the interpretation SIC-32 on web site costs addresses when development spending can be recognised as an intangible asset and requires spending on promoting the entity's own products or services to be expensed. Ask the project team for a cost breakdown by stage so your auditors can advise on the treatment, and confirm VAT treatment of any supplier invoices with your tax adviser or the Federal Tax Authority.

Questions on benefits: the website business case

A website business case should connect the spend to outcomes that someone in the business will own after launch. Our guide to building the business case for an enterprise website covers the full structure; these are the questions a finance approver should test.

5. Which business outcomes will this change, and who owns them?

A good answer names two or three outcomes, such as qualified enquiries, online sales, reduced call centre volume, faster recruitment or fewer manual processes, and a named owner for each. It explains the mechanism: what the new site does differently that should move the number.

6. What is the baseline today?

If the current enquiry rate, conversion rate or support volume is not known, the benefit cannot be measured later. A good answer includes current figures from analytics and CRM, or a plan and budget to establish them before launch. An audit before the rebuild is often where these baselines come from.

7. When will benefits appear, and how will they be reported?

Benefits rarely appear on launch day. Search visibility takes time to build or recover, and process savings depend on staff adopting new tools. A good answer sets a realistic reporting cadence, such as quarterly, with defined measures and a review point where the business decides whether further digital investment is justified.

8. What happens if we do nothing?

The cost of delay is a legitimate part of the case: an unsupported platform, a security exposure, a site that cannot handle a new market or language, or manual work that grows with the business. A good answer describes these risks specifically rather than claiming the current site is "outdated".

Questions on risk

9. What could make this project late or over budget?

A good answer names the real risks for this project: content not ready, integration partners slow to respond, approvals across many departments, unclear requirements. It shows how each risk is managed and who owns it. A team that claims there are no material risks has not looked.

10. How will we protect existing traffic and revenue during the change?

For many organisations, the existing site already brings in enquiries or sales through search. A rebuild that breaks URLs or removes pages can cut that income for months. A good answer includes a migration plan with redirect mapping, pre launch checks and post launch monitoring. Our article on a decision framework for GCC website transformation discusses how to weigh this against the benefits of change.

11. What are the security and data protection obligations?

Websites that collect personal data through forms, accounts or payments carry legal obligations. In the UAE, the Personal Data Protection Law (Federal Decree-Law No. 45 of 2021) applies generally, and entities in the DIFC or ADGM have their own data protection regimes. Sector regulators may add more. A good answer identifies which apply, how the site will meet them, and confirms that legal counsel has reviewed the approach. Finance should not accept "the developer will handle it" on this point.

12. Who supports the site after launch, and to what standard?

A good answer defines support hours, response times for different severities, who monitors uptime and security, and how updates are tested. For sites that matter to revenue, a service level agreement is worth considering; we cover this in treating your website as a production system.

Questions on ownership and exit

This is where website budget approval most often goes wrong. A business can pay for a site and still not control it.

13. Who owns the code, design, content and accounts?

A good answer confirms in the contract that the business owns the custom code, design files and content, and that the domain, hosting, analytics, Search Console, CMS and third party software accounts are registered in the company's name with company controlled access.

14. Could another supplier take over if we needed to change?

A good answer describes a mainstream platform or well documented custom build, a handover pack (documentation, repository access, deployment steps, credentials held by the business) and no proprietary components that only the current supplier can maintain. If a proprietary element is proposed, ask what it costs to replace.

15. What are the contract terms on termination?

Ask about notice periods, handover obligations, licence terms that continue after termination, and whether any fees fall due on exit. A good answer makes leaving straightforward, even if nobody expects to.

Questions on governance during the project

16. Who can approve changes to scope and budget?

Most overruns come from many small decisions rather than one large one. A good answer names a single project sponsor with authority over scope, sets a threshold above which finance must approve a change, and describes how changes are logged with their cost and reason. Ask to see the change log at each steering meeting.

17. How will finance see progress before the money is spent?

A good answer links payments to delivered and accepted milestones rather than to dates alone, and provides a short regular report on spend against budget, open risks and decisions needed. If the supplier invoices on a calendar schedule regardless of progress, the business carries the delivery risk.

A quick reference table for the approval meeting

How to structure the website investment approval

Large digital investment does not have to be approved in one block. Consider staging it:

1. Approve discovery first. A short, separately priced discovery phase produces requirements, baselines, a content inventory and a firmer estimate.
2. Approve build against the discovery output. The build budget is then based on evidence rather than a sales estimate.
3. Approve the run budget with the build. Recurring costs should be agreed at the same time, so the site is not left without support after launch.
4. Set a benefits review. Agree a date when the owners report against the business case.

Hypothetical example: a Dubai based professional services firm receives a proposal for a new corporate website. The CFO asks the marketing director for total cost over four years, a list of integrations and the current enquiry baseline. The answers show that the CRM integration accounts for a large share of the build and that nobody currently tracks which enquiries come from the website. The firm approves a discovery phase and CRM tracking first, then approves the build two months later with a measurable baseline in place.

Bring the right questions to Codeeo

Codeeo works with finance, marketing and IT teams on website and digital investment decisions. Our website design and development and custom software and business systems teams can scope a project so each cost is tied to a clear driver, and a website audit can establish baselines before you commit to a full build. We have delivered more than 200 projects across the UAE and the US with a team of 80+ across Dubai, Riyadh and Karachi, and our office in Dubai means UAE approvers can meet the team in person. You can see examples of our work in our case studies, or contact Codeeo to talk through a proposal.