Faberluna Decisions, not decks.

You need a CTO.
You don’t need a full-time one yet.

I’ve held the job — most recently as CTO of Oberon Security, where I built agentic AI for incident triage that matched analyst-labeled ground truth about 90% of the time. Before that, 23 years at Microsoft: eight building, fifteen leading engineering teams.

I embed two to three days a week and own the technical calls — architecture, hiring, roadmap, and whether what you’re building will survive production.

Not a report. Not a recommendation. Accountability.

Microsoft 2000–2023 · CTO, Oberon Security · M.S. CS, Ohio State

Fixed reference

Engagements

Three ways to work together.

The first is the one most engagements become. The other two are how they start — fixed scope, fixed price, agreed before work begins.

Fractional CTO

For founders with a team already shipping, who need senior technical judgment they can’t yet justify hiring full-time.

Two to three days a week, embedded. I own architecture decisions, technical hiring, roadmap feasibility, model and vendor calls, and the evaluation strategy that tells you whether any of it is working. I’m the technical voice in your board conversations.

Most engagements run six to eighteen months and end when you hire the full-time CTO or VP Engineering — a search I’ll run with you.

Ongoing Monthly retainer Pricing on the intro call Reviewed quarterly 30 days’ notice, either way

AI Audit

For teams with something already built that they can’t confidently assess.

I review the system end to end — architecture, retrieval, prompts, model selection, evaluation — and give you a written assessment covering cost, latency, reliability and quality. Where it’s over-built, I say so. Where it will break under real traffic, I say when.

You keep the document whether or not we work together again. This is also how most retainers start: a week is long enough to see how I think, and cheap enough that neither of us commits on the strength of one call.

1 week Fixed price Pricing on the intro call Written assessment

Prototype Sprint

For teams who know what they want to build and need it built properly the first time.

Four weeks alongside your engineers, taking one AI feature from idea to something that runs in production — with the evaluation harness that proves it works and the documentation that lets your team own it afterwards.

Your engineers write the code. I set the architecture, build the evaluation, and make sure what ships is maintainable by people who aren’t me.

4 weeks Fixed price Pricing on the intro call Ships to production

How this works

Two to three days a week, embedded.

Weekly cadence with leadership. Reviewed every quarter. Not a fixed end date, but not open-ended either — long enough that I own the consequences of my own decisions, short enough that I’m working toward my replacement from the start.

What I own

  • Architecture decisions, and the trade-offs behind them
  • Technical hiring — scoping roles, interviewing, closing
  • Roadmap feasibility, and saying no when a date isn’t real
  • Model, vendor, and build-vs-buy calls
  • Evaluation strategy: how we know whether it works
  • The technical conversation with your board and investors

What stays with your team

  • Day-to-day delivery and sprint execution
  • Code ownership — your engineers write it, not me
  • Product direction and prioritization
  • On-call and operational response

I don’t take the keyboard away from your team. If I’m writing production code, something has gone wrong with the engagement.

How it starts

  • A 30-minute intro call — what you’re building, where it’s stuck, whether I’m useful
  • A one-week audit, fixed price, yours to keep
  • A retainer, if it fits

How it ends

  • When your team can make the calls I was making
  • Usually a full-time CTO or VP Engineering hire — I’ll run that search with you
  • You keep everything: decision records, evaluation harnesses, runbooks, scorecards
  • No proprietary tooling you can’t maintain

About

Twenty-six years building software.
Three of them deciding what other people should build.

2000 – 2008Software Engineer · Microsoft — eight years writing code
2008 – 2023Engineering Manager · Microsoft — fifteen years leading teams
2024 – 2025CTO · Oberon Security — agentic AI for incident triage
2025 →Founder · Faberluna

At Oberon I built an agentic AI system for security incident triage. It matched analyst-labeled ground truth about 90% of the time. I lead with that number deliberately — it’s the question you should be asking about any AI system someone wants to build for you, and it’s the question most of them can’t answer.

The smallest model that works.

Most AI features are over-provisioned. The interesting engineering is usually in retrieval, evaluation, and the parts nobody demos — not in reaching for a larger model.

Production constraints from day one.

Latency, cost and failure modes aren’t things you optimize later. They’re the design. A prototype that ignores them isn’t 80% done — it’s a different system.

