How to choose a software development company without gambling on the project

Why the choice feels like a gamble — and the question to ask instead of "who is the best"

After two meetings with development companies, the differences start to disappear. They all present nice projects, an experienced team, and an orderly process. You are left with different quotes, a gut feeling, and a lot of words you cannot verify.

The real fear is not choosing a less well-known company. You are afraid the project will get stuck, that the only person who understands it will disappear, or that you will get a system no one else can touch. That is why the question "who is the best?" is not the right question.

Ask instead: who carries responsibility at every stage, and what exactly comes back to me if something goes wrong?

A software development company can be excellent at code and still leave you alone with a vague requirements document, a price that grows, or a system with no clear way forward. By contrast, a provider that holds the entire chain of responsibility reduces the number of decisions you have to make in the middle of the pressure.

This is true both when you are considering software development outsourcing and when you are looking for a local software house. The gap is not in the name of the model. It is in the responsibility that stays with you without you intending it to.

The chain of responsibility: the seven links every software project goes through

Every project goes through seven links: requirements document, pricing, team, process, code, delivery, and the day after. Instead of giving each candidate a general score, mark next to each link who actually holds it.

• Requirements document — who defines the problem, the users, the boundaries, and the acceptance criteria.
• Pricing — who connects the defined scope to the cost, the risks, and the changes.
• Team — who works on the project, who replaces them, and who makes professional decisions.
• Process — how you move forward from week to week, check deliverables, and approve a change.
• Code — who is responsible for quality, security, infrastructure, and the ability to maintain the system.
• Delivery — what you receive at the end, in what state, and with what information you can continue working.
• The day after — who handles bugs, changes, updates, and events that were not planned.

In a clinic with two reception stations, a new system can look simple: a form, a calendar, and WhatsApp messages. But if it was not defined what happens when a patient cancels, when two secretaries edit the same appointment, or when there is no reception, the problem is not technological. The requirements document link has fallen.

A company that holds a link provides an owner, a document, a decision, or a testing mechanism. A company that rolls it over to you usually says: "you define it," "you choose," "you check," or "we'll talk about it later."

This model is not a tool to punish a candidate. It is a tool to see the risk before it becomes your task.

Links 1–2: Requirements document and pricing — who holds the definition of the problem and who holds the price

A good company holds the requirements document as a collaboration, not as a requirements form you have to write on your own. It connects the business problem, the users, the edge cases, and what will count as success.

Link 1: Requirements document

A software project's requirements document should answer questions that are not technological:

• Who uses the system every day?
• Which decision does he need to make?
• What happens when there is no data, when there is duplicate data, or when someone changes it?
• Which actions must be documented?
• What will not go into the first version?
• How will you know the process improved?

In an accounting firm in February, a document intake system is not just an upload screen. It needs to define who checks a missing document, who gets a reminder, and what happens when a client sends an old file. A candidate who talks only about screens has not yet held the requirements document.

The exposure question: "Which decision do you need from us in order to close the requirements document, and which decisions can you make on your own?"

A good answer will detail the path: a process workshop, a decisions document, a prototype, or use cases. A weak answer will ask you to send a list of features and promise to start from there.

Link 2: Pricing

Software development cost is not examined by the last number in the proposal. You check what was defined, what was not defined, who carries the risk of uncertainty, and what happens when a new detail is discovered.

A responsible proposal separates the stage of understanding the problem from building the system, states assumptions, shows what is included and what is excluded, and explains how a change is approved. It does not have to promise a fixed price. It has to make the uncertainty visible.

Suppose an insurance agency asks for a customer portal. Only later does it turn out that the portal needs to display documents from several systems, send a message on WhatsApp, and document permissions. If the original proposal did not say what the source of the information is and what counts as a connection, the addition did not appear because the supplier "surprised" you. It simply was not defined.

The exposure question: "Which assumption in your proposal, if it turns out to be wrong, will change the scope or the price?"

Ask that the assumptions appear in the document itself. That way you can compare proposals by level of risk, and not by an amount that is disconnected from the work.

Links 3–4: The team and the process — who actually works on the project and what a work week looks like

The team and the process are where a commercial promise meets your week. Do not settle for the name of a project manager or a diagram of stages; check who does the work and how you see it.

Link 3: The Team

Ask who the permanent people on the project will be, who approves decisions, who reviews the code, and who steps in when a central person is unavailable. There is no need to demand an inflated list of roles. You need to know whether there is clear ownership.

A freelancer who disappears after a while is not necessarily an unprofessional person. The risk arises when the knowledge sits with him alone, there is no documentation, and there is no other person who can understand the system. A large company can create the same risk if the team changes and you meet a new person every time.

The exposure question: "Who will actually do the work, who replaces him if needed, and where are the team's decisions documented?"

Ask to meet at least the person who will make professional decisions during the build. A sales presentation is not proof of the team composition you will get.

Link 4: The Process

A good process lets you check a deliverable before the entire budget is already behind you. You need to know what will happen this week, what is waiting for your approval, and what counts as a change.

