Every year brings a growing number of firms claiming to offer world-class software development. Some are excellent. Many are not. And when your business depends on the software being built correctly, the difference between choosing well and choosing poorly can cost you six figures and six months you will not get back.
This guide is written from the perspective of practitioners — people who have been hired to rescue projects abandoned or badly executed by other firms. We know what the warning signs look like because we have inherited the consequences.
The Software Development Market: What You Are Navigating
The market is genuinely impressive. There are skilled engineers, modern practices, and firms doing excellent work for global clients. There are also:
- Freelancers operating as agencies (with no capacity to scale or support)
- Firms that sell well but deliver poorly (senior team on the pitch, junior team on your project)
- Competent technical teams with no product thinking or security awareness
- Firms that build to specification without questioning whether the specification is right
Understanding which category you are dealing with before signing a contract is the entire challenge.
The 7 Questions to Ask Every Software Development Firm
1. Can I speak with two or three past clients — not references you selected, but clients I choose from your portfolio?
The difference matters. A firm will select references who will speak well of them. Ask to see a fuller client list and choose who you want to speak to. Pay particular attention to clients who had difficult projects — delays, scope changes, technical challenges. How did the firm perform when things got hard?
If a firm refuses or cannot produce a meaningful client list, that tells you something important.
2. Who specifically will work on my project, and can I meet them before we sign?
Sales teams and delivery teams are often entirely different people. The senior engineer who impressed you in the pitch may have no involvement in your project. Ask to meet the actual team — the project manager, the lead developer, the person who will write your code.
If the firm is evasive about this, or if the team you meet has significantly less experience than the people who pitched, adjust your expectations accordingly.
3. How do you handle security in the development process?
This question is surprisingly effective at separating firms. Acceptable answers include: threat modelling during design, OWASP guidelines in code review, penetration testing before launch, dependency scanning, secrets management practices.
Unacceptable answers: "We take security seriously" (without specifics), "We can add security later", or a blank look.
In 2025, every web application is a target. Building without security by design is not acceptable.
4. What does your code review process look like?
Need this built for your business?
We deliver production-grade web and mobile applications — senior engineers, fixed price, full source code ownership.
Firms without structured code review produce inconsistent, unmaintainable code. Ask specifically: does every commit go through peer review? Are there automated quality gates (linting, static analysis, test coverage thresholds)? Who is responsible for maintaining standards?
5. How do you handle testing, and what does the test suite look like at handover?
You should receive a codebase with a meaningful test suite — not just some unit tests written to satisfy a checklist. Ask what types of tests they write (unit, integration, end-to-end), what coverage they target, and whether you can inspect the test suite on an existing project.
Software without tests is software that breaks silently in production.
6. What does the handover look like at end of contract?
If you ever need to move to a different firm, or bring development in-house, what do you receive? You should expect: full source code ownership, complete documentation, deployment runbooks, database schemas, API documentation, and a knowledge transfer session. Firms that make handover difficult are creating dependency by design.
7. What is your commercial model if the project runs over scope or timeline?
Scope creep and timeline extension are the most common sources of conflict in software projects. Understand upfront how the firm handles this: fixed-price contracts with change order processes, time-and-materials with budget controls, or something else. Neither model is inherently better — but both require clarity before work begins.
Red Flags to Watch For
Extremely low pricing. Software development is skilled, labour-intensive work. If a firm's rates are dramatically below market, they are either using inexperienced developers, offshoring to lower-quality resources, or planning to make margin somewhere else (scope creep, ongoing support lock-in).
No questions about your users or business goals. A firm that jumps straight to technical architecture without understanding who will use the software and what problem it is solving will build the wrong thing, correctly.
Resistance to agile working or progress visibility. You should be able to see working software regularly — every 1–2 weeks. Firms that prefer to "go away for three months and come back with something" are almost always not operating at an adequate standard.
Vague contracts. If the contract does not specify deliverables, acceptance criteria, IP ownership, data handling, confidentiality, and termination rights in clear language, do not sign it. Every ambiguity is a future dispute.
No post-launch support terms. Every software system has post-launch issues. Understand exactly what support is included, for how long, and what the commercial arrangement is if you need ongoing maintenance.
What Good Looks Like
A trustworthy software development partner will:
- Ask hard questions about your users, goals, and existing constraints before proposing solutions
- Be transparent about team composition and not obscure who will do the work
- Provide a written specification or statement of work before development begins
- Show you working software frequently, not just status reports
- Write code with security, testing, and maintainability built in — not bolted on
- Own problems rather than deflecting, and escalate risks early
- Hand over a clean, documented, tested codebase at the end of the engagement
Our Standard
We have been building production software since 2015. Our delivery model is built around the problems described above because we have seen them fail projects for other clients.
What we bring:
- ISO 27001-certified security practices in every engagement
- Senior engineers on every project — not juniors supervised at a distance
- Agile delivery with working software every sprint
- Full source code ownership and clean handover as standard
- Post-launch support included in all fixed-price engagements
Remote-first software engineering. 10 years. 75+ global clients. ISO 27001 certified. View our work →
Tags
- Software Development
- Web Development
- Hiring
- Guide
- Outsourcing
Written by
Gideon Ondari
An independent engineering practice building platforms, automation and security.
Field notes
Engineering notes, security advisories and case files. Monthly, no noise.
