What a CFO should expect from a CTO in real numbers

Why finance and engineering often talk past each other

Finance tracks money by month. Engineering tracks work by backlog, incidents, and release risk. They can look at the same problem and describe two different realities.

A cloud bill is a good example. Finance sees operating cost rising and gross margin getting squeezed. Engineering sees a traffic spike, a rushed launch, or a system that was built fast and now needs cleanup.

Hiring creates the same gap. A CFO asks whether two more engineers fit the budget. A CTO asks whether the team can hit a release date, keep uptime steady, and avoid burning people out. Those questions are tied together. Hiring plans, release dates, and infrastructure spend move as one.

Picture a SaaS team that promises a new enterprise feature for Q3. To ship on time, the team adds a vendor, increases cloud capacity, and delays platform cleanup. Finance sees spend go up. Engineering sees a deadline met. Three months later, both sides get the same surprise: support load rises, margins slip, and the next release looks less certain.

A CTO should give finance more than a list of features shipped. The job is to connect product decisions to business results.

That shared view usually comes down to four measures:

• infrastructure cost per customer or product line
• vendor dependence and renewal risk
• gross margin impact of engineering choices
• confidence level on delivery dates

When a CTO reports only output, trust starts to wear down. Finance hears progress but cannot tell whether that progress is getting cheaper to run, safer to support, or easier to predict. Engineering then ends up defending expenses one by one, which wastes time and pushes both teams into the wrong conversation.

Alignment starts when both sides use the same operating view. A release is a product event, a cost event, a margin event, and a planning event. Teams make better decisions when they treat it that way every month.

What a strong CTO should show in numbers

Handing finance a cloud invoice is not cost control. A good CTO shows how technical spending moves with revenue, product usage, and delivery speed.

Infrastructure spend makes more sense as a ratio than as a standalone bill. If hosting costs rise from $40,000 to $60,000, that number alone says very little. If revenue rises from $400,000 to $700,000 in the same period, the business may be getting more efficient, not less.

It also helps to split engineering costs into clear buckets: hosting and cloud services, tools and API usage, contractors or agencies, and support load tied to incidents and customer requests. That breakdown shows where the pressure actually comes from. A rising support bill after repeated outages tells a very different story from a higher cloud bill caused by healthy customer growth.

Unit costs are even more useful. For a SaaS product, cost per active customer or per 1,000 transactions says more than total spend. If one product line costs three times more to serve than another, finance can spot a pricing or packaging problem early.

The CTO should also explain what happens when usage grows faster than revenue. If product usage jumps 40% but revenue grows 15%, finance needs the dollar effect. Maybe the team underpriced a heavy-use plan. Maybe waste built up in the infrastructure. Maybe AI API usage expanded without limits. The explanation should sound like this: "If this trend continues for another quarter, gross margin drops from 72% to 66%."

Delivery numbers belong in the same report. Estimate accuracy and release slippage should be stated plainly: "We estimated six weeks and shipped in seven," or "Three of eight releases slipped by more than five business days." That tells a CFO whether the plan is reliable enough to support hiring, pricing, and cash decisions.

Once the same few numbers show up every month, finance stops guessing what engineering is doing.

How infrastructure spend changes gross margin

Gross margin gets muddy when infrastructure sits inside one big cloud bill. A good CTO splits that bill into two buckets right away: the base cost to keep the product running, and the cost that grows when customers use it more.

That distinction matters because fixed platform costs behave differently from usage costs. If your team spends $20,000 each month on the base stack and another $15,000 that rises with traffic, storage, or API calls, the margin story changes as volume changes. Finance can then see whether growth improves margin or simply pushes the bill up at the same speed.

The next step is to place costs where they belong. Product hosting, databases, bandwidth, and usage-based AI APIs usually sit in cost of goods sold because they are part of serving the customer every day. Internal dev tools, recruiting software, and back-office systems usually sit in operating expense because they support the company without scaling directly with product use. Shared tools need a simple rule for allocation, not guesswork.

