How Non-Technical CTOs Decide Which Mobile Projects to Fund

Seven projects are competing for a budget that covers three. The engineering teams have presented each one. Every one sounds important. The technical arguments are ones you cannot evaluate directly. The decision lands with you.

This is the default condition for a non-technical CTO. The projects are real, the budget constraint is real, and the decision cannot wait for a technical review that produces a ranking you could have predicted from the lobbying intensity. You need a framework that produces a defensible prioritization without requiring you to read the code.

The decision you are actually making

The funding decision is not a technical assessment. It is a risk and return decision made with incomplete information. That is true for every capital allocation decision a non-technical executive makes - it is not a deficiency, it is the nature of the role.

What the decision requires is not technical knowledge. It is a consistent framework applied to all proposals that surfaces the risk and return dimensions you can evaluate: business outcome, cost credibility, risk profile, and dependency exposure. A proposal that cannot answer those four questions with specifics is not ready to be funded, regardless of its technical merits.

The four inputs that matter

Business outcome. What specific metric does this project improve, and by how much? A project that cannot answer this question in one sentence is not ready for a funding decision. "Improve the user experience" is not a business outcome. "Reduce cart abandonment from 68 percent to 55 percent, adding $2.1 million in annual revenue at our current conversion value" is a business outcome.

Cost estimate credibility. How was the estimate derived, and what is the vendor's track record on similarly scoped projects? An estimate produced by a vendor who has delivered three projects of similar scope and size is more credible than an estimate produced by a vendor who has not. Ask for the reference.

Risk profile. What happens if this project is four weeks late? Eight weeks late? What happens if it delivers 70 percent of scope? A project with low business impact if late is a different risk than a project tied to a regulatory deadline or a product launch.

Dependency exposure. How many things outside the delivery team's control need to work for this project to succeed? Third-party API approvals, backend changes owned by another team, App Store review timelines, hardware delivery schedules - each dependency is a risk multiplier. Projects with more than two significant external dependencies require a dependency management plan before funding.

How to score without reading the code

Score each project on the four inputs using a simple scale: two points for a strong answer with specific evidence, one point for a qualified answer, zero for a vague or absent answer. Maximum score is eight.

Projects that score six or above are strong candidates for funding. Projects that score three or below have at least one unfundable gap - a missing business outcome, an unverifiable cost estimate, or a dependency exposure that has not been assessed.

Projects that score four or five are borderline. For those, ask one follow-up question for each dimension that scored below two. If the follow-up produces a strong answer, the score should increase. If it produces more vagueness, the score should not.

The projects that always look better than they are

Two project types consistently score well in presentations but underperform against their proposals: platform modernization and greenfield AI features.

Platform modernization projects look attractive because they address real technical debt and have a plausible long-term ROI story. They underperform because the benefit is diffuse (a faster, cleaner platform does not produce a measurable business outcome on a six-month horizon) and the scope is always larger than the initial estimate. A modernization project scoped at six months and $300,000 that delivers at twelve months and $520,000 is not unusual. Require a specific business outcome and a milestone-based payment structure before funding.

Greenfield AI features look attractive because they address the board mandate and have high strategic visibility. They underperform because they depend on capabilities that are not always present in the team being asked to deliver them. A vendor who has never shipped an AI feature in production will not produce a reliable estimate for one. Require a proof-of-concept phase before the full budget is committed.

How to defend the decision

A prioritization decision made with a consistent framework is defensible. A decision made by advocacy is not.

When the board asks why project four was funded instead of project two, the answer should be: project four scored higher on the business outcome dimension (specific metric, defensible estimate) and lower on the dependency exposure dimension than project two. Here is the scorecard.

That answer ends the conversation. An answer based on "the team made a strong case" does not.