What a fractional CTO actually does in the first 30 days.

I get some version of the same question every time I start talking with a founder about fractional CTO work: what would you actually do? It's a fair question — "fractional CTO" gets used loosely enough that it's genuinely unclear whether you're hiring a part-time engineer, an advisor who shows up to meetings, or something else entirely. Here's what the first 30 days actually looks like, based on how I run it.

Week one is an assessment, not a fix

I go through the codebase, the infrastructure, and the deployment process before I touch anything. I'm looking for what's fragile, what's fine, and — just as important — what's fine for now but won't be at 10x the users. Founders are sometimes surprised I don't start making changes immediately. I'd rather understand the whole shape of the thing than fix the first problem I trip over and miss the bigger one two steps away.

I spend real time on the business, not just the code

What are you actually trying to prove in the next three months? Who are your users, and what do they need that they don't have yet? Technical priorities that aren't tied to the actual business goal are just busywork with good intentions. A big part of the job is translating "we need to move faster" into a specific, ordered list of what to fix first.

Quick wins happen early, on purpose

There are usually a handful of things — a missing backup strategy, an obvious security gap, a monitoring blind spot — that are fast to fix and meaningfully reduce risk. I do those in the first couple weeks, both because they matter and because trust gets built by showing real progress fast, not by talking about a six-month roadmap.

The bigger structural work gets sequenced, not rushed

Database redesigns, real CI/CD, proper environment separation — these take longer and touch more of the system, so they get planned deliberately rather than done in a rush that creates a new set of problems. I'd rather tell a founder honestly that something is a four-week project than pretend it's a weekend fix and deliver something fragile.

We settle into a rhythm

Fractional means I'm not there 40 hours a week, so we establish what needs a live conversation versus what can move async, and how decisions get made when I'm not in the room. The goal by day 30 isn't that I've fixed everything — it's that you know exactly what's actually going on with your technology, what the plan is, and that decisions aren't bottlenecked on me being available.

If there's one thing I'd want a founder to take away from this: the value isn't that I write code faster than you could hire someone else to. It's that I've seen this specific movie — prototype to real product — enough times to know which problems are urgent and which ones can wait, and I'd rather spend the first month proving that than guessing at it.