Once the costs are mapped, waste becomes easier to spot. Idle servers, oversized databases, old backups nobody needs, and third-party APIs called more often than necessary all eat into margin. A CTO should point to the biggest leaks in plain numbers: "Unused storage costs $3,200 a month" or "A duplicate monitoring tool adds $18,000 a year."

Higher spend is not always bad. Extra database capacity before a big launch may protect revenue if it prevents outages or slow checkout flows. The same logic does not apply to forgotten test environments, duplicate vendors, or premium services nobody uses enough to justify the price.

Raw invoices rarely help a CFO make sense of this. Trend lines do. Cost per customer, cost per transaction, or infrastructure as a share of revenue over the last six to twelve months turns a noisy vendor bill into a margin story.

The point is simple: spend should support revenue or reduce risk in a way everyone can see. If it does neither, it deserves scrutiny.

What vendor control looks like in practice

A good CTO does not treat vendors as a pile of unrelated subscriptions. They manage them as part of the operating model.

Finance should be able to ask for one current view of every tool, who owns it, what it costs, when it renews, and whether the company can live without it. If that list does not exist, costs drift fast. Teams add tools during busy quarters, and nobody removes them later. Six months on, the company is paying for two monitoring products, three AI coding tools, and a contract that renews next week.

A healthy setup is boring in the best way. The CTO keeps a vendor register and reviews it every month or quarter. That register should show each vendor and internal owner, monthly or annual spend, renewal and notice dates, usage limits or seat caps, and how hard it would be to switch away.

That last part matters more than many CFOs expect. A cheap tool becomes expensive when the team builds half its workflow around it and cannot leave without a long rebuild. Teams should ask early whether they are buying a tool or locking themselves into its habits.

Good vendor control also means putting guardrails in place before spend jumps. Approval rules for new seats, API usage, storage growth, and premium add-ons keep costs from drifting upward without a reason. Duplicate tools should be removed quickly. If engineering uses one service for logs, another for alerts, and a third for dashboards, the CTO should explain why the split is worth the money.

Sometimes consolidation is the better move. In lean teams, a stack built around GitLab CI/CD, Sentry, and Grafana with Prometheus can replace several overlapping vendors. That will not fit every company, but the idea is straightforward: fewer tools, clearer ownership, fewer surprises.

Contract timing matters too. A CTO should review pricing, usage, and exit options before renewal deadlines arrive. That leaves enough time to renegotiate, downgrade, or leave.

How delivery predictability shows up in planning

Planning gets weak fast when dates are treated like promises instead of forecasts. A good CTO gives a date range, explains the confidence level, and updates it early when reality changes.

That range should come from team capacity, not optimism. If the team has six engineers but spends about 35% of its time on support tickets, production issues, and customer requests, the roadmap only has room for the other 65%. A plan that ignores support load might look tidy in a spreadsheet, but it falls apart during the month.

Small release batches make this easier to see. When a team ships one large feature after ten weeks, everyone learns about the delay too late. When the same work ships in smaller pieces every one or two weeks, finance can see drift early and adjust revenue timing, hiring, or vendor spend before the quarter gets messy.

A CTO does not need to bring finance into every ticket. What finance needs is a short update on what moved, why it moved, and what that change did to cost. If a release slipped by two weeks because the team had to fix billing errors in production, the CFO should hear whether that used existing staff time, added $8,000 in contractor hours, or delayed invoicing.

A few simple signals usually explain most missed dates: how much engineering time went to planned work versus interruptions, how many tasks got blocked and for how long, how much time the team spent redoing work, how often production issues changed the schedule, and how large each release batch was.

These numbers show whether the real problem is poor scoping, unstable requirements, vendor delays, or a product that needs more maintenance than expected.

Predictability does not mean perfect accuracy. It means surprises get smaller, tradeoffs get clearer, and both sides trust the plan a little more each month.

How to run a monthly CFO-CTO review

A monthly review does not need to be long. Forty-five minutes is often enough if the format stays the same.

