How to Choose a Custom Software Company: Seven Questions on Source Code, Handover and Maintenance

Problems that start when the project ends

In custom software, the mistake usually becomes visible after the project ends. The software works, but the source code stays with the vendor; there is no documentation; when the only developer who knows the system leaves, nobody can touch it; a small change takes months. Eventually someone says "let's rewrite it" and the budget is spent a second time.

Almost all of these problems are visible when the company is chosen. The seven questions below are asked in the proposal meeting; get the answers in writing.

1. Do you really need custom software?

A good company asks this question first. Off-the-shelf packages fit most businesses' standard processes; the process that sets you apart from competitors is not solved by bending a package but by software built on your own workflow. There is also a third way: business process platforms that build approval flows, forms, rules and reporting without writing code; not every need requires software from scratch.

The question to ask: "For my need, which do you recommend, a package, a platform or custom development, and why?" A company that recommends custom software for every need is selling hours, not solutions.

2. Who owns the source code and the data?

The source code and data of the software you pay for should belong to you, and the contract should say so explicitly. If the code stays "locked" on the vendor's server, if a yearly payment is requested under the name of a licence fee, or if you cannot export your data, a dependent structure is being built.

The minimum: the code is kept in a repository opened in your name, access keys and server accounts belong to the business, and the database is delivered with an understandable schema.

3. How will documentation and handover be done?

Software should live on after the team that wrote it is gone. An installation document, an architecture summary, environment variables, an integration list 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?" If the answer is "they'd call us", there is no handover plan.

A good company defines handover support from the start: who answers questions, for how long and within what scope, in writing.

4. Architecture, security and testing: is there proof?

A system that works with ten users today should also work with hundreds of users in two years. Scalable architecture, the permission and access model, backups, automated tests and the release process are discussed at the start of the project; adding them later usually means rewriting.

Ask for proof: how do they test, which environments do they use (development, test, production), how do they roll back if a bug reaches production? The answers should be concrete; "we are careful" is not an answer.

5. How will it talk to your existing systems?

Custom software does not live alone: it exchanges data with accounting, ERP, CRM, shipping, payment and third-party services. The integration list and the owner of each integration should be in the proposal; data should not be entered twice, and the "systems that do not talk" problem should not appear.

For businesses running an ERP this matters even more: the ERP remains the single source of truth and the custom software carries the processes around it. A company that also knows the ERP side lowers the integration risk.

6. Process and scope: what happens from discovery to launch?

A solid project starts with discovery and analysis: the process map, screens, roles and integrations become clear; then design, development, testing and launch follow. A company that skips discovery and quotes a price directly will either grow the scope later or deliver less.

Scope and out-of-scope should be in writing: which modules, which integrations, how many roles, which reports, what the acceptance criteria are. Phased delivery with approval at each phase reduces surprises.

7. Who maintains it after launch, and how is it developed further?

The life of software starts at launch. The maintenance and development model for bug fixes, security updates, new features and capacity growth should be clear from the start: response time, monthly scope, hourly or package pricing, communication channel. Direct contact with a senior team removes layers in between and lost time.

Piküp Medya builds custom web-based software where off-the-shelf packages fall short: admin panels, automations, integrations and APIs; source code and data belong to the client, delivered with documentation and handover support. Because the Canias ERP implementation team and our own business process platform DeepBDP are under the same roof, we do not propose software from scratch for every need; we make the package, platform or custom decision together. Our offices are in Istanbul and Dubai and we work across Türkiye; let's map your need together in a free introductory meeting.