To choose a software development company, look past the price and the portfolio and check five things: how the firm runs discovery, whether you can verify its references, who will own the code and the intellectual property, how it handles security and handover, and whether the contract model fits how much of the project is still unknown. The ten criteria below, with a scorecard you can reuse, turn a vendor shortlist into a decision you can explain to your board.
Before you talk to vendors
Three things on your side make every vendor conversation more productive.
- The business problem and how you will measure success. Not "a new customer portal" but "dealers place orders online instead of by phone."
- An internal owner. One person who makes decisions, answers questions quickly and signs off on acceptance tests.
- Fixed constraints. The systems you must connect to (ERP, CRM, accounting), the personal data involved and any go-live date the business genuinely cannot move.
1. Discovery quality
Watch who asks the questions in the first call. A capable team asks about your users, your current workflow, where your data lives and which systems need to be integrated before it talks about price. It ends the call with a written summary of what it understood and what is still open. When a key assumption is risky, for example whether a vendor API actually exposes the data you need, it proposes a small proof of concept to test that assumption before quoting the whole project. A firm quote that arrives before anyone has asked about your process can look efficient, but it usually means the uncertainty has been handed to you.
2. References you can verify
A wall of logos is not a reference. Ask to speak with a client whose project resembles yours, and ask them directly: Did the project finish within the agreed scope? Is the system still in production? How did the team behave when something went wrong? Did the team change halfway through? Check whether published case studies name the client, describe the problem and show what was delivered. Reviews on independent platforms such as Clutch or Gartner Peer Insights are a useful extra signal, but they do not replace a conversation with a client.
3. Ownership of code and IP
Do not assume the code is yours because you paid for it. Ownership follows the contract and the law that governs it, so the agreement should state that source code, designs, documentation and project data transfer to you as you pay. If you work with a Turkish vendor, note that Article 52 of Türkiye's Law on Intellectual and Artistic Works requires contracts on economic rights to be in writing and to list each right separately (Law No. 5846, mevzuat.gov.tr). A vague "all rights are transferred" line is not enough, so have your counsel review the clause.
On the practical side, ask for two things. First, the code repository should live in your organization's account from day one. Second, every open-source and third-party component should be listed with its license. If the engagement ends early, you still hold a working codebase.
4. Security and ISO 27001
An ISO/IEC 27001 certificate shows that the firm runs information security through an audited management system. Ask for the certificate and its scope statement; the scope should cover the teams that build software and handle client data. Then ask:
- How is access to our environments granted, and how is it revoked when the project ends?
- Is real personal data used in testing, and if so, how is it anonymized?
- How are code reviews and dependency vulnerability scans done?
- If there is a security incident, when and how will we be told?
If personal data is involved, put roles and responsibilities under GDPR, and KVKK for data processed in Türkiye, into the contract. If you want to assess your own readiness first, see our KVKK and ISO 27001 compliance service.
5. Documentation and handover
When the project ends, your team or another vendor must be able to run the system. Check what the proposal includes for handover: architecture documentation, build and deployment pipelines, runbooks, transfer of admin accounts and secrets, and knowledge transfer sessions. There is a simple test. During acceptance, ask someone on your team to set up the system in a fresh test environment using only the documentation. If they get stuck, the handover is not finished.
6. Team continuity
The people in the sales meeting are not always the people who build your system. The proposal should name the technical lead and the project manager. Ask what happens if someone leaves: who replaces them, how much notice you get and how knowledge is transferred. Knowledge that lives in the repository, the issue tracker and the documentation, not in people's heads, is the most concrete protection you have.
7. Contract model
The right model depends on how well the work is understood.
| Model | When it fits | What to watch |
|---|---|---|
| Fixed scope, fixed price | Scope and acceptance criteria are written down and stable | Uncertainty is priced in as risk; every change becomes a change request |
| Time and materials | Scope will be discovered together and priorities may shift | You need a budget cap, weekly reporting and control over priorities |
| Phased delivery | Work can be split into phases after discovery and a proof of concept | Each phase needs its own deliverables, acceptance criteria and go or no-go decision |
For most enterprise projects, contracting discovery and a proof of concept as a separate piece of work, then splitting the build into phases, makes risk visible to both sides.
8. Communication
Expect a weekly status meeting, regular demos of working software, a single point of contact and written records of decisions. You should have access to the issue tracker and a test environment, so you judge progress by working software rather than slides. With a team in another country, agree on the project language and overlapping working hours at the start. Türkiye's working day, for example, overlaps with most of the European day and with the morning on the US East Coast.
9. Local or remote partner
Most software work can be done remotely. The moments when being on site adds value are usually predictable: discovery workshops, observing a process on a production line or in the field, user acceptance testing and go-live day. Ask how those moments are planned and ask for a written plan rather than a general promise. ALGOFACT, for example, runs engineering from offices in Adana and Ankara TEKMER in Türkiye and has a US entity in Dover, Delaware; clients in other cities and countries are served the same way, and on-site work is planned per project in the discovery call. See the locations we serve for details.
10. Red flags
One of these alone may not disqualify a vendor, but several together should make you cautious.
- A firm price and date in the first call, before anyone asked about your needs.
- Access to the source code held back until the final payment.
- Requests for a reference call that are politely deflected.
- No named team members in the proposal.
- Testing, documentation or handover left out or marked "optional."
- "Yes, we can do that" to every question, with no risks named.
A scorecard you can reuse
Rate every vendor on your shortlist with the same table. Adjust the weights to your situation: security weighs more when personal data is involved, and discovery quality weighs more when the new system must connect to existing ones.
| Criterion | Question to ask | Evidence to request | Weight | Score (1 to 5) |
|---|---|---|---|---|
| Discovery quality | What did you understand, and what is still open? | Written call summary, list of assumptions | High | |
| References | Can we speak with a client with a similar project? | Reference call, system in production | High | |
| Code and IP | When and how do code and rights transfer? | Contract clause, repository in our account | High | |
| Security | How is access to our data and environments managed? | ISO/IEC 27001 certificate and scope | High | |
| Documentation and handover | Could another team run this system? | Sample runbook, handover plan | Medium | |
| Team continuity | Who works on the project, and what if someone leaves? | Named team, replacement procedure | Medium | |
| Contract model | How is uncertainty shared? | Phase plan, acceptance criteria | Medium | |
| Communication | How will we see progress? | Meeting schedule, demo cadence | Medium | |
| Local or remote | When is on-site work needed, and how is it planned? | Written engagement plan | Low to medium | |
| Red flags | Which risks do you see in this project? | Risk list in the proposal | Pass or fail |
You can turn weights into numbers, for example 3 for high, 2 for medium and 1 for low. The total is not the decision itself; it structures the discussion inside your team. When two vendors score close together, reference calls usually reveal the difference.
Running the selection
- Keep the shortlist to three or four firms; a longer list makes comparison shallow.
- Send every firm the same problem statement and the same questions.
- Read each proposal for scope, assumptions and risks before you look at the price line.
- Hold reference calls with the final two.
- If uncertainty is high, start with discovery and a proof of concept, then decide on the build with the results in hand.
Next step
ALGOFACT starts solution engineering projects with a 30-minute discovery call, followed by a founder presentation of the proposed scope. Feel free to use this checklist on us as well: bring your questions and book a discovery call.