The Questions To Ask A Software Partner Before You Sign

You are about to hand a software studio a meaningful amount of money to build something your business will run on. The proposal looks good, the demo was impressive, and the salesperson was sharp. None of that tells you the thing you actually need to know, which is whether, six months from now, you will own a working product you can take anywhere, or be locked into a relationship you cannot leave with a codebase you cannot touch.

The difference between those two outcomes is mostly decided before you sign, by questions most buyers do not think to ask until it is too late. The studios that own your outcome answer them plainly. The ones that just want to bill you for hours get evasive. Here is the checklist that surfaces which kind you are dealing with, organized around the few questions that matter most.

Who owns the code, in writing, with no ambiguity

This is the question that protects everything else, and it is the one most people get wrong because they assume the answer. They figure that since they paid for the software, they own it. That is not how it works by default. Under copyright law, the party that creates a work owns it unless the contract explicitly transfers ownership, which means that absent a clear assignment clause, the studio that wrote your code retains rights to it. You paid for it and you do not own it.

So you ask directly, and you ask to see it in the document: where exactly in this contract does it say I own the intellectual property, the source code, and the design assets, in full, upon final payment? The answer has to be a specific clause, not a verbal assurance, because verbal assurances mean nothing when the written contract says otherwise. Courts enforce what is written. Full IP assignment on final payment is the standard that protects you, and anything short of it, partial ownership, a license rather than ownership, rights retained "for portfolio use" that turn out to be broader than they sound, is a dependency you are signing up for.

The follow-up that exposes the worst version: can I take the complete codebase and hand it to a different studio tomorrow if I need to? If the answer is anything other than an immediate, unqualified yes, you are looking at vendor lock-in. Some studios transfer only compiled code while withholding the repositories, the infrastructure access, or the deployment rights, which leaves you owning a thing you cannot modify or move. You want the source, the repos, and the keys, all of it, contractually yours when you have paid. The deeper version of this risk, the product that quietly depends on one irreplaceable person, is covered in handing off software so it survives the person who built it.

Who is actually going to do the work

A common and demoralizing experience: you meet impressive senior engineers during the sales process, you sign, and then your project is quietly handed to a team of juniors you never met or vetted. This bait-and-switch is structurally common in shops that sell on their best people and deliver with their cheapest, and it is one of the most consistent complaints from buyers who got burned.

So ask who specifically will build your product, and whether the people in the room during the pitch are the people who will write the code. Ask to meet the technical lead who will actually own your project, not just the account manager who will report on it. Ask how they handle continuity if someone leaves mid-project, and whether you keep direct access to the people doing the work or are mediated entirely through a project manager. A studio that owns your outcome will put you in contact with the engineers and stand behind their involvement. One that is selling you a brochure will keep the real team at a distance.

How they communicate when things go wrong

Communication problems do not appear after you sign; they are visible before, and they only get worse once the contract is signed and the studio is juggling you against other clients. If responses are already slow and answers already vague during the courtship, when they are trying to win you, that is the best the relationship will ever be.

The things to look for are concrete. Direct access to the technical lead, not just a project manager relaying messages. A clear channel for day-to-day communication and regular check-ins, so you are not guessing about status. A real answer to "how do you handle an urgent production issue at 9pm," because at some point there will be one. And documentation practices that mean the knowledge of how your system works lives somewhere other than one person's head. A studio that goes quiet for a week during the sales process will go dark for a month during a crisis, and a crisis is not hypothetical, since every hour of downtime carries a real number that someone has to be reachable to stop.

The honesty test: do they ever say no

Watch for the studio that says yes to everything. It feels great in the sales meeting, but it reveals one of two problems, and both are bad. Either they lack the experience to know when you are heading somewhere wrong, or they know and will not tell you because they do not want to risk the deal. A studio that owns your outcome will push back when your plan has a flaw, tell you when a feature is a bad idea, and occasionally talk you out of spending money. That friction is the sound of someone thinking about your result rather than their invoice.

The same instinct shows up in scope and estimates. A partner who scopes honestly will give you ranges, flag the parts that are uncertain, and tell you what they do not yet know, and ideally help you cut the brief down to something shippable, the way scoping an MVP that ships in six weeks describes. The same honesty should extend to whether your first hire is even a developer at all, which why your first software hire should not be a developer unpacks. One who hands you a precise fixed number for a vague brief is either guessing or planning to make it up in change orders later. The bigger build-versus-buy question underneath all of this is the subject of when to build custom software instead of buying off the shelf. This is exactly the kind of judgment we try to lead with in a senior technical consultation, because the most valuable thing an experienced studio offers is often the honest "here is why that approach will hurt you," not the eager "sure, we can do that."

The structural signals in the contract and the money

A few specifics in the paperwork separate a partner from a trap.

• Payment tied to deliverables. A reasonable structure ties payments to milestones with defined deliverables. A demand for the large majority of the fee up front, before meaningful work, with no milestone structure, is a different kind of signal entirely, because it removes the studio's incentive to deliver on schedule.
• Willingness on NDAs, IP, and access. A partner who resists an NDA, dodges clarity on IP ownership, or is vague about access control and data protection is telling you something. A studio that takes security seriously should be able to speak plainly about how they protect your data, the buyer's side of vetting a vendor's security before you hand over your data. Resistance to these basics is a red flag you cannot afford to wave off.
• Source control and backups you can see. Ask where the code lives, who has access, and how it is backed up. The answer should be a real repository you have visibility into, not a black box on the studio's machines that you only see at the end.
• A documented handoff. Ask what you get at the end beyond a running app: the source, the documentation, the deployment process, the credentials, enough that another competent team could pick it up. A studio that owns the outcome plans for the day you might not need them; one that wants lock-in plans for the opposite.

What you are really testing for

Every question on this checklist is a proxy for one thing: will this studio treat your result as their responsibility, or will they treat your project as billable hours? The ownership clause tests whether they want you free or captive. The team question tests whether they will give you their real engineers or their cheapest available bodies. The communication and honesty tests reveal whether they will tell you the truth when it is inconvenient. The contract structure shows whether their incentives are aligned with you delivering or with them billing.

The studios worth signing with answer all of this plainly, because they have nothing to hide and they have built their business around clients who come back rather than clients who cannot leave. We try to be that kind of partner, building, deploying, and running software end to end and handing clients full ownership of what they paid for, which is the standard you can read about across how we work and what we build. The ones to walk away from get cagey on exactly these questions, because the lock-in, the bait-and-switch, and the buried license terms are the business model, not an accident.

Ask the questions before you sign, while you still have all the leverage. After you sign, with the money committed and the work underway, the same questions get much harder to ask and much easier to ignore, which is precisely why the wrong kind of studio hopes you will not ask them now.