This matters before we get to the questions themselves.

You're not interviewing for a job. There are no right or wrong answers in the conventional sense. What you're doing is gathering signal — trying to understand how this person thinks, how they'll behave under pressure, and whether your working relationship will be generative or grinding.

As a non-technical founder, you can't assess whether someone's architectural decisions are correct. But you absolutely can assess whether their thinking is clear, whether they consider trade-offs honestly, and whether they treat your non-technical perspective with respect or mild contempt. Those things are fully within your ability to evaluate — and they matter at least as much as technical skill.

Listen for: curiosity, honesty about limitations, genuine product thinking, and the willingness to say "I don't know but here's how I'd find out." Be wary of: overconfidence, dismissiveness, an allergy to business context, and anyone who makes you feel stupid for asking reasonable questions.

With that framing in place — here are the questions.

"What's the riskiest technical assumption in what I'm building?"

This is probably the single most valuable question on this list. A strong technical cofounder will be able to identify the thing most likely to break your product before it's built — the integration that's harder than it looks, the scalability issue that'll arrive at exactly the wrong moment, the third-party dependency that could pull the rug out. Someone who answers this with "I don't think there are any major risks" either hasn't thought about it properly or isn't being honest with you. Neither is what you want.

‍

"If you had to build an MVP in eight weeks with a £30,000 budget, what would you cut?"

Constraints reveal thinking. You want someone who can make pragmatic trade-offs — who understands that an MVP's job is to answer one question ("will people pay for this?") and that everything else is optional until that question is answered. An answer that protects the technical elegance while sacrificing user-facing functionality tells you something. An answer that ruthlessly prioritises what a user actually needs to see to say yes tells you something else entirely.

‍

"What tech stack would you use for this, and why — in terms I'd understand?"

Two things are being tested here. Their technical reasoning, and their ability to translate it. A cofounder who can only explain their decisions to other developers is going to frustrate you daily. You don't need to approve every technical decision, but you do need to understand the reasoning behind significant ones. If they can't explain a tech stack choice in plain language, it's a flag — not because the choice is wrong, but because the communication pattern will be a problem.

‍

"What have you built that's live and being used by real people?"

Not projects. Not side experiments. Shipped products, in the hands of real users. Anyone can start building something. The people who interest you are the people who finish. Ask for links. Open them. Use them. Judge what you find.

‍

"Tell me about a technical decision you made that you'd make differently now."

You want to know if this person reflects, learns, and has the self-awareness to acknowledge limitation. Confident competence is attractive. Infallible confidence is a warning sign. The best engineers have strong opinions that are loosely held — meaning they'll defend their decisions but they'll also update them when confronted with new information. That's the disposition you need in a cofounder.

"How do you prefer to communicate when we're working remotely?"

This sounds like a logistics question. It isn't. It's a question about communication style, autonomy, and collaboration habits. Someone who communicates through long asynchronous documents works differently from someone who wants a quick call every morning. Neither is wrong — but if your style is daily standups and theirs is "I'll surface when I've got something to show," that friction will compound over months.

‍

"What does a bad working week look like for you?"

This is a disarming question and it's intentionally so. You're asking someone to be vulnerable about their limitations before they've committed to anything. What you're listening for: self-awareness. A person who can describe what derails them — "I struggle when priorities shift constantly" or "I get stuck if I don't have clear product requirements" — is someone who knows themselves well enough to communicate before problems become crises. A person who says "I don't really have bad weeks" is possibly someone who doesn't reflect, or possibly someone who isn't being honest with you.

‍

"How do you handle disagreement — with me, with the product direction, with technical trade-offs?"

You will disagree. At some point, you will want to build something your technical cofounder thinks is wrong, or they will want to build something you think is unnecessary, or you will both think the other person is making a mistake. The question isn't whether this happens. It's what it looks like when it does. You want someone who surfaces disagreement directly and early, not someone who goes quiet and implements what they think is right without telling you. The first approach is uncomfortable. The second one is catastrophic.

‍

"What does your current life look like, and how does this fit into it?"

This is the question most founders are too polite to ask and should absolutely ask. A technical cofounder who is also freelancing for three other clients, managing a property portfolio, and quietly applying for senior jobs at Google is not actually your technical cofounder. They're someone who's interested in the idea but hasn't committed to it. You need to understand what "I'm in" actually means for this specific person — in terms of hours, in terms of other commitments, in terms of how long they can sustain reduced income. Ask it plainly. The answer will tell you a great deal.

"What do you think is wrong with this idea?"

