A 7-criterion framework for separating founder-minded partners from transactional vendors — and how to know if you’re the kind of founder they’ll actually want to work with.
The YC Problem
Y Combinator says don’t use dev shops for v1. They’re right — most of the time. Their argument: outsourced v1 builds tend to produce low-quality products that founders ultimately throw away, after spending real time and money getting there. The concern is legitimate. Commodity agencies optimize for volume and margin, not for your outcome. They pad estimates, cut corners on quality, and hand off mediocre code that becomes your problem.
But there’s a spectrum between “offshore dev-mill” and “founder-mode partner.” This article is about how to spot the difference, and what questions separate the two.
When founders interview us at Founding Developers, we’re applying the same 7 criteria to them that they should be applying to us. The evaluation isn’t one-directional. Good partners are selective — we reject misfit clients. And you should be just as selective about us.
1. Senior Technical Leadership in the Room (Not Just Sales)
The first thing I notice in a call is who’s talking. If it’s sales explaining your product back to you in your own language, without pushback or technical nuance, I know we won’t be a fit. We won’t do the work.
Here’s why this matters: scope creep and misalignment usually start when sales commits to something engineering can’t deliver. You need a technical voice in every conversation about what’s feasible, what’s wise, and what’s a trap.
When you talk to a partner, look for who’s making decisions. Is a senior engineer on the discovery call, or just sales? When you ask a technical question — “Can we integrate with Stripe?” — does the sales person defer to the engineer, or answer from their script?
A weak signal: “Our engineers will figure it out.” A strong signal: “Let me show you how we’d approach that, and here’s why we’d probably avoid this alternative.”
Red flag: No engineer present in initial calls. Sales person describes your product in generic terms, not technical translation.
Probe question: “Who will be my main technical touchpoint, and who makes architecture decisions?“
2. Problem-First Discovery (Not Feature-First)
The second thing I listen for is whether the founder understands their customer’s problem. Not features. Not UI. The actual problem. If they jump to “We need a mobile app with a chat feature and real-time notifications,” without telling me why, I know discovery is going to be painful.
Feature-first projects fail. Fifty-two percent of projects suffer from scope creep — not because developers are slow, but because the spec was incomplete (PMI). Problem-first discovery prevents this. It forces you to articulate constraints: What’s the budget? What’s the timeline? What’s the minimum outcome that proves the idea works?
When you interview a partner, watch their discovery process. Do they ask why before what? Do they spend time on customer context — the workflows, competing solutions, industry norms? Or do they start sketching UI in the first call?
A strong partner pushes back if your feature list is too large for the timeline. They’ll say, “Here’s what we can ship in 8 weeks if we’re ruthless about scope. Everything else is v1.1.”
Red flag: Partner immediately starts sketching UI or asking about tech stack. No questions about customer context or constraints.
Probe question: “Walk me through your discovery process. How long does it typically take, and what do you investigate first?“
3. Engagement Model Fit (Fixed Price vs. Time & Materials)
Fixed-price contracts lock in cost but inflate price. Partners add 15–30% buffers for unknowns, and you pay that premium whether the risks materialize or not. For early-stage work, this is expensive.
Time & Materials allows pivoting. You learn something new, you adjust. The trade-off is that you need discipline: weekly demos, clear change-control, no scope creep without timeline pushback.
Here’s what I look for: Can the founder accept T&M with governance? Or are they so constrained by budget that fixed-price is their only option? If it’s the latter, I pass. Fixed-price works for well-defined projects. MVPs are not well-defined.
When you talk to a partner, ask what they recommend for your stage. A good answer: “For early-stage, we recommend T&M with weekly checkpoints. You’ll have full visibility, and we adjust scope or timeline together as you learn.”
A bad answer: “We guarantee a fixed price. All-in. No surprises.”
Red flag: Partner pushes fixed-price without detailed discovery. Won’t commit to weekly demos or reviews.
Probe question: “For this MVP phase, do you typically use fixed-price or T&M? What are the trade-offs you see?“
4. Code-Quality Discipline (Not Just Speed)
Code written today becomes technical debt tomorrow. Partners who skip testing, code review, and documentation to ship faster are betting your future — literally. Engineers at Stripe spend up to 42% of their time dealing with technical debt. Rewriting bad code later is significantly more expensive than building it right the first time. That 2-week shortcut today becomes 6 months of rework later.
Worse: technical issues discovered during due diligence materially reduce valuation, and a meaningful share of investment deals collapse when technical review surfaces problems. For a data-backed breakdown of what AI-generated code misses without senior review, see The Hidden Cost of AI Code.
When I interview a founder, I listen for whether they understand or care about code quality. Will they defend time for testing and refactoring, or are they “ship fast, fix later” people?
Ask your partner: What’s their code-review process? Who approves code before it ships? What’s their test coverage target? A real answer includes specifics: “We aim for 80%+ coverage. Every change is reviewed by a senior engineer before merge.”
Red flag: Partner has no documented code-review process. “We’ll test later.” No clear quality bar.
Probe question: “Walk me through your code-review process. Who approves code before it ships? What do you check for?“
5. Continuity & No Key-Person Risk
If your project depends on one engineer — and that engineer leaves, gets sick, or moves on — your project stalls. You need documentation, onboarding, and team depth.
When I interview a founder, I’m asking: Will you stay engaged after launch? Can I reach you when needed? Will you help onboard the next person when the current one moves on?
When you interview a partner, ask about continuity. Do they have a written handoff process? Who’s the backup for your lead engineer? What’s their average tenure? A strong signal: written documentation of architecture decisions, not just code comments. A clear onboarding process. A named backup.
Red flag: “Your main engineer is John; he’s the only one who knows this codebase.” Or no transition plan.
Probe question: “If your lead developer leaves the project, how quickly can someone else jump in? What would that handoff look like?“
6. Outcome Accountability (Owning a Release, Not Just Hours)
Partners paid by the hour have no incentive to finish. They benefit from delay. Partners who care about outcomes prioritize getting to a releasable product — something you can ship, test with real users, and learn from.
This is the difference between “feature-counting” and “outcome-focused.” If the partner says “We’ll build everything on your list,” that’s a red flag. No one finishes a list. Lists grow. A strong partner says: “We’ll ship a Beta with features A, B, and C. That’s our definition of done for this phase.”
When I interview a founder, I’m listening for their definition of “done.” Is it something shipped and in users’ hands? Or is it a vague internal build?
Ask your partner: What does success look like for this engagement? What counts as done? A strong answer includes releases and users, not just code. “Done means shipped, with user feedback, and documented for handoff.”
Red flag: No clear release plan. “We’ll build everything on your list.” Focus on hours logged, not shipped outcomes.
Probe question: “How do you define success for this engagement? What does ‘done’ mean?“
7. Equity-Style Alignment (Caring About Your Runway, Not Just Their Margin)
True partners care about your long-term success: your runway, your burn rate, whether you raise the next round. Transactional vendors care about billable hours. The difference is obvious once you know what to listen for.
A partner with equity-style alignment asks about your runway in discovery. They’ll proactively suggest trade-offs: “We can ship this in 6 weeks instead of 12 if we defer that feature. Here’s what you’d lose.” They’re not padding the timeline to lock in billable hours — they’re optimizing for your constraints.
When I interview a founder, I’m asking: Do they understand their own burn rate? Will they iterate and improve, or blame external factors? Do they expect us to care about their traction months later?
Ask your partner: What’s your take on timeline? What would you cut to stay lean? If this was your company, what would you do differently? A strong answer shows they’ve thought about your constraints, not just their project revenue.
Red flag: Partner shows no interest in your business metrics. Doesn’t ask about runway or funding. Pricing is inflexible and indifferent to your stage.
Probe question: “What’s your take on how long this should take and what we should cut to stay lean? What would you do differently if this was your company?”
Red Flags Checklist
Use this before you sign anything.
Before You Commit:
- No senior engineer on discovery calls — just sales.
- Partner won’t commit to weekly demos or reviews.
- Hard push for fixed-price without detailed discovery.
- Your product described back to you in your own language, with no technical pushback.
- No documented code-review or testing standard.
- Can’t articulate a transition plan if the lead engineer leaves.
- No interest in your business model, runway, or constraints.
- Slow response times during the sales process. How a partner shows up before the contract is the best preview of how they’ll show up during development.
During Early Development:
- Scope expanding without timeline pushback.
- Merged code that wasn’t reviewed.
- No test coverage or “We’ll test later.”
- Partner avoiding difficult conversations about trade-offs.
- Vague status updates or communication gaps.
- Missed deadlines with no explanation or course correction.
- You can’t run or understand the code they’ve written.
Questions to Ask in the First Call
These are the questions I ask founders when they interview us. Use them on any partner, including us.
Question 1: “Tell me about your discovery process. How long does it take, and what do you investigate first?”
Listen for: A problem-first approach. Customer context, workflows, constraints. Timeline (“1–2 weeks,” not “2 days”). Who’s involved (“Our lead engineer attends, plus we talk to your target customer if possible”).
Red flag: Jumping to UI sketches or feature lists without understanding the problem.
Question 2: “If this project goes longer than expected, how do we adjust?”
Listen for: Explicit change-control process. Weekly reviews. Trade-off decisions (“We can ship faster if we defer X or reduce quality in Y way”). Proactive catch of scope creep in standup.
Red flag: “We pad estimates so we’re always on time” (suggests hidden cost).
Question 3: “What’s your code-review process? Who approves code before it ships?”
Listen for: Senior engineer or architect reviews all code. Testing standards (“80%+ coverage”). Security and performance standards.
Red flag: “Each developer reviews their own code” or no formal process.
Question 4: “If your lead engineer leaves the project, how quickly can someone else jump in?”
Listen for: Documentation standards. Team depth (“We’d onboard the backup within a week”). Explicit handoff process.
Red flag: Blank stare or “That’s never happened.”
Question 5: “What does ‘done’ mean to you for this phase?”
Listen for: Specific, releasable definition. (“A shipped Beta with features X, Y, Z and documented APIs.”) Not vague (“We build everything on your list”).
Red flag: Unwillingness to say “Out of scope for this phase.”
Question 6: “How much of my time will you need? What are you asking me to do?”
Listen for: Realistic scope (“3–5 hours/week for decisions and reviews”). Specific asks (“Weekly review of the build, access to target customers for feedback”).
Red flag: “Minimal — we’ve got this” (you’ll be surprised later) or “20+ hours/week” (unsustainable).
Question 7: “What’s your process for estimating, and how accurate are you?”
Listen for: Honesty about uncertainty. (“Pre-PMF is inherently uncertain; we estimate in ranges and review weekly.”) Not: “We’re always within 10%.”
Mention of buffer reasoning: “We add 20% for unknowns and flag if they materialize.”
Question 8: “What does success look like for you in this partnership?”
Listen for: Alignment with yours. (“A shipped product your users love, and you becoming successful.”) Not: “Completing the project on time and budget” (transactional language).
Interest in your growth: “We care whether you get traction and what you learn.”
Why the Right Partner Costs Less Than the Wrong One
The question founders ask is often the wrong one. They think: “How do I spend the least?” The better question: “How do I avoid spending several times more later?”
Cheap shops produce code that costs several times more to fix later. Premium partners prevent technical debt, scope creep, and timeline delays. The math is simple.
Scenario 1: Cheap shop. $30K for 3 months, then 6 months and $60K in rework. Total: $90K, 9 months.
Scenario 2: Premium partner. $50K for 4 months, ships clean, scales to v1.1 in 2 more months. Total: $70K, 6 months. Thirty percent cheaper, 3 months faster.
That difference matters. If your burn rate is $18,000/month, 3 months of runway is $54,000. A premium partner that saves you 3 months of development time covers the cost difference twice over.
Add in the valuation impact. Clean code doesn’t get dinged at due diligence. Debt does — and the discount can be material on the way to Series A. Do the math on your fundraise target.
Early stage is when alignment matters most. You need someone who optimizes for your runway, not their hours. You need someone who’ll say “Here’s what we should cut” instead of “Here’s the full list you asked for.” For a side-by-side comparison of how different technical partners (agency, founding engineer, fractional technical cofounder) compare on cost, equity, and alignment, see Fractional CTO vs Founding Engineer vs Agency: What Pre-Seed Startups Actually Need.
What This Means for You
The 7 criteria apply to any technical partner — in-house founding engineer hire, freelancer, agency, or fractional technical cofounder. They’re not FD-specific. They’re signals of founder-minded technical partners, full stop. For a deeper breakdown of which type of technical partner fits which stage, see Founding Engineer vs. CTO: What Your Early-Stage Startup Actually Needs and How to Get Senior Engineering Help Without Giving Away Equity.
Good partners expect to be evaluated. They’ll welcome these questions. If a partner bristles at rigor, you’ve learned something important.
Run multiple discovery calls. Compare partners against this framework. Watch for consistency. Watch for who pushes back on your assumptions (that’s good) and who says yes to everything (that’s bad).
And remember: partners who are selective about clients are usually the ones who produce good outcomes. If we reject you, it’s not personal. It means we don’t think we’re the right fit. That clarity saves you months later.
Frequently Asked Questions
How do I find a technical partner who thinks like a cofounder, not just a contractor?
Look for someone who codes daily, joins your standups, and asks about your runway — not just your feature list. The clearest signal: do they push back on your assumptions, or agree with everything? A founder-minded partner says “here’s what we should cut” rather than “here’s the full list you asked for.” They’re also selective about clients — if they say yes to everyone, that’s a red flag. For a full framework of what makes a founding engineer different from a contractor or agency, see Founding Engineer vs. CTO: What Your Early-Stage Startup Actually Needs.
What should I look for when evaluating a software development agency for my startup?
Seven criteria separate founder-minded partners from transactional vendors: (1) senior technical leadership in discovery calls, not just sales; (2) problem-first discovery before feature discussion; (3) T&M engagement model with weekly demos; (4) documented code-review and testing standards; (5) continuity plan if the lead engineer leaves; (6) outcome accountability — a shipped product, not just hours; (7) equity-style alignment — they ask about your runway and suggest trade-offs. Use the probe questions and red flags checklist in this article before you sign anything.
What’s the difference between a founding engineer and a development agency?
A founding engineer is embedded in your team full-time, codes daily, participates in strategic decisions, and has equity alignment with your outcome. An agency is project-based, optimizes for billable hours, and leaves after delivery. The critical difference for early-stage startups: founders need someone who stays — who maintains context across the codebase, mentors the next hire, and cares about your traction three months after launch. For a cost and commitment comparison across all options, see How to Get Senior Engineering Help Without Giving Away Equity.
Should I use fixed-price or time and materials for my startup MVP?
Time and materials for an MVP, always. Fixed-price contracts inflate cost by 15–30% (partners pad for unknowns) and punish you when you discover new information mid-build — which you always do. T&M with weekly demos and clear change-control gives you visibility and the flexibility to adjust scope as you learn. Fixed-price works for well-defined, stable-spec projects. An MVP is neither.
How much of my time does working with a technical partner require?
Plan for 3–5 hours per week minimum: weekly build review, key product decisions, and access to target customers for feedback. Partners who say “minimal — we’ve got this” are setting you up for misalignment. Partners who say “20+ hours per week” are creating an unsustainable dependency. The right answer is specific: “Weekly 45-minute review, async Slack communication, and you make the final call on scope trade-offs.”
What are the red flags that a technical partner is transactional, not aligned?
No senior engineer on discovery calls. A push for fixed-price before detailed scoping. No questions about your runway, burn rate, or business model. “We’ll test later” or no documented code-review process. Slow response times before signing (the best preview of post-signing availability). And most importantly: they say yes to everything. A partner who never pushes back on your feature list is optimizing for billable scope, not your outcome.