What to Look for When Choosing a Software Development Partner

Most companies hire a software development partner the way they hire a decorator: look at pictures, pick a price, hope the rooms work. Then six months later the rooms don't fit how people actually live.

I am biased — I am a software consultant who also builds — but I'm going to write this as if you might not hire me. You should still walk into any conversation with the same checklist. If I fail it, don't hire me either.

Partner vs Vendor vs Freelancer

A vendor takes a ticket. A freelancer finishes a slice. A partner cares whether the slice belongs in the product at all.

If you only need a slice, don't pay partner rates. If you need a system that will still make sense in two years, don't hire a vendor and call them a partner. I broke this down in consultant vs agency vs freelancer. Read that if you're still mixing the three.

What “Good” Looks Like in the First Two Calls

They can tell your story back to you

After one conversation they should describe your customer, your painful step, and what version one is not. If they only repeat “you need a mobile app and a dashboard,” they heard a shopping list, not a business.

They talk about non-goals

The best partners are slightly annoying. They cut scope. They ask who will use this on day one. They would rather ship a smaller true thing than a museum of features. That's the same instinct as founders build too much.

They can explain architecture without a TED talk

You should understand, in plain language, how data will move, who can see what, and what will hurt if you add a second location later. If they hide behind jargon, you will not be able to govern the project. See requirements and architecture.

They separate advice from the build

A partner who cannot imagine telling you not to build yet is selling implementation. Consulting first, then a build decision, is how adults buy software. That's why my own site leads with software consulting, then technical partnership.

You will own the work

Code, accounts, repositories, cloud — in your name. If they want to keep the keys, you're renting a hostage.

Change after launch is a process, not a surprise invoice personality

Software that is used will change. Ask how they handle that: retainer, warranty, tickets, what is in scope. Vague answers become arguments.

Questions I Want You to Ask (Including Me)

1. What would you refuse to build for us right now, and why?
2. Walk me through a project where the first idea was wrong. What did you do?
3. How do you decide buy vs build for payments, auth, admin?
4. Who writes requirements? What do I receive before the first sprint?
5. When the first developer is on leave, who understands the system?
6. What does “done” mean for the first release — and what is explicitly out?
7. If we part ways, what do we keep and how do we run it?

Watch their face on question 1. If they never refuse work, they will never protect your budget.

Red Flags (I've Seen All of These)

• A fixed quote after a 15-minute call with no workflow walkthrough.
• Stack religion in minute five: “We only do X, so your product will be X.”
• No mention of data, roles, or failure cases — only screens.
• Offshore black box with no named human you can reach.
• They need your logo for their homepage more than they need to understand your ops.
• They promise the timeline the sales deck needs, not the one the problem needs.

Cheap is not automatically a red flag. Unscoped cheap is. I'd rather a smaller, honest MVP than a bargain that becomes architecture tax for two years.

A Rough Scorecard You Can Use

Give each item 0–2. Below 8, keep looking. This is not science. It's how you stop hiring on charm.

• Explained our workflow back, including the unofficial steps (Excel, WhatsApp).
• Named something they would not build in version one.
• Talked data, roles, and failure — not only screens.
• Clear who owns code, cloud, and accounts.
• Separate discovery from the build quote (or a tiny paid discovery).
• Could describe a time they told a client to buy a tool instead of custom.
• Named a human we will actually work with, not a logo.

If they score well on screens and poorly on the rest, you will get a nice demo and a system that fights your operations. That's the expensive kind of pretty.

Fit Matters More Than Prestige

A huge agency that builds banks may be the wrong partner for a 12-person operations company. A freelancer who is brilliant at React may be the wrong partner if you need inventory logic and role-based pricing.

Ask: have they sat with a messy operational workflow before — not just a marketing site? Have they told a client to buy off-the-shelf instead of custom? That's the buy vs build conversation. If they never recommend buying, they're not a partner. They're a factory.

The Order I Recommend

1. Clarity — problem, workflow, version one. Consultant hat.
2. Blueprint — requirements, architecture, buy vs build.
3. Build — partner hat, against that blueprint.
4. Operate — you own it; they may stay on retainer.

Skipping 1 and 2 is how you choose a partner with a vibe and a colour palette. I wrote when to hire a software consultant for that skip.

How I Show Up If You Talk to Me

I'm Gracious. I consult first. If we should not code yet, I will say so. If we should buy a tool, I'll say that too. If the blueprint is solid and you want one owner to ship a SaaS or internal platform, I can stay as technical partner — no equity, you keep the company.

Remote, from Port Harcourt, with companies in the US, UK, Canada, and Nigeria. Thirty minutes is enough to know if we're a fit. Bring the painful workflow, not a 40-page wishlist.