How to Choose a Development Contractor: The Question List and the Red Flags

Matching the vendor type to the project

Half of the projects that fail do not fail on execution, they fail on a mismatch between the class of the task and the class of the vendor. A freelancer handed a one-and-a-half-million project with five integrations physically cannot carry it, and an integrator asked for a landing page will spend the landing page budget agreeing a project charter. This is not about competence, it is about structure. Each vendor type has its own economics, and those economics decide which projects it does well and which it accepts out of politeness.

The key variable is how large your project is as a share of the vendor revenue. If your budget is large for them you get their strongest people, but you also carry the risk of a company stretched thin on you. If your budget is small for them you get stability and process, but juniors will do the work and your emails will wait three days. The sweet spot sits in between: your project is visible to the vendor but not critical to their survival.

In-house deserves its own line. Teams are built not because they are cheaper (over a horizon under a year they almost never are) but because the product needs continuous development and knowledge accumulated inside the company. The economics are simple: a lead, two developers, a designer and a QA engineer cost several hundred thousand roubles a month in 2026 whether or not there is work for them. In-house makes sense where the work is guaranteed for years ahead.

So that this article is not simply an advertisement for its author: by this classification Veltos.Tech is a small agency, and every limitation of that row applies to us in full. We close projects well in the range from a landing page to a web application, and we are not the right choice for systems-integrator work with multi-year integration into a corporate landscape. If your project is the second kind, the honest answer is to look for a different vendor class, and every question below should be asked of us exactly as it is asked of everyone else.

Twenty-five questions for the first call

The first call is not the vendor presentation, it is your interview with them. The value of the questions below is not in the correct answers but in how the vendor reacts: a confident team answers specifically and without irritation, a weak one retreats into generic phrases about a bespoke approach and a team of professionals. You do not have to ask all twenty-five in sequence, but do cover every group, because they are chosen to close different categories of risk.

The most informative group is about people. Projects are almost always sold by the strongest members of the firm: the owner, the art director, the CTO. Someone else will do the work. Asking who specifically will write the code, what their name is and how many projects they are on right now exposes the industry standard bait and switch, where a senior in the pitch becomes a junior with two parallel tasks on delivery. An answer of "we will assemble the team after signing" means there is no team right now.

The second most informative group covers process and estimation. What matters is not which methodology gets named but how precisely the person can describe what happens in week three of the project. A vendor with a real process will tell you about demos every two weeks, where the task board lives, who decides on ambiguous points and how scope changes are recorded. A vendor without one says "we are flexible", which in practice means the order of events will follow whatever mood the week brings.

• Team: who specifically will do the work, with names, roles and seniority?
• Team: how many other projects are those people running in parallel?
• Team: are they employees or brought in per project?
• Team: who is my point of contact and who covers them during leave?
• Team: what happens if the key developer leaves mid-project?
• Process: describe what happens in week three of the project.
• Process: where do I see tasks and progress, and will I have access?
• Process: how often are working results demonstrated?
• Process: how is a scope change recorded and who approves it?
• Process: who does the testing and against what checklist?
• Estimate: how many hours are allocated to each stage?
• Estimate: what is included in the price and what is billed separately?
• Estimate: what risks do you see in my project and what could they cost?
• Estimate: under what conditions does the number grow, and by how much?
• Estimate: how many revision rounds are included in design and in build?
• Communication: which channel do we use and what is the response time?
• Communication: who writes the copy and prepares the photography?
• Communication: what do you need from me and by when, to keep the schedule?
• Communication: how and how far in advance do you report a slipped deadline?
• Guarantees: what is the warranty period and what does it cover?
• Guarantees: what counts as a defect and what counts as a new task?
• Guarantees: show me two projects in my niche and tell me what went wrong on them.
• Handover: who owns the source code, the design files and the IP?
• Handover: in whose name are the domain, hosting and licences registered?
• Handover: what do I receive besides a working site, and what does the documentation look like?

How to read a portfolio properly

A portfolio in its presented form measures the wrong thing. Beautiful renders on a tilted laptop tell you about case presentation quality, not product quality. Three questions per case are more useful: what was the business problem, what exactly did this team do, and what changed in the numbers after launch. If the second answer is "we produced the design from the client mockups" and the third is silence, you are looking at a picture rather than a case.

