Short answer: the 5 steps of commissioning custom software
Commissioning custom software takes five steps: define the problem, write a brief, ask for quotes against the same brief, start with a small discovery or prototype phase, then move to development and release. The preparation that helps most before you ask for a quote is a written brief that describes what you want as a problem, not as a solution.
The first answer to "how many weeks will it take?" is a range, not a number. According to Construx, an estimate made very early in a project can be off by up to 4x on the high side and 4x on the low side (a total range of 16x), and organizations that commit too early work with a 2x to 4x error margin. So a sound quote offers a plan divided into phases with a re-evaluation at the end of each, instead of one fixed date.
| Step | What you do | Output |
|---|---|---|
| 1 | Write the problem and what is out of scope | A one-page problem statement |
| 2 | Prepare the brief | Scope, users, constraints, budget range |
| 3 | Give the same brief to 2-3 vendors | Quotes you can compare |
| 4 | Start with a discovery or prototype phase | Scope and plan become clear |
| 5 | Development, testing, release and support | Working software and a support agreement |
At the end of the article there is a brief template you can copy.
How do you write a brief?
Should you write the solution or the problem?
The UK government's service manual (GOV.UK Service Manual, updated 21 June 2021) recommends that in the first phase, discovery, you do not start building the service; you first frame the problem and explicitly agree what is not part of it. It is a public-service guide, but the logic holds for any custom software: instead of "we want these screens", write "this process is failing and this is the result we want". You design the solution with the vendor; a solution you draw up front can close off a better route.
What should the brief contain?
Our suggested minimum list: problem and goal, who will use the software, what is in scope and out of scope, priority features, systems it must connect to (ERP, accounting, e-commerce), constraints (regulation, data protection, infrastructure), success measure and acceptance criteria, budget range and schedule constraint. The TÜBİTAK BİLGEM "Application Software Development" guide likewise expects the needs analysis to include a detailed analysis of the system, a cost analysis and a project plan.
Would ready-made software do?
Ask this before the brief. The TÜBİTAK BİLGEM guide also recommends assessing the packaged-versus-custom choice up front. For the decision, see our off-the-shelf vs custom software decision matrix; for ready-made products such as ERP, we collected what to ask in 12 questions to ask when choosing an ERP vendor in Izmir.
15 questions to ask yourself before requesting a quote
These are questions for you before they are questions for a vendor: the answers become the brief. If you cannot answer all of them, that is not a problem; it is a sign that they belong to the discovery phase.
Problem and scope
- Which problem are we solving, and why now?
- What is this problem costing us today (time, errors, lost sales)?
- What stays out of scope?
- Who will use the software, and who will approve it?
- What criteria must be met to say "done"?
Technical and legal
- Does a ready-made product (packaged software) not meet this need?
- Which systems must it connect to (ERP, accounting, e-commerce, banks)?
- What constraints exist (regulation, data protection, current infrastructure)?
- Who will own the source code, and how will transfer or licensing be written?
- Will the vendor access personal data, and how will security measures be ensured?
Commercial and operations
- Will the price be fixed, time-based or hybrid?
- How will extra work be priced if scope changes?
- How will maintenance and support work after release (duration, response time)?
- What are the exit terms: if we part ways, how do I get the code, data and documentation?
- How will secure development and testing be done?
Project phases and timing
What phases does a project go through?
A general summary: discovery and analysis, design or prototype, development, testing, release, maintenance and support. The GOV.UK manual also splits work into discovery, alpha, beta and live; it gives a typical discovery length of 4-8 weeks and a typical alpha length of 6-8 weeks, and it expects the code written in alpha to be thrown away. These were written for public services and are not measured durations for custom software projects in Turkey; we cite them only to show the logic that "the first phases are not the duration of the full software". We could not find reliable published duration data for custom software in Turkey.
Fixed price or time-based?
A fixed price needs a clear scope; if scope changes, extra work is priced separately. A time-based model is flexible but needs tracking; on the customer side, a cap (for example a budget ceiling for each phase) is a common safeguard. Our recommendation is to go hybrid: do the discovery phase as hours or a small fixed package, then discuss a price for development using the clear scope that comes out of it. As Construx warns, commitments made too early weaken predictability and raise risk.
Why is time a range?
Because uncertainty falls as the project progresses. Construx writes that meaningful commitments become possible in the early-middle part of a project (about 30% of the way in). If a quote shows a single end date, ask how it was calculated and what happens if scope changes.
Local vendor: advantages and disadvantages
We could not find a source confirming that "meeting on site and being nearby improves project success", so we do not write it as a firm advantage. In practice, being in the same city means you can hold meetings at your site, they can see your workflow in person and reference visits are easier. The question left over is whether that advantage is written into the contract. Pin down in the offer how many on-site meetings there will be, at which phase and whether they carry extra fees. Let your criteria be references, the plan and the contract, not the city.
Source code and contract: which clauses should be in writing?
This section is not legal advice; consult a lawyer for contract clauses. Three things to know:
- Computer programs are works. The Turkish Law on Intellectual and Artistic Works (Law No. 5846, FSEK) counts computer programs expressed in any form as works (Article 2).
- Transfer of rights must be in writing. Under FSEK Article 52, contracts on financial rights must be in writing and the rights they concern must be listed separately. So "the source code will be delivered to us" is not enough on its own: source code delivery, a usage license and transfer of rights should each be stated separately and in writing.
- You keep data responsibility too. Under Article 12 of the Turkish data protection law (KVKK), the data controller must take all necessary technical and administrative measures to prevent unlawful processing of and access to personal data; if personal data is processed by another person on its behalf, it is jointly responsible with them for those measures. If the vendor will access your data, put that and the security measures in writing.
For secure development you can ask the vendor which frameworks it follows: OWASP's Application Security Verification Standard for web applications (ASVS 5.0.0, May 2025) and NIST's Secure Software Development Framework (SSDF; the NIST page says it can be used by acquirers as well as software producers).
Brief template
Fill in these headings and give the same text to every vendor:
| Heading | What you write |
|---|---|
| Problem | Which process is failing, and what does it cost? |
| Goal and success measure | What do you want to change, and how will you measure it? |
| Users | Who will use it, how many, in which roles? |
| In scope | What the first release must include |
| Out of scope | What will not be there for now |
| Systems to connect | ERP, accounting, e-commerce, banks, other |
| Constraints | Regulation, data protection, infrastructure, existing software |
| Budget range | A figure or a range; it keeps the quote realistic |
| Schedule constraint | If there is a mandatory date, why |
| Contract expectations | Source code, maintenance, exit |
Frequently asked questions
What should a custom software brief contain?
Problem and goal, users, what is in and out of scope, systems to connect, constraints, success measure, budget range and schedule constraint. Describe the problem, not the solution; design the solution together with the vendor.
Is an on-site meeting in Izmir necessary?
We found no source showing it is mandatory. Seeing the process on site can help, especially for firms with physical work such as production, warehouses or field operations; make it a written clause in the offer (how many meetings, at which phase, any extra fee).
How many weeks does a project take?
We could not find reliable published duration data for Turkey. It depends on scope, integrations and how fast you approve things. Remember that any early estimate has a wide error margin (up to 4x in both directions according to Construx): that is why you should ask for a plan divided into phases.
Who owns the source code?
It depends on what the contract says. Under FSEK Article 52, contracts on financial rights must be in writing and list the rights separately; state source code delivery, the license and transfer separately. For the exact clauses, consult a lawyer.
If you would like to go through your brief together, you can look at our custom software development page or get in touch.
Sources: How the discovery phase works (GOV.UK Service Manual, 21 June 2021), How the alpha phase works (GOV.UK Service Manual, 8 May 2019), The Cone of Uncertainty (Construx), Application Software Development guide (TÜBİTAK BİLGEM), Law No. 6698 on the Protection of Personal Data, Article 12 (Ministry of Justice), Law No. 5846 on Intellectual and Artistic Works (orgTR), OWASP ASVS, NIST Secure Software Development Framework
Cover photo: Vitaly Gariev / Unsplash