If you can’t measure it, you haven’t shipped it.

Agreement rates, regression suites, labeled ground truth. Without these you don’t have a product — you have a demo that’s currently working.

I’d rather you didn’t need me.

The point of a fractional CTO is to make the role unnecessary, by building the team, the decisions and the documentation that outlast the engagement. I’m not trying to become load-bearing.

Background

  • M.S. Computer Science · The Ohio State University
  • B.S. Applied Mathematics · Kyiv Polytechnic Institute

The applied math degree is probably why I think in ground truth and agreement rates rather than in demos.

Who this is for

Founders and CEOs with an engineering team already shipping, who need senior technical judgment they can’t yet justify hiring full-time.

I’m not the right fit for pre-seed companies without an established engineering function, or for projects that want a demo chatbot rather than a production system. If that’s where you are, I’ll say so on the first call rather than three months in.

Questions

The ones worth asking.

How is this different from hiring a consultant?

A consultant gives you a recommendation and leaves. I make the decision and live with it.

If I tell you to build on a particular architecture and it turns out to be wrong in month four, I’m still there in month four. That’s the whole difference, and it changes what advice you get — nobody recommends the clever risky thing when they’ll personally own the consequences.

How can anyone be a CTO two days a week?

For a team of six to thirty engineers, the CTO job is mostly decisions, hiring and unblocking — not volume. Two days of genuine senior attention usually beats five days of someone learning the role.

It stops working somewhere around forty engineers, or when the company hits a real crisis. I’ll tell you when you’ve reached that point. It’s the same conversation as telling you to hire my replacement.

Won’t this undermine my lead engineer?

It’s the most common way these engagements fail, so it’s worth being direct.

I’m not there to outrank your best engineer. In most cases the right outcome is that they grow into the role and I leave. I’ll say that to them, in the first week, without you asking.

What I won’t do is quietly take technical authority away from someone who’s earned it. If your lead engineer is capable and just needs support, tell me — that’s a different and usually shorter engagement.

Do you write code?

Rarely, and deliberately. I read a lot of it.

I’ll build evaluation harnesses and prototypes to settle an argument, because arguing about whether something will work is usually slower than finding out. But if I’m writing production code, either the engagement is scoped wrong or you have a hiring problem I should be solving instead.

Eight of my 23 years at Microsoft were spent as an engineer, so I can still do it. That’s not what you’re paying for.

Are you going to tell us to rebuild everything?

Almost never. Rebuilds are what people recommend when they don’t understand the existing system well enough to fix it.

The most common finding in an audit is that the system is over-built — too large a model, too much retrieval, too many moving parts — and that the fix is subtraction.

Why not just hire a full-time CTO?

If you can, do. A full-time CTO committed to your company will beat me on availability and context every time.

The reasons founders don’t usually come down to three: you can’t afford the compensation yet, you’re not sure what you need so a wrong hire is expensive, or you need someone now and a good search takes five months. Fractional solves all three — and none of them permanently.

How many clients do you take at once?

Few enough that two to three days each is real. Ask me on the intro call and I’ll tell you exactly how many and what they are — sector, not names.

I won’t take a direct competitor to an existing client, and I’ll tell you if a prospective one appears.

What if it isn’t working?

Thirty days’ notice, either direction, no penalty. You keep everything produced up to that point.

I’d rather end an engagement in month three than have you spend a year being politely dissatisfied. If I’m not earning the retainer, I’d genuinely rather know.

Who owns what you produce?

You do — all of it. Architecture decision records, evaluation harnesses, runbooks, interview scorecards, code. No proprietary tooling, no licensing, nothing you can’t maintain after I’ve gone.

I’ll sign your NDA.

Do you only do AI work?

It’s most of it, and it’s where the current demand is. But the job is technical leadership — if what you actually need is help with hiring, infrastructure cost, or an architecture that has nothing to do with models, that’s still the job.

What I won’t do is take an AI engagement where the honest answer is that you don’t need AI. I’ll say that on the first call.

What size company do you work with?

Roughly a Series A to Series B shape: an engineering team already shipping, real users, and technical decisions that are starting to have consequences.

I’m not a fit for pre-seed companies without an established engineering function. There isn’t enough for a CTO to do, and you’d be paying me to invent work.