Cases can be verified, and it is faster than it sounds. Open the site from the portfolio and check whether it is alive at all, because a surprising share of showcase links lead to domains that stopped responding or changed hands years ago. Look the domain up in a web archive: it shows when the site appeared in this form and whether another team rebuilt it afterwards. Check the footer or the page source for a studio credit, since a signature matching the person showing it to you is worth several slides of presentation.

The strongest check is calling the client from the case study. A vendor confident in the work will hand over the contact without hesitation; refusing on NDA grounds can be legitimate, but two refusals in a row is a signal in itself. Ask the former client specifics rather than whether they were happy: did the team hit the dates, how many times did the estimate change, how did they respond to bugs after launch, would they work with them again. Five minutes on the phone closes more risk than an hour of presentation.

Sector fit deserves separate attention. Cases in your industry are valuable not because of domain expertise as such but because the team has already stepped on your rakes: they know how accounting integration works in your kind of business, what happens to a ten thousand item catalogue, which fields your enquiry form must contain. No cases in the niche is not disqualifying, but then someone pays for teaching the vendor your subject area, and that someone is usually you.

Red flags

The most underrated red flag is a price quoted immediately. If on the first call, without a single question about integrations, catalogue size, who writes the copy or what happens to existing data, you are given an exact figure, that figure did not come from a calculation. What follows takes one of two shapes: either the scope gets trimmed down to the number during delivery, or the number grows through extra invoices. Both end in conflict, because the expectation was created before the analysis.

The second flag is an opaque estimate. A single line reading "website development, 450,000 RUB" cannot be compared to other offers, cannot be tracked during delivery and cannot be accepted in parts. Asking for a breakdown by stage and hours is entirely normal, and refusing it means one thing in substance: no precise estimate exists and the number is an approximation. The same applies to an estimate with no QA, no content work and no launch line, because that work does not disappear, it simply gets paid for later.

The third group concerns promises and obligations. "We will do it in a week" on a project where design approval alone takes two means either a template or a promise nobody intends to keep. Working with no contract and no specification means there is nothing to argue about when the result disappoints. Refusing to show the team, vague answers about source code handover, registering the domain and hosting to the vendor, demanding 100% upfront: each of these is individually explainable, but two or more together describe a fairly specific business model.

• An exact price quoted before any questions about scope, integrations or content volume.
• A one-line estimate with no stages, no hours and no exclusions list.
• Promised timelines that physically do not fit the volume of work.
• No contract, no specification, or "we will sign later, let us just start".
• Refusal to name the actual people and their current workload.
• Vague answers about code ownership and source handover.
• Domain, hosting and licences registered to the vendor rather than to you.
• 100% prepayment before any work starts on a project longer than two weeks.
• Not one portfolio link that opens and works right now.
• Asked what went wrong on past projects, they answer that everything always goes to plan.

Comparing quotes that are not comparable

Getting 180,000, 450,000 and 1,100,000 RUB back on one brief is normal, and it does not mean one of the three is wrong. It means each read the brief differently and priced their own version of the project. Comparing such offers by the final number is meaningless: first they have to be normalised. Normalisation takes a couple of hours and almost always changes the ranking, because the cheapest offer, once brought to a common scope, frequently turns out to be mid-priced.

In practice: list in a table every work item that appears in at least one proposal and mark who includes it and who does not. Then price each missing item separately with each vendor. That step usually reveals that the cheap proposal excludes tablet layouts, QA, content population, analytics setup and migration of data from the old site, and once all of that is added the gap to the expensive one shrinks to tens of percent rather than multiples.

The second layer of normalisation is hours and seniority. Ask each vendor how many hours are budgeted and at what rate. If the 180,000 proposal contains 120 hours and the 450,000 one contains 300, you are not comparing price, you are comparing how much attention the project receives. The third layer is what gets billed on top: revisions past the included rounds, changes after acceptance, first-month support, licence renewals. Those lines create the gap between the estimate and the total you eventually pay.

What the contract must contain

A contract exists not for the courtroom but so that disputes have a resolution procedure agreed in advance. In nine cases out of ten it is never opened, yet the presence of certain clauses changes how both sides behave. The minimum working set is the contract itself plus an annex with the specification and an annex with a staged estimate. Without the second and third annexes the first document is a statement of intent.

