Choosing a custom software partner: Five red flags

If you’re choosing a custom software partner this quarter, this post sharpens the questions you should ask after the first three calls. A custom software partnership is one of the three most expensive contracts a mid-sized B2B company signs in any given year. The engagement runs 6-12 months, the spend lands somewhere between $50K and several hundred thousand dollars, and the decision is hard to reverse — switching partners means handing a half-built codebase to another team or resetting scope from zero. The five red flags you can catch in the first three calls save the worst version of that pain.

Across three years we have watched the same patterns repeat — both in clients walking away from a previous partner, and in RFPs we run against other shops. This post lays out five red flags you can identify in the call notes or on the proposal page, then five green flags that balance the picture. The aim is not to give you a rigid disqualifier checklist; it is to clarify which questions to ask after the first three conversations. We share this list openly with our own clients while we work, because we want our own practice audited the same way.

Red flag 1: “We do everything” — no clear specialty

If the first call covers “we work in B2B SaaS, e-commerce, mobile, blockchain, AI, IoT, and ERP integrations,” pause. A five-person shop cannot hold that profile; a fifty-person shop saying “we do that” usually means “we did it once, we can probably do it again.”

Custom software is a domain where vertical depth compounds. A team that has worked on tenant isolation in three different B2B SaaS products in the last 18 months will walk you through the trade-offs in 30 minutes. A team looking at the problem for the first time will spend three weeks reading documentation and you will pay the bill.

Three practical ways to test depth:

• Ask for anonymized summaries of the last six engagements. Does the sector distribution cluster around one area, or does each engagement use a different stack? A cluster signals depth. Scattered means “we do everything” was a marketing line.
• Ask a technical reference a technical question. For example: “What is your connection pooling strategy for an RLS setup with 2,000 tenants in Postgres?” If the answer does not lock onto a recognizable pattern, they have not seen the problem before.
• Count repeat vocabulary. When the team describes its own work, do five or six specific concepts recur (such as “dual-write,” “shadow read,” “outbox pattern”)? That recurrence marks a comfort zone.

Scope creep risk is structurally higher with “we do everything” shops. You sign, three months in the design review reveals “we don’t actually do that part, do you mind if we sub it out?” — and the bill grows on your side.

Red flag 2: Single-client portfolio or one-sector lock-in

The opposite shape is also a red flag: 80% of the portfolio comes from one client or one sector. It looks like specialization at first glance; in practice it produces dependency and a missing outside perspective.

A single-client shop carries two risks: when that big client leaves, the partner hits a liquidity crisis and your project ends up on the back burner. Or, the technology preferences of that client (their favorite framework, their cloud, their architectural patterns) get copy-pasted into your project. Both outcomes are bad for you.

A single-sector shop carries a different risk: no outside perspective. A team that lives entirely in B2B SaaS goes blind on e-commerce checkout abandonment problems. They miss creative cross-sector patterns. A team with depth in one sector but exposure to one or two others usually proposes more durable solutions.

The check: does more than 50% of the portfolio come from one client? More than 70% from one sector? If either is true, slow the conversation down. Ask about their concentration-reduction plan. The silence after that question is itself a signal.

Red flag 3: Pricing that is either opaque or rushed

The third flag lives in the pricing process itself. There are two failure modes, both costly.

Too opaque. Three calls in, scope is broadly agreed, but “we’ll get a number to you in a week or two” keeps repeating. No scope mapping is happening internally. The team is either waiting on internal approval, or stalling to see your other quotes. Either way, the asymmetry of information stays on their side of the table.

Too rushed. Worse: a 30-minute first call ends with “this is going to be $80K, 16 weeks.” That number was given without any scope mapping — meaning either the partner already plans to grow it through change requests, or they are body-shopping a rate without understanding your problem.

A healthy pricing process takes about two weeks:

• Week 1: Discovery (one or two calls), scope draft, written list of open questions.
• Week 2: Architecture brief, milestone breakdown, range estimate.

A range price (e.g., “11-14 weeks, $55-72K”) signals the partner has separated the risk factors internally. A point estimate is suspicious. If you see one, read the change request clause carefully — a generous CR clause means the real pricing happens after you sign.

Four of the twelve items on our B2B partnership checklist are dedicated to the pricing process; the PDF is free if you want it before your next RFP.

Red flag 4: Code ownership and IP language that is vague

