Choosing a software company in İstanbul

What should you decide first?

Before researching firms, answer this: what type of work is it? There are three, and they call for different competence. Building a new product is work that needs discovery, design and architectural decisions. Extending an existing system requires the ability to work within that system's constraints. Adapting an off-the-shelf package requires knowing the configuration, not building the product.

Proposals gathered without making this distinction cannot be compared, because each firm translates your question into the type it is good at. The package integrator proposes a package, the product team proposes writing from scratch — both are right from where they stand, and neither is answering your question.

How many kinds of software company are there?

“Software company” does not describe one thing, and choosing well starts with seeing the distinction.

If your work sits between two of them, let this question decide: will it still be alive after the project ends? If it will, you need a team that can take ownership; if it is a one-off delivery, a narrow solution is enough.

Why can't you trust “best software companies” lists?

Because most of them are written by a software company that sits first on the list. The format spread because it performs well in search; what determines the order is not measured performance but who wrote the piece. The second group is directories that accept paid placement — there, position correlates with visibility budget.

That does not make the lists worthless; they are usable for generating a candidate pool. But as a starting point, not a ranking. Draw the decision from the questions you ask the candidates, not from the list.

How do you tell whether a team is genuinely capable?

Reference count does not show competence; a team that has done the same job fifty times can be a novice on a problem unlike yours. What shows competence is the quality of the answer to a hard question at the proposal stage. Four questions separate them.

• **“How would you break this work up, and why?”** A good answer contains a rationale, not a list: which piece goes first and what uncertainty that removes.
• **“What could go wrong here?”** A team that can name the risks up front has done this before. “Nothing will go wrong” is not reassurance, it is a sign of inexperience.
• **“Who runs this system after delivery?”** A proposal without an answer means a system nobody can touch six months later.
• **“Which part would you not build?”** A suggestion that narrows the scope rather than widening it is the strongest sign the bidder understands the work.

Which six facts should the brief contain?

Comparable proposals depend on an identical brief. Six facts are enough: the problem to solve (not a feature list), who will use it, the existing systems it must connect to, the reason behind any date constraint, a budget range, and who makes the decision.

Sharing a budget range does not weaken your position, it makes the proposals useful. Without one, every firm prices against its own assumption and you receive three numbers that cannot be compared. With one, the question stops being “how much” and becomes “what can be built for this” — and that answer is the one worth having.

Five clauses to look for in the contract

• **That source code and design files belong to you**, and which account the code lives in.
• **That store accounts are opened in your name**; if the app is published from the agency's account, that a transfer will be executed within a defined period on request.
• **The scope and duration of post-delivery maintenance**: which bug fixes, store-policy compliance and dependency updates are included, and for how long.
• **Team continuity**: how knowledge transfer works if the people doing the work change.
• **Acceptance criteria**: the definition of done; which tests passing means delivery is accepted.

None of these raise the price directly, but each one prices a risk. If it is not in the contract the risk stays with you, and it usually surfaces at the worst moment — when the relationship ends.