A reasonable work week can include choosing a scenario, building, your testing, fixing, and deciding on the next step. It does not have to be called a sprint. The name matters less than the pace at which tangible evidence is created.

In an online store that replaces an Excel sheet with an order system, a demo of a pretty screen is not a sufficient deliverable. You need to test a partial order, a cancellation, a return, and a sync error. These are the places where the process exposes reality.

The exposure question: "What will we see at the end of the first week, and what happens if we do not approve the deliverable?"

A responsible answer will explain the checkpoint and the effect on what follows. A vague answer will talk about "progress" without showing what you will be able to open, test, or reject.

If you are not sure which process is even worth automating, start with business automation: which process to choose first. Choosing the right project before choosing the provider saves an argument about a system that does not solve the main problem.

Links 5–6: The Code and the Handover — Who Owns the Code and What Happens the Moment the Project Ends

In the code and the handover, you need to separate the company's business information from the software that was built. The information must be accessible and exportable; the contract must define what you receive in order to operate, maintain, and continue the system.

Link 5: The Code

Don't just ask "who owns the code?" Ask what exactly is included in the term code. Is it the repository, the infrastructure settings, the deployment scripts, the documentation, the API connections and the accounts required to run it?

A brokerage office's system can work perfectly well as long as one person holds the password, knows the connection to the advertising system and remembers why a certain alert was built. Without orderly permissions and documentation, the code exists but the ability to use it is limited.

Also check how changes are tracked, who approves access and how actions are documented. Secure login and the existence of a full activity log — who did what, when and from which address — are basic mechanisms worth asking to see in a relevant system.

The exposure question: "What material will we receive if we need another developer to examine the system, and what will remain dependent on your internal knowledge?"

Don't settle for the answer "everything is yours." Ask for a list: information, documents, permissions, documentation, work environments, connections and the export process.

Link 6: The Handover

A handover is not the moment when a message is sent that the system went live. It is a transition point with clear acceptance conditions. You need to know which scenarios were tested, which gaps are open, who approves, and what material remains after launch.

In the clinic, a system can go live but fail on the day two reception stations change the same appointment. A serious handover includes such test scenarios, permissions for every role, an operational explanation and documentation of issues still being handled.

A good agreement also defines the option of export. When the engagement ends, the client's data is available for export for 30 days. Don't confuse the ability to extract the information with receiving the software itself. These are different things that should be written separately.

The exposure question: "What exactly counts as a handover, and who signs that the system is ready for use?"

A good answer will present an acceptance list by scenarios. A dangerous answer will say the system will be handed over "when everything works," without a definition that can be checked.

Link 7: The day after — maintenance, bugs, changes and continuity

The day after begins before launch. A good contract and process define who handles a bug, who approves a change, who follows security updates, and what happens when the system depends on an external service.

Separate between four states:

• Bug — the system does not do what was agreed it would do.
• Change — you are asking for new behavior or a new process.
• Operational event — a service, connection or infrastructure is unavailable.
• Improvement — an idea that extends the system, but is not a malfunction.

This separation prevents an argument every time something changes. In a law firm, if an existing document search returns a wrong result, that is a bug. If you ask to add a search by a new field, that is a change. If an external provider does not send information, that is an event that needs a checking and handling mechanism.

Ask what is included in maintenance, who receives a request, how the handling is visible and what requires additional approval. Do not rely on general phrases like "ongoing support". They do not say who does what on a busy day.

If you are considering automations based on Make or Zapier, check in advance who monitors a failure in the connection and who handles a change at the external service. Business automation: when automation based on Make and Zapier turns from an asset into a burden explains why automation without an owner quickly becomes another ticket queue.

The practical rule: if there is no owner, no reporting channel, no documentation and no definition of a normal state, you do not have maintenance. You have hope.

Five questions in the first conversation that reveal who holds each link

In the first conversation, do not try to impress the candidate with technical knowledge. Ask questions that force her to describe responsibility, decisions and boundaries.

1. "What do you need to find out before you can give a serious quote?"

The question tests the requirements document and pricing links. A responsible candidate will ask to understand users, processes, information, connections, exceptions and what is not included. If she gives a number immediately, check which assumptions it rests on.

2. "Which part of the work stays with me as the project manager?"

The question tests whether the team holds the process or expects you to manage every detail. You still need to make business decisions, approve priorities and give people access. You are not supposed to chase tasks, write a technical specification and check the quality of the build yourself.

3. "Who will actually work on the system and what will happen if he does not continue?"

This is a check of the team link. Ask for role names, a point of responsibility and a documentation process. The answer should explain how the knowledge is preserved, not just who appears in the sales call.

4. "What will I receive if the engagement ends?"

The question tests code, handover, and information. Ask for a detailed list of the information, documentation, permissions, integrations, and operational materials. Make sure the client's data can be exported for 30 days after the engagement ends.

5. "Give an example of a bug that became a change, and how you handled it"

The question exposes the day-after link. A good answer describes classification, a decision, documentation, and communication. A weak answer shows there is no agreed boundary between a fault and a new request.

Ask for the answers in writing after the conversation. Not to create bureaucracy, but to check whether what was said verbally also appears in the proposal and the agreement.