The fourth and most expensive red flag is fuzzy language around code ownership and intellectual property. The most common version we see: contracts say “the client gets a license to use the work” once delivered. A license is not ownership. The day you need to switch partners, fork the code, or sell the product into a different market, the gap between the two becomes very expensive.

Three clauses to look for:

• Work-for-hire language. All code, documentation, architecture diagrams, test suites, and infrastructure configuration transfer to the client on delivery. This needs to be explicit; “license to use” is not enough.
• Third-party dependencies. If the partner is bringing in their own open-source or proprietary libraries, under what license? A viral GPL clause sneaking in becomes your problem later. Permissive licenses (MIT, Apache 2.0) are preferred; for proprietary libraries, perpetual usage rights for the client need to be in writing.
• Account and credential ownership. Cloud account, repos, CI/CD environment, secrets manager — under whose name? The partner can have access during the engagement, but ownership starts on the client side. Plenty of bad cases start with “we set up the AWS account on your behalf”; on exit, transferring it back takes months.

If IP language is vague, ask one question in the call: “If we end this engagement, how long does it take another team to take over the code?” Any answer beyond “two weeks of documentation handover and account transfer” implies lock-in is in the design.

Red flag 5: No hand-off plan — drop-and-leave or lock-in

The fifth flag is the absence of a thought-out post-engagement phase. It shows up at both ends of the spectrum.

Drop and leave. Code drop, GitHub access transfer, “good luck.” Twelve weeks later, the first major production incident lands; your team does not know the codebase, and the partner is on a new engagement so you wait three weeks. Operational risk has been pushed onto your side.

Lock-in. The reverse: the partner has positioned itself as “you cannot run this without us” and tries to convert that into a yearly retainer. Documentation is thin, deployment scripts live on one engineer’s laptop, secrets rotation is undocumented. When you ask to leave, the answer is “it will take you three months to be able to operate without us.” That is either bad engineering culture or intentional lock-in. Neither is acceptable.

A healthy hand-off plan has four components:

• Bridge period: A 4-8 week transition window after engagement end. The partner stays available for bug fixes and questions a fixed number of hours per week, written into the contract.
• Operational runbook: Documentation for every recurring task — deployment, rollback, on-call rotation, secrets rotation, monitoring threshold tuning.
• Internal knowledge transfer sessions: In the last four weeks of the engagement, two hours per week of recorded sessions covering architecture, decisions, and debugging patterns.
• Verification checkpoint: When the bridge ends, a test session to confirm the system runs without the partner. Usually verified by your team performing a production deployment without partner involvement.

If these four components show up as “yes, that’s how we work” in the proposal call, verify by asking a previous reference: “What happened in the six months after they left?” The answer “we still pay them five hours a month for advisory” versus “we never needed them again after the bridge” tells you a lot.

Five green flags

To balance the five red flags, five green flags. None of these guarantees a good engagement, but two or three together tell you the partner is worth taking seriously.

• NDA turnaround. Signed NDA back within 24-48 hours of request. The first signal of operational discipline.
• Sector mix. Portfolio centered on one specialty (e.g., B2B SaaS) but with one or two cross-sector engagements. Outside perspective is present.
• Transparent pricing method. Range estimates, milestone breakdown, change request clause that follows industry norms. The pricing conversation does not generate information asymmetry.
• IP transfer language. Sample contract has clear work-for-hire language. Account ownership starts on the client side. A license inventory for third-party dependencies is part of the proposal.
• Bridge plan. The proposal or an attached document includes “post-engagement bridge: 6 weeks, 8 hours/week.” Someone has thought past delivery.

Finding all five green flags in a single partner is rare; three or four is enough to make signing defensible. Zero is a stop signal — do not proceed without an audit similar to the partner due diligence we run inside strategy and insights engagements.

What to do when you see a red flag

A single red flag does not kill an engagement. Two flags justify additional calls. Three or more: change partners. Six to twelve months into a custom software engagement, switching partners costs you time, money, and morale; up-front diligence is always cheaper.

A practical recipe: in the RFP stage, lay three partners side by side, fill out the five-red-five-green checklist for each, then call the technical references. A 30-minute reference call regularly produces more useful signal than a three-week proposal cycle. If you do not have the bandwidth to run that diligence yourself, or if you want a second opinion between two finalists, reach out — a typical partnership review session is two to three hours and ends with a finalist call.