How to Choose a Software Development Agency: What to Ask and the Red Flags

Choosing a company to build your software is one of the most consequential business decisions you'll make — and one of the hardest to evaluate, especially without a technical background. The difference between a good partner and a bad one can be the difference between a product that ships and is maintained, and a stalled project you end up paying for twice. This guide summarizes what to ask and the signs that warrant caution.

The Red Flags

Some signals are worth pausing on before you sign anything:

• An unrealistically low price: good development costs money, and the far-cheaper bid is usually recovered later through change fees or low quality.
• Vague promises with no detail: 'we'll build everything for you' with no written scope or clear delivery milestones.
• Refusing to put the ownership model in writing, or being evasive about what you own versus what stays with the vendor.
• No mention of testing, security, or post-launch — as if the project ends at delivery.
• Hard-to-reach or slow to respond during pre-sales — it only gets worse after the contract is signed.

Fixed-Price vs. Time & Materials

There are two common contracting models, and each has its place:

• Fixed-price: suited to projects with a fully defined, well-understood scope. It gives you budget certainty but assumes requirements won't change — and any change becomes a new negotiation.
• Time & materials: you pay for actual effort, best for evolving or not-fully-defined products. It demands more trust and transparency but is more flexible and realistic for most digital products.

Code Ownership and Post-Launch Support

This point is often overlooked until it's too late, and more than one model exists in the market. Some vendors transfer code ownership to you on payment. Others keep the code and the intellectual property and grant you a full usage licence instead, in exchange for a lower upfront cost and an ongoing service. Both are legitimate; the real risk is a model that is vague or unwritten. Our own model at PhiBit is single and stated up front, across every type of engagement: the code and IP remain ours permanently, and you hold a full, uninterrupted licence to use the product — with read-only access to your project's repository and a contractual clause that protects your business if we ever cease to operate. Either way, insist that deployment accounts, the domain, and the data are in your name from the start. And ask about the post-launch support model: who fixes bugs, with what response time, and at what cost? A product with no maintenance plan is deferred debt.

Questions to Ask

1. What exactly is the ownership model: full transfer on payment, or does the vendor keep the code and licence it to me? Where does the contract say so, and what happens to my product if the vendor stops trading?
2. How do you handle testing and security — is there code review and vulnerability remediation?
3. What's the communication cadence: regular reports, meetings, a single point of contact?
4. What happens after launch — what are the maintenance, support terms, and response times?
5. Can I see past work or speak to former clients?