Start with the three business numbers that already matter: revenue goals, margin targets, and cash limits. That puts engineering choices in the same frame the CFO already uses.

Use a shared dashboard and keep it simple enough to scan in two minutes. In most companies, one page is enough: revenue versus plan, gross margin trend, cloud and software spend versus budget, delivery status for the next 30 to 90 days, and a short note on cash impact.

Then review the three biggest cost drivers. In many software teams, those are cloud usage, outside vendors, and payroll tied to delivery delays. The point is not to inspect every invoice. The point is to see what moved, why it moved, and whether that change helped revenue, margin, or delivery speed.

After that, review the three biggest delivery risks. Keep them concrete. "Auth rewrite may push the enterprise launch by three weeks" is useful. "Engineering is busy" is not. The CFO needs to know what could slip, what that slip might cost, and whether extra spending would fix it.

Decision rules matter just as much as reporting. If every vendor change or infrastructure purchase needs approval, the CTO cannot move fast enough. If nothing needs approval, finance loses control. Set limits for contract size, headcount changes, and unexpected cloud spend above a threshold. Everything else stays with the CTO.

A SaaS company might agree on a simple split like this: the CTO can approve tooling changes under a monthly cap, shift workloads to lower hosting cost, and replace a weak vendor without a long meeting. The CFO signs off on new annual contracts, headcount changes, and any spend that cuts cash runway below the agreed floor.

End the meeting with owners, dates, and short notes. Write down who will do what by when, plus any number that needs a follow-up next month. If the same problem shows up three meetings in a row, the notes will usually show whether the issue is execution, planning, or a bad assumption.

That rhythm builds trust because both sides keep looking at the same numbers, risks, and decisions.

Example: a SaaS team with rising cloud costs

A SaaS company with 3,200 paying accounts watched its monthly cloud bill rise from $42,000 to $68,000 in six months. Revenue went up only 11%. At the same time, two planned releases slipped by about five weeks. The CFO saw one problem from two angles: cost kept rising while delivery kept moving.

The old report was almost useless. Finance got one large invoice with rough labels like app, data, and other. That made spend look like fixed overhead even though some of it came from specific product choices.

The CTO changed the view and grouped spend by product usage: core application traffic, storage and backups, AI jobs for one premium feature, and engineering tools and test environments.

That simple change exposed the real issue. The premium AI feature was used by only 14% of customers, but it drove 31% of infrastructure cost because it ran on an expensive managed queue and oversized compute during busy hours. Now the CFO could tie spend to a feature and see the margin impact instead of staring at one big cloud number.

One vendor change that cut spend

The next move was simple. The company moved logs from a costly hosted service to a lower-cost setup with the same retention period the team actually used. Engineers kept their dashboards and alerts. Support kept incident visibility. The monthly bill dropped by $7,500.

That worked because the team did not need a rewrite or a new process. They just stopped paying for features they barely used.

One roadmap reset that fixed planning

The roadmap had eight items committed for the next quarter even though the team had delivered only four or five items in each of the last three quarters. The CTO cut the committed plan to five items, moved the rest out of the quarter, and stopped assigning dates until each item had a clear owner, design, and dependency list.

Within two planning cycles, forecast accuracy improved from about 55% to 85%.

That gave the CFO a much cleaner view of the business: which feature drove cloud cost, where vendor spend could drop without hurting output, how delivery risk affected the quarter, and how infrastructure control connected to gross margin and planning confidence.

Mistakes that weaken trust

Trust breaks fast when finance treats engineering as one fixed cost bucket. Some costs stay fairly flat for a while, but cloud usage, support load, third-party APIs, and contractor spend often move with product demand and product choices. The CTO should separate costs that scale, costs that stay mostly fixed, and costs the team can remove.

Another common mistake is cutting cloud spend in isolation. A cheaper setup can look good for one month, then page speed drops, errors rise, and enterprise customers start asking uncomfortable questions. Saving $8,000 on infrastructure does not help if the company loses a $40,000 renewal because the product feels less reliable.