A cofounder who tells you your idea is great in every dimension is not a cofounder. They're someone who's excited about the conversation and telling you what you want to hear. You want someone who pushes back — who sees the holes in your logic, the gaps in your market analysis, the assumptions you're making that haven't been tested. That critical thinking, applied to your business, is one of the most valuable things a cofounder brings. If they can't do it now, in a conversation with no stakes, they certainly won't do it reliably when the stakes are high and you both really want the answer to be yes.

‍

"Who do you think our biggest competitive threat is, and why?"

You're not looking for a correct answer. You're looking for evidence that they've thought about the business beyond the technology. A technical cofounder who has no view on the competitive landscape isn't wrong — but it suggests their thinking stops at the code. The best technical cofounders are genuinely interested in the commercial reality of what they're building. This question reveals whether that's true.

‍

"What would success look like for you personally in three years?"

This is the question that surfaces misaligned expectations before they become misaligned outcomes. If your three-year vision is "Series B, scaling internationally" and their three-year vision is "we've built something cool and I've learned a lot," you're not starting from the same place. That's not insurmountable, but it's something to talk about now — not after eighteen months of building in different directions.

"How do you think equity should be divided between us, and how did you arrive at that view?"

Ask this before you've offered anything. Not to negotiate from a position of strength, but to understand how they think about fairness, contribution, and the value of different types of work. Someone who immediately argues for a higher equity split than you'd expected isn't necessarily wrong — but how they make that argument tells you a lot about whether your values are aligned. Someone who says "I think it should be roughly equal and here's why" is thinking about partnership. Someone who opens with a complex formula that happens to favour them significantly is thinking about something else.

‍

"Have you had business partners or cofounders before? How did those relationships end?"

People have histories. Previous cofounder relationships — what worked, what didn't, and particularly how things ended — are valuable data points. You're not looking for someone with a spotless record. You're looking for someone who has reflected on what they've learned. A person who describes a previous failed cofounder relationship entirely as the other person's fault is possibly someone who hasn't fully processed what their own contribution to that outcome was.

‍

"If we fundamentally disagreed on the direction of the company six months from now, what would you want the process to look like?"

This is a forward-looking version of the conflict question, and it surfaces whether this person has thought about governance. What happens when you don't agree? Is it your call, their call, a vote, a conversation? Getting to an explicit understanding of decision-making authority early — before it matters — is one of the most valuable things you can do for a cofounder relationship.

After all of those conversations, there's one more thing to do before equity enters the picture.

Work together on something small.

Not a fake project. Not a test. A real, defined piece of work — scope the technical architecture for the MVP, build a prototype of one specific feature, review the existing technical assumptions in your product brief and poke holes in them.

Two to four weeks of actual collaboration will tell you more about fit than two months of conversations. You'll find out how they communicate when there's a real problem to solve. You'll find out whether they document their thinking or keep it in their head. You'll find out whether their instinct is to make something work quickly or to make something work perfectly — and whether they can calibrate that instinct to what the situation actually demands.

Pay them for the trial project. This matters more than most founders think. It establishes the relationship as professional before it becomes personal, it's fair to ask someone to invest time without compensation before you've offered anything in return, and it removes any imbalance in the dynamic. You're evaluating each other as equals — not auditioning a candidate.

The list of questions above is long. You won't use all of them in a single conversation — nor should you. A three-hour interview-style interrogation isn't what you're going for.

Think of these as a bank to draw from across multiple conversations. Some will naturally come up. Others you'll need to deliberately introduce. The goal isn't to get through all of them. It's to get to a point where you feel, genuinely and not just hopefully, that you understand how this person thinks, works, and handles difficulty.

That feeling — grounded in real evidence rather than enthusiasm — is the foundation of a cofounder relationship worth having.

And if you get to the end of this process and the right person still hasn't appeared? That's okay. That's genuinely okay. There are other ways to build your product that don't require you to wait indefinitely. But at least when you eventually find them — or decide you don't need them — you'll know what you were looking for.

We wrote this article because we work with a lot of non-technical founders, and we've seen what happens when the cofounder decision is made quickly, under pressure, without the right questions being asked.

We don't have a stake in whether you find a technical cofounder or not. Some of the founders we work with find brilliant ones and go on to build with them. Others build their first product with us and decide that's the model that works for their company.

What we do care about is that you make this decision properly — with clear information, honest expectations, and your long-term interests genuinely in mind.

If you're somewhere in the middle of this process and want a sounding board, we're happy to talk.