The best questions to ask a fractional CTO test six things: relevant experience, how they would approach your product, whether they can build, how they communicate, what you will pay and how you would leave. Below are 20 questions grouped that way, each with what a good answer sounds like and the warning sign to listen for.
You won't get through all 20 on one call, and you shouldn't try. Send a few in writing beforehand, choose the five that matter most for the call itself and keep the rest for a follow-up. How the answers arrive tells you almost as much as what they say. For what it's worth, I would expect any founder to ask me every one of these.
Experience: has this fractional CTO done it before?
You are paying for judgment, and judgment comes from having shipped things and broken things.
1. What stage were the companies you led, and what did you ship there?
Good answer: stages close to yours, specific products or features they launched, and an honest split between what they did personally and what the team did.
Warning sign: only big-company titles when you are pre-launch, or a long list of roles with no product you could go and look at.
2. Tell me about a technical decision you got wrong. What did it cost?
Good answer: a specific story, such as a database choice that didn't hold up or a vendor they kept too long, plus what they do differently now.
Warning sign: “I can't think of one,” or a story in which the mistake was always someone else's.
3. Can I speak to two founders you have worked with, including one where it ended?
Good answer: yes, with introductions within a day or two. Keeping client names off a website because of NDAs is normal; a private reference call should still be possible.
Warning sign: no references at all, or only current clients who are still in the early, happy months.
Approach: how would they tackle your product?
These questions show whether they think before they prescribe.
4. What would you do in your first two weeks with us?
Good answer: get access, read the code and the vendor contracts, talk to you and ideally a few users, list the risks, find one or two quick wins and put a written plan in front of you.
Warning sign: a confident plan to rebuild everything, or a firm stack recommendation, before they have seen a line of your code.
5. How would you decide what to build first?
Good answer: start from the riskiest assumption and the core user journey, then cut. Expect them to suggest handling some features with manual work or off-the-shelf tools for now.
Warning sign: they want to build everything on your list, in the order you wrote it.
6. Which tech stack would you choose for us, and why?
Good answer: “It depends,” followed by what it depends on: your product, your hiring market, your budget and what already exists. Boring, well-supported defaults are a good sign.
Warning sign: the same favorite stack for every client, or something exotic that few developers in your market know.
7. When did you last tell a founder not to build something?
Good answer: a real example, like running an admin process from a spreadsheet for six months, or using an existing booking tool instead of building one.
Warning sign: they never have. A CTO who agrees with everything will spend your money agreeing.
Hands-on ability: can they actually build?
Skip this group if you only need advice and already have a strong team. If you need someone to build, it is the most important group here. Not sure which you need? Start with the difference between hands-on and advisory CTOs.
8. What have you personally built in the last year? Can you show me?
Good answer: they open a live product, walk you through the part they built and explain a trade-off they made along the way.
Warning sign: everything they mention was built by teams they managed years ago.
9. If a developer or agency sends you code, will you review it yourself?
Good answer: yes, and they describe how: pull requests, automated tests, a staging environment and coding standards the team agrees on.
Warning sign: “I trust the team,” with no review process behind it.
10. What do you set up for hosting, security and backups before launch?
Good answer: concrete basics: cloud accounts owned by the company, individual logins with two-factor authentication, automated backups that have been restored in a test, and monitoring that alerts a human when something breaks.
Warning sign: “Don't worry, it'll be secure,” with nothing specific behind it.
Communication: will you know what's going on?
In my experience, engagements go wrong in communication long before they go wrong in code.
11. What will I see from you every week?
Good answer: something specific and regular, such as a demo of working software and a short written update in plain English on a fixed day. In my own engagements, that is a demo every Friday.
Warning sign: “We'll catch up whenever you need.” That usually means you will be the one chasing.
12. How fast do you reply, and what happens if the product goes down?
Good answer: clear response times for normal messages, agreed overlap hours and a defined path for urgent incidents.
Warning sign: no clear answer, especially if replies during the sales process were already slow.
13. Can you explain a recent technical trade-off as if I were a customer?
Good answer: plain English, two or three options, the cost and risk of each, and a clear recommendation.
Warning sign: jargon, impatience or “you'll just have to trust me.”
Commercials: what exactly are you paying for?
Get these answers in writing. They become the backbone of your contract.
14. How do you charge, and what is included?
Good answer: a clear model (a monthly retainer, days per week or hourly), what is in and out of scope and how extra work is priced. For a benchmark, compare it with typical fractional CTO pricing.
Warning sign: a fee with no defined hours or deliverables, or a number that moves during the call.
15. How many clients do you have, and how many hours will we get?
Good answer: an honest number and a specific commitment, such as two days a week with set overlap hours.
Warning sign: a dodge, or a client count that can't add up to the hours they are promising you.
16. Do you earn anything from vendors, agencies or tools you recommend?
Good answer: a clear no, or full disclosure in writing with the freedom to choose another vendor.
Warning sign: hesitation, or “it doesn't affect my advice.”
17. Are you expecting equity, and on what terms?
Good answer: cash first, with any equity small, vested over time and tied to a long-term commitment. Here is how equity for a fractional CTO usually works.
Warning sign: a large stake up front, before any work has been done.
Exit: how would you leave cleanly?
Ask these while everyone is still friendly. They protect you on the day you need them.
18. Who will own the code, the accounts and the documentation?
Good answer: the company, from day one. Every account sits in the company's name, and the CTO works through their own login.
Warning sign: “I'll set it up under my account to save time.”
19. What does your handover look like if we part ways or hire a full-time CTO?
Good answer: current documentation, a transfer of credentials, knowledge-transfer sessions and help hiring or onboarding the successor.
Warning sign: “You won't need one,” or a plan that only exists in their head.
20. What is the notice period, and is there a minimum term?
Good answer: a short notice period that applies to both sides (often around 30 days) and, at most, a modest initial term during a build. The guide to fractional CTO contract terms covers the rest.
Warning sign: a long lock-in, or a large fee for ending early.
How to score a fractional CTO's answers
Right after each call, before the glow wears off, score each of the six groups from 1 to 3. Then weight them for your situation:
- No developers yet: hands-on ability counts double.
- A team or agency already in place: approach and communication count double.
- Raising soon: experience counts double, because investors will ask about it.
A low score on the exit questions rules someone out, however well the rest went. Compare your top one or two through a short paid discovery, the step in the full hiring process that tests work rather than talk. And keep the red flags that should end things early in front of you during every call.
The bottom line
A good first call with a fractional CTO feels like a working session, not a sales pitch. If they ask you sharp questions, give specific answers, admit what they got wrong and are clear about money and exits, you are probably talking to the right person. If you leave impressed but unable to say what they would actually do in their first month, keep looking.
Frequently asked questions
How long should a first call with a fractional CTO be?
Forty-five minutes to an hour is usually enough. Spend the first part on your product and goals, then cover the questions that matter most for your situation. Send a short written brief beforehand so the time goes on substance rather than background. If both sides want to continue, a short paid discovery is a better next step than a third or fourth call.
Should I give a fractional CTO a technical test?
Not a whiteboard puzzle. Senior people are better judged on real work. If you need a builder, ask them to walk you through a product they built and the decisions behind it. If you already have code, a short paid review of it is a fair test that also leaves you with something useful. A paid discovery is the strongest test of all, because it shows how they work with you.
What questions should a good fractional CTO ask me?
Expect questions about your customers, what you have already validated, your runway and budget, what exists in code and vendor contracts, your deadlines, who makes decisions and what success looks like in six months. A candidate who asks almost nothing and jumps straight to a solution is guessing. Good questions are one of the clearest signs that someone will build the right thing, not just the first thing you described.
How can I judge the answers if I'm not technical?
Listen for specifics and consistency rather than technical detail. Good answers include examples, numbers, trade-offs and honest uncertainty. Ask every candidate the same questions so you can compare, request a short written summary after the call and check what you heard against references. If you know an engineer you trust, invite them to one call. A paid discovery then shows whether the answers hold up in practice.