Choosing a software development partner is one of the higher-stakes vendor decisions a business makes. A bad choice costs money and time. A good choice produces working software that solves a real problem. The difference between the two usually comes down to five things: process clarity, communication, pricing structure, portfolio quality, and how they handle scope changes.
This guide gives you a practical evaluation framework — not a buyer's guide padded with generic advice.
Six things to evaluate
1. Do they scope before they price?
A development firm that quotes a price without first understanding your requirements is not pricing your project — they are pricing a guess. Good firms invest time in understanding what you need before they commit to a number. The estimate process should involve questions about your users, your existing systems, your constraints, and your definition of done.
If a firm sends a quote within hours of your first enquiry without any discovery conversation, that quote is not reliable.
2. Fixed price or time and materials?
Both models are legitimate. The important thing is understanding what each means for your risk exposure:
- Fixed price means the scope is agreed and the price does not change unless the scope changes. Good for projects with well-defined requirements. You know the total cost before work starts. The risk is that the firm builds exactly what was specified, which may not be exactly what you needed if the spec was incomplete.
- Time and materials (T&M) means you pay for hours worked. Good for projects where requirements will evolve. More flexible, but your total cost is unknown at the start. Requires active oversight to avoid budget overrun.
Ask any firm you are evaluating which model they use and why. A firm that cannot explain the tradeoffs is a firm that has not thought about your interests.
3. Who actually does the work?
Many agencies sell work at one rate and deliver it at another by subcontracting. This is not inherently bad — but you should know it is happening. Ask directly: are all developers on this project employees of your firm, or do you use contractors or offshore subcontractors? If they subcontract, ask how quality and communication are managed across that boundary.
4. How do they handle scope changes?
Scope changes are inevitable on any non-trivial project. How a firm handles them reveals their operating model. Ask specifically: "If we discover mid-project that a requirement has changed, what is your process?" You want to hear: written change requests, transparent pricing for the change, and a clear timeline impact before they proceed. Any answer that sounds like "we will just figure it out" is a warning sign.
5. What does their communication look like during a project?
Ask how frequently they provide updates, what format those updates take, and what access you have to progress during the build. You should expect: at minimum weekly written updates, access to a staging environment to see the build in progress, and a clear point of contact who responds to questions within one business day. If they cannot describe their communication process, they probably do not have one.
6. What happens after launch?
Ask specifically about post-launch support: Is it included? For how long? What does ongoing maintenance cost? What is the handoff process — do they provide documentation and a knowledge transfer session, or do you get a zip file? Firms that treat launch as the end of their responsibility create dependency problems for you.
Red flags to watch for
- Quoting without discovery. A price without questions is a guess with a number attached.
- Vague timelines. "A few months" is not a timeline. Expect specific milestones with dates.
- No staging environment. If you cannot see the product being built before launch, you have no visibility into quality.
- Testimonials without specifics. Generic praise tells you nothing. Look for references that describe the actual project, the actual problem, and the actual outcome.
- Pressure to sign quickly. Urgency tactics on a multi-month engagement are a red flag. Legitimate firms have capacity planning — they do not need you to sign today.
- No post-launch plan. Software requires maintenance. A firm with no post-launch offering is building you a product they will not be responsible for.
Questions to ask before signing
- Walk me through how you would approach this project from our first call to launch.
- Who specifically will work on this project? Can I meet them before we start?
- What does your quality assurance process look like?
- How have you handled a situation where a project ran into unexpected technical complexity?
- Can you share a reference from a client with a similar project type?
- What does the handoff look like at the end — what documentation do we receive?
How to read a portfolio
Most software portfolios show screenshots and logos. Neither tells you what you actually need to know. When evaluating a portfolio:
- Look for live, working products. Can you actually visit the URL and use the product? A live product that works is more informative than a case study about a project you cannot see.
- Look for comparable scope to your project. A firm that builds marketing websites is a different firm to one that builds SaaS platforms. Make sure the portfolio matches what you are trying to build.
- Ask about the problems, not just the outcomes. What went wrong on this project? How did you handle it? A firm that can answer this question honestly is a firm that has built enough software to know that things go wrong.
The estimate as evaluation tool
Requesting a free estimate from two or three firms is one of the most useful evaluation steps available to you. The estimate process reveals how a firm thinks: how many questions they ask, how clearly they communicate assumptions, how specific their timeline and scope are, and how responsive they are during the discovery phase.
A firm that produces a clear, specific estimate with a defined scope, a line-item breakdown, and a realistic timeline has demonstrated that they can manage a project — before you have spent any money.