Choosing a software contractor is not like buying a product off the shelf. You are buying a promise of work that will take months, and its result will run in your company for years. That is why the question of how to vet a software contractor before signing a contract does not end with comparing three PDFs with quotes. It is about something else: whether the team on the other side understands your business problem, knows the limits of the technology and can tell you what cannot be done. At Web Systems we have been doing custom software development since 2006: web and mobile applications, B2B systems, API integrations and AI solutions. So we have seen both projects run by the book and projects taken over from someone else halfway through. Below is what really separates good contractors from skilled salespeople.
Table of contents
What you are really looking for before you start checking offers
Vetting starts with you, not with the contractor. Before you judge anyone’s skills, you have to name what you are ordering. An MVP to validate a market idea, an internal B2B system meant to work for the next decade, modernizing an application that has been running for eight years - three completely different undertakings. A different approach, a different pace, different people.
A prototype rewards speed and a readiness to throw away half the code after the first tests with users. A system that integrates with an ERP rewards caution, knowledge of data structures and patience in talks with the vendor of that system. A team that is great in the first scenario is often average in the second. And the other way round. If you do not make this distinction, you will ask everyone for an “application” and get offers that simply cannot be compared on substance.
And that is when the typical trap appears. Since the documents look alike, the decision is made on the amount. Except that the difference in price usually does not come from the other side’s greed, but from a different understanding of the scope. One contractor priced a form. Another priced the same form plus data validation against an external register, error handling and an admin panel for correcting mistakes.
Warning sign: the contractor gives a specific number before asking about data volume, the number of users, the required integrations and what happens to the application at the peak of the season. A quote without questions is a quote for something other than your project.
Tip: write down three things on one page - the business problem to solve, the processes the application has to handle, and the systems it has to talk to. That sheet will do more for the quality of the offers than a twenty-page specification written without knowing the technology. Send it to every company you ask and watch who follows up with questions and who sends a price list straight away.
Experience you cannot see in a portfolio
A portfolio shows the visual result, not the technical difficulty. A good-looking shop can be a standard rollout of an off-the-shelf engine, while a visually dull logistics panel can be the hardest project in the company’s history, because it synchronizes stock levels between four systems in real time. Screenshots do not show that.
Instead of a gallery, ask for a description of the challenges. The question is: what was the hardest part of this project and how was it solved. The answer “everything went smoothly” is suspicious. IT projects do not go smoothly, at best they go well managed. A contractor who can tell you about a wrong architectural assumption from the start of the work and how they corrected it tells you more than twenty logos on a website.
Ask separately about projects maintained for years. Handing over a system and disappearing is not the same as seven years of looking after a growing application, during which framework versions, legal requirements and partner APIs have changed. Long client relationships are harder to fake than one-off projects.
- Team continuity - whether the people who built the project from three years ago still work at the company, or whether only a name in the portfolio is left of them.
- Company track record - a business that has been operating for more than a decade has already been through several technology shifts and at least one economic slowdown.
- How they talk about failures - a specific story of a fixed mistake carries more weight than a claim of never having had a failure.
Check references sensibly. A conversation with a client a week after acceptance brings enthusiasm. A conversation a year later - the truth about maintenance costs, response times to tickets and whether anyone picks up the phone once the project is no longer new. Ask about that second moment.
Technical questions that filter out contractors
You do not have to be a developer to ask filtering questions. It is enough to listen for whether the answer contains reasoning or just names of technologies. Ask for a description of the proposed architecture and an explanation of why this one in particular. A monolith can be the right choice for a system used by thirty people, and splitting it into microservices can generate operating costs with no business benefit at all.
The second area is security and personal data. Ask how authentication works, where passwords and tokens are stored, who has access to the production database and how permissions are divided in the application. If the system touches personal data, you should hear about encryption, retention, access logs and minimizing the information collected.
The third area is integrations. That is, the place where most budgets disappear. The API call itself is simple. The trouble starts with rate limits, a partner being temporarily unavailable, repeated events and data that arrived incomplete.
- What happens when an external API responds with an error or does not respond at all - is there a queue, a retry, a limit on attempts.
- How do you detect duplicate events so that one transaction is not booked twice.
- Where do records rejected by validation go and who looks at them.
- How will the system behave when the data volume grows several times over - what will become the bottleneck then.
Also ask about working hygiene: automated tests, CI/CD, a separate test environment, event logging and monitoring. A contractor who deploys changes straight to production saves now and sends you the bill later. Proven many times over. With implementations based on artificial intelligence, ask about the token cost under real traffic, the quality and preparation of the input data and the way results are controlled - a model that generates unpredictable answers in a customer service process needs a framework, not just a prompt.
Pricing, schedule and billing model
Fixed price is tempting because it is predictable, but it only works when the scope is described precisely enough that both sides understand it the same way. The more precise the description, the more analytical work before the start. And that work costs money too. A contractor who agrees to a fixed price with vague requirements has either protected themselves with a thick buffer or plans an amendment with every change.
Time and material gives flexibility and honestly reflects the effort. However, it requires trust and reporting that can be verified. A sensible compromise is often to split the project: a paid analysis and technical design in the first stage, and only on that basis a binding quote for the build. You then spend a small part of the budget to find out how much the rest really costs, and you can walk away with the documentation to another team.
A very low offer rarely means exceptional efficiency. More often it means a narrowly understood scope, skipped tests, no data migration or the assumption that you will provide the content, graphics and infrastructure configuration yourself. Add that up later and compare it with the offer that seemed expensive.
An estimate with no breakdown into stages cannot be checked. A single amount for everything does not let you judge whether anyone even thought about the admin panel or about importing the old data. Ask for a breakdown into modules and features, with the time for analysis, testing, deployment and project handover shown separately.
Also agree on what happens when the scope changes during the work. Because a change will happen. You need a simple path: request, quote for the change, approval, delivery. Without it, every modification becomes a negotiation from scratch.
Tip: compare offers by their assumptions, not by the final amount. List in a table what each contractor treated as included and what they passed over in silence. The differences in that table will explain the differences in price better than any sales conversation.
Code, data and licenses - who owns what when the project ends
This is the most often neglected part of the contract. And at the same time the one that can block a company for years. Paying for software to be built does not automatically mean acquiring the rights to it. The transfer of economic copyrights has to be written down explicitly, with the fields of exploitation listed, and it has to cover the right to modify the software and to commission changes from other parties. Without that last point you formally own code that you cannot freely develop.
Access to the repository from the first day of work, not after final acceptance, is just as important. Ongoing insight into the code is not a lack of trust, it is a basic safeguard for continuity. If the cooperation ends halfway through the project, you have everything that has been created so far, along with the change history.
The infrastructure should belong to you. The domain registered to your company, cloud accounts set up on your address, API keys for external services issued to your accounts, and the contractor added as a user with the right permissions. The reverse setup, where everything hangs on the agency’s account, turns an ordinary change of supplier into negotiations.
- Component licenses - ask for a list of third-party libraries and their licenses, especially for software you intend to sell or make available to clients.
- Data export - there has to be a way to pull out the complete data set in a readable format, without writing an extra tool.
- Handover documentation - a description of the architecture, instructions for setting up the environment and a list of dependencies, so that another team can take over the project without doing archaeology in the code.
Also check whether the project contains any closed proprietary components of the contractor, licensed only for the duration of the cooperation. That is acceptable, but you have to know about it before signing, not when you try to migrate.
Contract clauses that save a project
A contract is not a document for when a conflict breaks out. It is a record of how both sides understand the cooperation, and that is why it is worth giving it time before the start, while the relationship is still good. First on the list: the definition of acceptance. “Done” has to have a specific meaning - a set of test scenarios that pass, a launch on the indicated environment, documentation handed over, a named person who confirms acceptance and a deadline for raising comments.
A warranty described in a few catchwords does not work. You need bugs divided into categories with response times assigned to them. A failure that blocks sales is a different matter from a misplaced button, and the contract should tell them apart. Also agree on the hours in which those times apply and what happens outside them.
Describe the communication rules. Who is responsible for the project on the contractor’s side, who stands in for that person during leave, how often you get a progress report and through which channel you raise comments. Projects fall apart more often from information chaos than from technical difficulties. One decision-maker on each side saves weeks.
If the application processes personal data, you need a data processing agreement that defines the scope of the data, the purpose, the subcontractors, the server locations and the rules for deleting the data once the cooperation ends. It is sometimes treated as a formality to sign in a hurry. Yet it is real protection in the event of an incident.
Finally, the exit terms. Write down what happens when the contract is terminated: the handover of code, data, access credentials, documentation and configuration within a set deadline, and the settlement of the work done. A well-described parting is usually never needed, but its absence turns an ordinary change of supplier into a dispute that drags on for months.
Maintenance after launch - the most often overlooked part of the choice
An application only really starts to cost money after launch. That is when library updates appear, along with security patches, changes in partner APIs that force integrations to be reworked, growing infrastructure bills as traffic increases and small fixes reported by users who have finally started using the system. A contractor who stays silent about this stage in a sales conversation has either never maintained anything for a longer time or is deliberately avoiding an uncomfortable topic.
Monitoring, backups and the restore procedure should be agreed before launch, not after the first failure. A backup on its own means nothing if nobody has ever checked that a working system can be restored from it. Ask directly what the restore test looks like and how long it takes to get back to work after a serious incident.
Agree on who responds to a failure on a Friday evening and on what terms. The answer “we will work something out” means there is no procedure. You have to know whether there is an on-call service, how it is triggered, how much it costs and what it covers.
Also check their ability to come back. In six months you will want to add a reporting module or connect a new payment system. A company busy only with new projects, with no process for serving past clients, may not have people available then.
Common mistake: choosing the cheapest contractor for the build on the assumption that someone else will take over maintenance. Taking over someone else’s code without documentation, tests and a record of design decisions costs more than the initial saving, and the new team first has to work out what must not be touched. Treat the build and the maintenance as one decision.
Summary
Vetting a software contractor before signing a contract means assessing how they think about the problem, not comparing price lists and project galleries. A nice portfolio and an attractive amount will not tell you how the team will behave when an integration starts returning errors, the data volume grows beyond the assumptions or the requirements change halfway through the work. What will tell you is the answers to questions about architecture, security, exception handling and maintenance.
The biggest risk does not sit in the visual layer. It sits in integrations, data quality, rights to the code and what happens after launch. Secure these four areas in conversation and in the contract, and the rest can be fixed along the way. A good partner talks about limitations, trade-offs and maintenance costs of their own accord already at the offer stage, because they prefer a difficult conversation now to a conflict a year from now.
Are you planning an MVP, a web or mobile application, an API integration, process automation, an AI-based solution or the modernization of a system that can no longer keep up with your company? Write to us. We will gladly look through the offers you have on your desk and suggest what to ask about before you sign anything.
