Custom Software Shops: Fractional CFO or a Controller First?

Fixed-bid and milestone contracts create work in progress that sits on the balance sheet as an asset before it becomes an invoice. A team that finishes 70% of a milestone by month end has earned revenue that hasn't been billed yet, and if nobody is tracking that, monthly numbers swing based on invoice timing instead of actual delivery. Retainer and time-and-materials work behaves differently again, with revenue tied to logged hours rather than deliverables. A shop running all three models at once, fixed-bid for one client, T&M for another, a retainer for a third, needs someone translating each into consistent monthly revenue, and that reconciliation work is where a controller earns their keep.

A fractional CFO looks past this month's invoices to the question of whether the business model itself is working: which contract type carries the best margin once developer time is fully loaded, whether the firm should push clients toward retainers for revenue predictability, and how much runway exists if a large client pauses a project. If your shop is deciding whether to bid on a project that would require hiring three more engineers, or negotiating payment terms on a contract large enough to affect cash flow for two quarters, that is a fractional CFO conversation about risk and capital, not a bookkeeping question.

A controller is the person who makes sure work in progress, unbilled revenue and contractor payables reconcile every month without drama, so the fractional CFO's forecasts are built on numbers that are actually right. If the shop mixes W-2 engineers with 1099 contractors, runs payroll on different schedules for each, and bills clients in a mix of currencies for distributed teams, someone needs to own that reconciliation as a full-time discipline rather than a monthly fire drill. A firm running multiple concurrent projects with different revenue recognition methods for each one usually needs a controller before it needs deeper strategic modeling, because strategy built on inaccurate numbers is worse than no strategy at all.

A controller's monthly close for a dev shop should cover these items:

• Reconcile work in progress and unbilled revenue, so fixed-bid milestones show earned revenue instead of swinging with invoice timing.
• Translate fixed-bid, time-and-materials and retainer contracts into consistent monthly revenue that a forecast can rely on.
• Reconcile contractor payables alongside W-2 payroll, especially when engineers are paid on different schedules or in different currencies.
• Recognize revenue as work is actually delivered, not on the day a milestone ships, so a strong quarter does not look mediocre.

The national median salary for accountants and auditors is $83,680 a year, and a full-time controller hire typically costs more than that once benefits and payroll taxes are added¹. If your shop is under roughly 20 people and running a handful of concurrent projects, a fractional CFO paired with outsourced bookkeeping usually covers both the strategic and the reconciliation work without that fixed cost. Past that size, with multiple project managers each owning their own client relationships and billing cadence, the reconciliation volume alone tends to justify a dedicated controller, with the fractional CFO staying on for the parts that require judgment rather than process.

Say the firm wants a line of credit to cover payroll during a slow quarter between projects. A bank evaluating that request will price it off the prime rate, which sits at 6.75% as of this year, plus a margin based on the firm's financials². A controller can produce the clean financial statements the bank wants to see. A fractional CFO is the one who decides whether taking on that debt makes sense given the pipeline, negotiates the terms, and models what happens to cash if the next quarter is slower than expected. Most growing shops eventually need both roles working together rather than choosing one permanently over the other.

A common error in project-based dev shops is recognizing revenue the day a milestone ships rather than as the underlying work was actually delivered, which can make a strong quarter look mediocre or a weak one look fine depending on when invoices happen to land relative to the calendar. Say a twelve-week engagement delivers roughly even value each week but only invoices at three milestones: recording revenue only at invoice dates will misstate every month that falls between them, even though the engineering team's output was steady the whole time. A controller who books revenue against actual delivery, using a percentage-of-completion approach for multi-month fixed-bid work, keeps the monthly numbers honest regardless of when the invoice happens to go out. That distinction rarely matters for a single small project, but across a dozen concurrent engagements it is often the difference between a monthly close that reflects reality and one that just reflects billing timing.