Red flags: the signs a company rolls responsibility back onto you

A red flag is not an unsuccessful sentence. It is a sign that a certain link is not held by anyone.

• "No problem, we'll build everything" before questions were asked — the requirements document link does not exist.
• An all-inclusive price on one line — the pricing is not connected to scope, assumptions, or risk.
• The team will be determined after signing — you do not know who holds the team link.
• A fixed demo every week with no artifact that can be checked — the process is a ceremony, not a decision mechanism.
• "The code is yours" with no list of assets — there is no practical definition of handover.
• No answer to the question of what happens when you leave — the information, permissions, and handover were not defined.
• Every fault is called a change — the day-after responsibility is rolled onto you.
• Every change is called a bug — the company is in practice promising unlimited scope.
• Only a salesperson shows up at meetings — you are getting a promise, not a professional owner.
• The candidate refuses to show an example of a document or process — she is asking for trust instead of presenting a way of working.

A request to sign a nondisclosure agreement is also not a substitute for checking. You need to protect sensitive information, but it does not prove capability in the requirements document, in development, or in maintenance.

The document itself: the responsibility chain table — fill it in against every candidate before committing

This table is your selection document. Copy it into a working document, create a separate column for each candidate, and fill in only answers you can point to in a proposal, a contract, a demo, or a conversation with a reference customer.

Acceptance questions you can add below the table

• Did every link get a person or team as owner?
• Is there a link you hold without having the time, knowledge, or authority to hold it?
• Do the proposal and the contract use the same definitions?
• Does one candidate hold more links, or just present them better?
• Which link would hurt you most if it fell?
• What will you do if the answer to that question is not written down?

There is no need to give every row an academic score. It is enough to mark: held, shared, with you, or not defined. A company that holds six links but is not ready to define delivery is different from a supplier that holds three links and presents itself with confidence. This is not a question of who is "better". It is a question of the risk you are willing to manage.

What a proper two-week selection process looks like — without turning it into a project

A good selection is not research that drags on for months. Within two weeks you can reach a decision if you check responsibility rather than collect more presentations.

Days 1–2: Define the problem and the boundaries of the decision

Write down who the users are, what does not work today, what must improve in the first version, and what will not be built. If you are debating between a custom CRM and a SaaS product, first read Custom CRM or SaaS? The question is not price. The question is change. The technology choice should come after understanding the business change.

Days 3–4: Send every candidate the same material

Send a short description of the process, two normal scenarios, and two edge cases. Do not send a full requirements document if you do not yet know what is right. Ask every candidate to note assumptions, open questions, and the links she holds.

Days 5–7: Hold a conversation with the chain questions

Use the five questions above. Write down not only the answer, but who answered, what was promised, and what remained open. A company that asks for time to understand the problem is not necessarily slow. Sometimes it is the only company that is not selling you false certainty.

Days 8–10: Compare documents, not presentations

Compare the responsibility table, the assumptions, the acceptance conditions, the definition of change, the delivery materials, and the post-launch handling. If you are examining a system for managing customers, CRM for small businesses: the complete guide to selection, requirements document, and implementation will help you identify which processes should go into the review.

Days 11–12: Check a reference about a specific link

Do not ask only "Would you work with them again?" Ask: who held the requirements document? What happened when the price changed? Who handled the bug after launch? Did you know how to export the information? The answers are more effective when they are tied to a link and not to a general feeling.

Days 13–14: Decide what you are buying and what you are keeping

Choose the candidate whose proposal leaves you with the most understandable and reasonable risk, not necessarily the cheapest or the longest proposal. Before signing, make sure the shared links have received clear owners and that there is no verbal promise that does not exist in the document.

If after the two weeks you still do not know who is responsible for a fault, you have not finished choosing. You are only closer to signing.

We at alcyone14 build custom software, and in the first conversation we fill in the responsibility chain table with the client before talking about a solution. If you want to examine your project through the seven links, you can start from a tailored system for service businesses and see which responsibilities remain with you.

Frequently asked questions

Should you choose a software development company by the lowest price?

No, because a low price without scope, assumptions, and acceptance conditions does not allow comparison. Check who holds each link and what will happen when a need that was not defined is discovered.

What is the difference between a software house and a software development company?

Usually there is no practical difference that decides the choice; the two names can describe very different providers. Check the chain of responsibility, the actual team, the delivery process, and the maintenance after launch.

Do I need to understand technology to choose a software development provider?

You do not need to know how to evaluate every line of code, but you do need to ask who is responsible for quality, permissions, documentation, and delivery. Questions about scenarios, owners, and deliverables give you a better indication than a list of technologies.

What must be in an agreement with a software development company?

The agreement must define scope, assumptions, acceptance conditions, the change approval process, role owners, maintenance, and delivery materials. It is worth defining separately the business information, the possibility of exporting it, and the software that was built.

How do you check whether the company will remain responsible after launch?

Ask to separate a bug, a change, an operational incident, and an improvement. Then check who receives each type of request, how the handling is documented, and what is included in maintenance.