Tool sprawl causes the same damage in a quieter way. One team wants a new testing tool, another wants a data tool, and a third wants a separate monitoring stack. If nobody asks what business problem each tool solves, the company pays for overlap, extra training, and messy handoffs.

Delivery dates can turn trust into theater too. If product priorities change every week, exact delivery dates are fiction. A CTO should still commit to ranges, tradeoffs, and confidence levels. When a CFO hears a firm date that later slips, the real issue is often not engineering speed. It is that nobody protected the inputs.

Budget timing matters more than many teams admit. If everyone waits for annual planning to fix obvious waste, small leaks become normal behavior. An unused tool renews. A large instance keeps running after traffic drops. A duplicate vendor stays on the books because canceling it feels minor. After six months, those minor choices add up.

A healthier pattern is pretty simple. Review cost changes monthly, tie savings plans to service levels and customer impact, approve new tools only with a real use case and an owner, forecast delivery with ranges when requirements are still moving, and remove waste as soon as the team finds it.

Finance does not need perfect certainty from engineering. It needs honest reporting, quick course correction, and numbers that match reality. CTOs do not need unlimited freedom either. They need room to explain why one cost cut helps margin and another one damages the product.

A quick check before the next budget meeting

Budget meetings go faster when both sides test a few facts instead of arguing from instinct.

Start with cost clarity. The CTO should be able to name the three biggest cost drivers in plain language, with rough percentages and a short reason for each one. If most money goes to cloud compute, database usage, observability, or contractor time, finance should hear that in one minute, not after ten slides.

A quick test usually tells you whether the relationship is working:

• Can the CTO explain the top three cost drivers without technical jargon?
• Can finance name the vendors that would be painful or expensive to replace?
• Can both sides show how current spend changes gross margin over the next quarter?
• Does the roadmap show confidence ranges instead of fixed dates with false certainty?
• Does the meeting end with decisions, owners, and a follow-up date?

One weak answer does not mean the team is in trouble. Several weak answers usually mean finance and engineering are still working from different maps.

Vendor risk deserves extra attention because it hides inside normal operations. A cloud bill may look manageable today, but lock-in grows when one provider handles compute, database, queues, identity, and analytics all at once. The CTO does not need to remove every dependency. The job is to say which ones are easy to change, which ones are expensive to change, and why.

Margin should stay visible through the whole discussion. If engineering asks for another $20,000 a month, finance should know whether that protects revenue, cuts delivery time, or lowers support cost. If nobody can connect the spend to margin, the budget is still a guess.

The roadmap matters too. Dates alone create fake confidence. A better plan shows likely delivery windows and the assumptions behind them. That gives the CFO a cleaner way to plan cash, hiring, and board updates.

If the monthly review ends without a decision log, the same debate will be back next month.

What to do next

Start small. A CFO and CTO do not need a new planning system to work better together. They need one shared dashboard and one monthly meeting with the same numbers every time.

Keep the dashboard simple. Put infrastructure spend, vendor commitments and renewal dates, gross margin trend, and delivery accuracy against plan in one place. When those numbers sit on the same page, finance can see tradeoffs early instead of finding them after the quarter closes.

Use the first month to fix two things, not ten: one clear cost leak, such as idle cloud resources, overlapping tools, or unused licenses, and one planning habit, such as shipping dates without an owner or forecasts that never get updated.

Then leave the tool stack alone for a bit. Most teams do not need another reporting app. They need cleaner inputs, fewer surprises, and one habit of reviewing the same numbers every month.

If your team has strong engineers but nobody who connects architecture choices to margin and cash, outside help can close that gap quickly. Oleg Sotnikov at oleg.is works with startups and smaller companies as a fractional CTO and advisor, with a focus on product architecture, infrastructure cost control, and AI-first operations. That kind of support is useful when the business needs clearer tradeoffs without adding a heavy process.

The standard is not complicated: clear numbers, honest tradeoffs, fewer surprises, and a plan both finance and engineering can defend.