How to Choose a Custom Software Company: 7 Questions to Ask

When choosing a custom software company, look for answers to four questions before price: do you really need software built from scratch, will the rights to the source code be transferred to you in writing, will enough documentation be delivered for another team to take the system over, and who will step in after launch, and how fast? In Turkey, computer programs count as works under the Law on Intellectual and Artistic Works, and transferring the economic rights requires a written contract. That is why the most expensive mistakes in custom software usually surface after the project ends, on points the contract never covered.

Off-the-shelf package, platform or custom software: which do you need?

A good software company asks this before quoting. For standard processes such as accounting, inventory or website management, off-the-shelf packages are enough for most businesses. Processes that are specific to your organization but follow a known pattern, such as approval flows, forms, rules and reporting, can be built faster on business process platforms that let you create applications without writing code. A workflow that sets you apart from competitors and has no equivalent in any other product is what justifies custom software.

Ask the company: "Which of these do you recommend for my need, and why did you rule out the other two?" A company that recommends custom development for every need may be selling its own capacity rather than solving your problem. We cover the platform option separately in our article on business process platforms.

1. Will the rights to the source code pass to you?

This section uses Turkish law as the example, which applies if your vendor is in Turkey or your contract is governed by Turkish law; check the equivalent rules in your own jurisdiction. Article 2 of Turkey's Law No. 5846 on Intellectual and Artistic Works counts computer programs, expressed in any form, as scientific and literary works. Under Article 18, the authority to exercise economic rights belongs to the author; for works created by employees in the course of their work, the rights are exercised by the employer. When you commission software from an outside company, however, you are not that company's employer. Article 52 also requires contracts on economic rights to be in writing and to list each right concerned separately.

In practice this means the sentence "the software will be yours" is not enough. The contract should state that the source code will be delivered, and list one by one which rights, such as reproduction, adaptation (modification) and distribution, are transferred, for what period and on an exclusive basis. If the project uses open-source components, a list of them and their license terms should be delivered too. Work with your legal adviser on the contract text; what you should expect from the company is that it accepts these clauses without argument.

2. Where will the code, servers and accounts live?

The minimum is that the code is kept in a repository (a Git repository) belonging to your organization, that domain, cloud and server accounts are opened in the business's name, and that the database is delivered with an understandable schema. If the software only runs on the company's server and you cannot export your data in a standard format, you are dependent in practice, even if you hold the rights on paper.

3. Who will protect personal data, and how?

If the software processes customer, employee or patient data, responsibility does not stay with the company alone. Taking Turkey as the example again, Article 12 of Law No. 6698 on the Protection of Personal Data (KVKK) requires the data controller to take the technical and administrative measures needed to prevent unlawful processing and access. The same article states that where data is processed by another person on the data controller's behalf, the two are jointly responsible for these measures.

Ask the company about the permission model (who sees what), access logs, and its approach to backups and encryption. Ask for a common reference for security testing: the current edition of OWASP Top 10, which lists the most critical risks in web applications, is 2025. Instead of "we take security seriously", listen for which tests they run and at which stage.

4. How will discovery and scope be written?

A solid project starts with discovery and analysis: the process map, screens, user roles, integrations and reports are clarified; then come design, development, testing and launch. A fixed price given without discovery either grows later or ends in an incomplete delivery.

Put what is out of scope in writing as well as what is in scope. Each phase should have acceptance criteria, such as "this phase is accepted when a purchase request passes three levels of approval and is transferred to the ERP". Phased delivery with approval at each phase makes surprises visible early.

5. How do testing, environments and rollback work?

Ask whether development, test and production environments are separate, where an update is tried first, and how a bug that reaches production is rolled back. A team with automated tests, code review and release notes can keep developing at the same speed two years from now. A team that cannot give concrete answers is most likely skipping these steps.

6. How will it talk to your existing systems?

Custom software does not live alone: it exchanges data with accounting, ERP, CRM, e-commerce, shipping and payment systems. The proposal should list the integrations, the direction of each one (which data is written where) and who is responsible when it breaks. In businesses that use an ERP, the ERP should remain the single source of truth, with the custom software carrying the processes around it. You can find the details of this design in our article on CRM and ERP integration.

7. How will documentation, handover and maintenance work?

Software should live on after the team that wrote it is gone. An installation document, an architecture summary, a list of environment variables, integration documentation and a user guide should be part of the delivery. Ask the company: "If another team took over this system tomorrow, what would they read?"

The maintenance contract for after launch is discussed from the start: response times by bug category, monthly scope, security updates, how small developments will be charged and the communication channel. Also ask whether the knowledge sits with at least two people, so you are not tied to a single developer who knows the system.

Proposal comparison checklist

• Have off-the-shelf, platform and custom options been compared, with reasons?
• Are the transfer of economic rights and the delivery of source code written out one by one in the contract?
• Are the repository, domain and server accounts in the business's name?
• Are the approaches to personal data, permissions and security testing defined?
• Are out-of-scope work and acceptance criteria in writing?
• Is there a separation between test and production, and a rollback method?
• Are documentation delivery, handover support and maintenance response times clear?

At Piküp Medya we build custom web-based software where an off-the-shelf package falls short, and for processes that follow a known pattern we recommend Nexfabra, our own business management platform; we make the choice between the three together with you. You can review the scope in our web and software services.