The clause most often written badly is intellectual property. Wording such as "the results are transferred to the client" is legally weaker than an explicit assignment of exclusive rights to the source code, the design files and other intellectual outputs in full, effective on signature of the acceptance act. Rights to modify and to transfer to third parties belong here too: without them you formally cannot hand the code to another vendor for further work. Record separately that fonts, photography and third-party libraries carry licences that permit your use.

The second most important block is stages and acceptance. It must state which stages the work consists of, what constitutes the deliverable of each, within how many days the client must accept it or give a reasoned rejection, and what happens if the client says nothing. A deemed-acceptance clause after N working days protects the vendor, a reasoned-rejection clause protects you. Both are needed, because a one-sided contract always produces conflict, just at different points.

Then the mandatory remainder: a three to six month warranty with a definition of what counts as a defect (non-conformance to the specification) versus a new task; the revision procedure and its limit; transfer of credentials, repository and accounts within a stated period after the final act; a termination procedure settling payment for work actually completed; and an NDA if you are handing over customer data or commercial terms. Finally, check whose name the domain, hosting and licences are in, because that is the single most common point where a client ends up hostage.

• Stages, the deliverable of each and an acceptance window with reasoned rejection.
• Full assignment of code and design IP, including the right to modify.
• Credentials, repository, domain and hosting held in the client name.
• A three to six month warranty and a written definition of a defect.
• Revision policy: what is included, what the next round costs, how it is recorded.
• A termination clause settling payment for work actually delivered.
• An NDA where customer data, pricing or internal processes are shared.

Warning signs mid-project and how to leave in time

Failed projects almost never fail suddenly. Two months before the collapse the same signs appear: demos get postponed, screenshots replace working software, answers grow longer and less specific, and a direct question about status returns a narrative about how much has been done. Another reliable symptom is a specific developer disappearing from the correspondence while the account manager tone stays cheerful.

The check takes one request: ask for access to the repository and to a staging environment. A live project has a commit history with an even rhythm and a working build you can open in a browser. A dead one produces excuses: staging goes up before the demo, the code is closed by security policy, we will show it next week. If you have twice failed to get access to a running version, you do not know the project status regardless of what the reports say.

Leaving earlier is cheaper than leaving later, and that is the main thing to hold on to. The order of operations: record in writing exactly what is missing against the specification and the schedule; send a formal notice with a concrete remedy deadline; in parallel collect everything already paid for, meaning code, design files, credentials and copy; and only then terminate. Collect the materials before announcing termination, because afterwards handover speed tends to zero regardless of what the contract says.

A realistic loss estimate: leaving mid-project usually costs 30% to 50% of what you have invested, because part of the work has to be redone and a new team spends time reading somebody else code. Carrying a doomed project to the end costs 100% plus the time lost. The arithmetic favours early exit almost every time, and the only reason people keep going is reluctance to admit the earlier decision was wrong.

Frequently asked questions

Related services

• IT consulting and product auditThe most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.
• Website audit: technical, SEO and UXBefore changing the design, raising the ad budget, or telling support the site "just feels slower," find out what is actually happening. An audit is one report that pulls technical health, SEO and usability into a single list: what is on fire, what matters, and what can wait.
• Website development, end to endWe build sites that still hold up a year later: from a one-page CMS build to a store or a web application on React and Next.js. One team for design, code, integrations and launch.

Read next

• The Technical Specification: Structure, a Worked Template and the Usual MistakesA specification is not bureaucracy, it is leverage: anything that does not match it gets fixed by the vendor at no charge. Here is the section structure, a filled-in example for a corporate site and how to write acceptance criteria somebody can actually test.
• What a Website Actually Costs in 2026: The Estimate, Line by LineA practical breakdown of a web development estimate: what analytics, design, front end, back end and integrations actually cost, which expenses always show up after launch, and where cutting the budget is safe.
• How to Choose a Tech Stack: Criteria That Outlive the HypeA stack is a five-year commitment usually made in a single call. Here is the order the decisions should be taken in, the criteria that carry real weight, working stacks for six project archetypes and what a wrong choice costs.