Your agency has already sold the work, committed to a date, and put its client relationship behind the outcome. Now you need outside Laravel or React capacity, but the wrong choice could leave you absorbing rework while explaining missed commitments to a client who was never meant to know another team was involved. Search for advice on how to vet a development partner, and you will find accounts of agencies losing months to weak delivery, poor communication, and code they could not safely maintain. Some point specifically at Indian vendors. Ablion is an Indian development company founded in 2004, and more than 20 years of this work points to a problem that is structural rather than geographical.
The first structural problem is a commercial model that rewards time spent rather than work accepted. If every occupied developer creates billable revenue, finishing efficiently can work against the supplier’s immediate financial interest. A weekly report may show a fully allocated team while important pull-request comments remain unresolved and the feature is still not deployable. During vetting, ask what event marks a task as complete and whether the supplier measures progress through hours recorded, work approved, or software released.
Internal utilisation targets can reinforce the same behaviour. A developer who spends two days removing unnecessary complexity may create more value than one who remains busy for a week, but a time-led reporting system can make the second person look more productive. Ask to see a redacted delivery report and examine what it treats as progress. If the report contains hours, activity, and percentage-complete estimates but no accepted outputs, blocked decisions, or release status, you have learned how problems will be presented after signing.
Oversized teams create another distortion. A small number of engineers may hold the architectural context and complete most of the difficult work, while additional people are assigned isolated tasks without enough knowledge to move delivery independently. The buyer pays for apparent capacity but remains dependent on the same two people whenever a requirement crosses component boundaries or a production issue needs diagnosis. Ask each proposed team member to describe their responsibility for the first release, then look for overlapping answers, unowned areas, and roles that exist without a clear deliverable.
Communication structure can hide these problems until recovery becomes expensive. A developer reports that an external dependency threatens the date, an account manager turns that into a general status update, and the agency hears about the delay after several alternatives have disappeared. Context is removed on the way into the team, while urgency and uncertainty are removed on the way out. Ask a technical question during vetting and watch whether you can discuss it with the person making the decision or must wait for an answer to travel through a commercial intermediary.
None of these failure modes requires bad intent. They recur because the supplier’s incentives, team structure and reporting route make them normal outcomes. That is useful during due diligence because structures can be inspected before any client-facing work is committed. The right questions force a supplier to show who will deliver, how work becomes accepted and how uncomfortable information reaches you.
Treat each answer as a claim to verify, not a conclusion to record. Ask for the document, repository view or live conversation named in the final column, and note whether the supplier provides it directly or substitutes a general assurance. A credible supplier may need to redact client information, but it should still be able to show how its delivery model works.
This group tests whether the supplier is a stable contracting party and whether project knowledge survives changes in personnel. For an agency reselling the work, continuity matters because its client will hold the agency responsible even when the underlying disruption occurs inside the supplier.
| Question | Good answer | Bad answer | How to test it |
|---|---|---|---|
| 1. How long have you traded, and which legal entity will sign the contract? | The supplier gives the exact legal name, registration number and contracting entity, and explains any difference between that entity and the trading name used in its proposal. | The proposal, invoice and contract use different company names, and the supplier cannot explain which entity will carry the contractual obligations. | Check the entity on the relevant official register, compare its incorporation date, status, officers and filing history, and remember that a registry entry does not prove the accuracy of every filed claim or the supplier’s delivery competence. |
| 2. Which people are responsible for engineering, technical decisions and commercial management? | The supplier identifies the delivery lead, technical decision-maker and commercial contact, and explains which decisions each person can make without referring the matter elsewhere. | The salesperson describes a large technical organisation but cannot identify who will approve architecture, reject inadequate work or accept a release. | Ask the proposed delivery lead to explain who decides whether a disputed requirement is ready for development and who decides whether the completed work is acceptable. |
| 3. Where does project knowledge remain when someone is unavailable? | The supplier records architectural decisions, environment instructions, deployment steps and unresolved risks in project materials that another engineer can use. | The supplier says its senior developer knows the application well and promises to prepare documentation when the engagement ends. | Request a redacted decision record, setup guide or deployment checklist, then ask who last updated it and what event triggers an update. |
This group tests whether the people presented during sales are the people who will write, review and take responsibility for the code. An agency needs named delivery ownership because an anonymous pool makes capability, availability and accountability difficult to verify before client work begins.
| Question | Good answer | Bad answer | How to test it |
|---|---|---|---|
| 4. Who specifically will write the code, and are they named to the project? | The supplier names the proposed engineers, defines their responsibilities for the first release and states whether their allocation is reserved for the engagement. | The supplier says its entire development pool will be available but cannot identify who will own the code or submit the first pull request. | Ask each proposed engineer to describe the part of the first release they will own, then compare the answers for overlaps, gaps and unclear responsibility. |
| 5. Can I meet the proposed engineers before signing? | The supplier arranges a conversation with the people expected to do the work and allows them to discuss the real project rather than giving a rehearsed presentation. | Senior technical staff attend the sales call, but access to the assigned engineers is withheld until the contract has been signed. | Give the proposed engineer one deliberately unclear requirement and observe whether they ask about users, permissions, edge cases and acceptance conditions before suggesting an implementation. |
| 6. What happens if an assigned engineer leaves or is reassigned? | The supplier describes a documented transfer covering current work, technical decisions, access, unresolved risks and a review by the replacement engineer. | The supplier says it has plenty of available developers but cannot explain how project context will move from one person to another. | Request a redacted handover checklist and ask who confirms that the replacement can set up the application, deploy it and explain the current technical risks. |
This group tests whether technical context can move directly between the agency and the assigned engineers, and whether delays become visible early enough to manage. The agency needs dependable overlap and escalation because it must make client-facing decisions before a hidden block becomes a missed commitment.
| Question | Good answer | Bad answer | How to test it |
|---|---|---|---|
| 7. Will our delivery lead speak directly with the developers? | The agency’s delivery lead can discuss requirements, defects and technical risks with the assigned developers while the commercial contact remains responsible for account matters. | Every question must pass through an account manager who collects an answer later and cannot explain the reasoning behind it. | Run one requirement discussion with the proposed developer and check whether the resulting written decision preserves the assumptions, trade-offs and unresolved questions raised in the meeting. |
| 8. What working-day overlap will the assigned team provide? | The supplier states a specific overlap window in the agency’s timezone, names the people available during it and explains how daylight-saving changes affect the schedule. | The supplier promises to work in the agency’s timezone but does not define the hours, the attendees or the cover available when the main engineer is absent. | Put the proposed overlap into both teams’ calendars and ask who will respond when a blocking decision arises near the beginning or end of that window. |
| 9. How does a blocked developer escalate, and who gives early warning of a delay? | The developer raises the block through a named route, records its delivery effect and reaches the agency while there is still time to change scope, sequence or dependency. | Risks are collected for a weekly status meeting, where the agency first hears that several working days have already been lost. | Present a dependency controlled by a third party and ask the supplier to trace what happens from the first blocked task to the decision that changes the committed date. |
This group tests whether claims about standards, review, testing and repository transparency are supported by work that can be inspected. The agency is reselling the resulting software under its own name, so weak review or inaccessible code becomes its quality problem when the client examines the release.
| Question | Good answer | Bad answer | How to test it |
|---|---|---|---|
| 10. What coding standards apply, and who enforces them? | The supplier names the standards used for the relevant technology and shows how automated checks and reviewer decisions prevent non-compliant code from being merged. | The supplier says its developers follow industry best practice but cannot show a written standard, an automated rule or a reviewer enforcing it. | Ask to see a redacted pull request where a standards issue stopped a merge, then inspect the reviewer’s comment and the change made in response. |
| 11. What do code review and testing look like on a real change? | The supplier shows a reviewed change where another engineer examined correctness, tests, security implications and the affected business rules before approval. | The supplier says every change is reviewed, but its example contains only automated formatting checks or an approval with no evidence that the implementation was examined. | Request a pull request that was rejected or returned for changes and look for comments about input handling, authorisation, data flow or business logic that automated tools could miss. |
| 12. Do I receive repository access from the start, and can I inspect real contribution history? | The supplier defines the agency’s repository role, grants access at the agreed start point and allows the agency to inspect authors, reviews, branches and contribution history. | The supplier provides screenshots during delivery and promises to transfer the repository only after the final invoice has been paid. | Ask for access to a safe demonstration repository during due diligence and inspect who performed each visible action, which repository it affected and when it occurred. |
This group tests whether ownership, confidentiality, subcontracting, change control and exit obligations are explicit before either party depends on the relationship. The agency needs these controls because it carries the client commitment and cannot safely discover during a dispute that an important obligation was only discussed verbally.
| Question | Good answer | Bad answer | How to test it |
|---|---|---|---|
| 13. How do the contract and NDA cover intellectual property and confidentiality? | The contract states when intellectual property transfers, while the NDA covers the agency, its client’s identity, project materials and every person permitted to access them. | The supplier relies on a general confidentiality clause and says intellectual property will belong to the agency without identifying the transfer point in writing. | Ask the supplier to mark the exact clauses governing ownership, client identity, permitted access and obligations that continue after the engagement ends. |
| 14. Will any part of the work be subcontracted to another company or individual? | The supplier identifies every outside organisation or individual that may access code, credentials or personal data and explains how prior approval and equivalent contractual duties are obtained. | The supplier says it never outsources core development, leaving unanswered whether testing, infrastructure, support or specialist work is passed to another party. | Ask who outside the contracting entity can access the repository or production data, then compare the answer with the contract and data-processing terms covering authorised sub-processors. |
| 15. How are scope changes recorded, and what do I receive if the engagement ends? | The supplier records each change with its effect on cost, sequence and release date, and can describe an exit inventory covering repositories, deployment instructions, environment configuration, credentials, documentation and unresolved issues. | Changes are agreed in conversation and absorbed without a written record, and handover is described as something to discuss when the time comes. | Take one sample change request through the supplier’s process and ask to see the resulting written record, then ask what the last agency to finish an engagement actually received on the final day. |
This group tests whether the supplier understands invisibility as an operational requirement rather than a promise not to attend client meetings. The agency’s position can be exposed through commit identities, domains, alerts, tickets or marketing, so every client-visible surface needs a defined owner and a practical check.
| Question | Good answer | Bad answer | How to test it |
|---|---|---|---|
| 16. Where could your identity become visible to my client? | The supplier names the specific surfaces – commit authors and email addresses, repository and organisation names, staging domain records, deployment accounts, monitoring alerts, support tickets, document metadata and calendar invitations – and says who checks each one before access is created. | The supplier says it will remain invisible because it will not attend client calls, and has no process for commit identities, domains, credentials, documentation or public portfolio use. | Trace one sample change from approval to deployment, then inspect the change record, commit identity, staging domain, automated messages, support account and handover materials for anything the end client could see. |
A price far below the other proposals is a warning when the supplier cannot explain the operating difference behind it. The missing amount may return as a larger team, repeated change requests, weak review or work that your own developers must rebuild. Ask the supplier to map the price to named roles, responsibilities, assumptions and deliverables. If the explanation still depends on a vague claim that location alone makes equivalent delivery dramatically cheaper, do not put client-facing work behind it.
Access only to a salesperson prevents you from testing the people and communication routes that will determine delivery. A polished commercial contact may understand the proposal without knowing how architectural disagreements, blocked tasks or rejected pull requests are handled. Ask to meet the proposed delivery lead and at least one engineer using the actual project as the subject. If that access is postponed until after signing, assume the sales team is the only team you are currently evaluating.
Agreement with every requirement often feels responsive, but it can show that nobody has examined what the work involves. Experienced engineers should find ambiguities, conflicting assumptions, and decisions that affect security, effort, or acceptance. Give the supplier one requirement that lacks an important detail and see whether the team asks a precise question before estimating it. If they promise the requested result without resolving the gap, expect them to guess during development as well.
An unnamed team lets the supplier sell senior capability without committing senior people to your project. You may meet an architect during due diligence and later receive work from an anonymous pool whose members lack continuity or authority. Ask who will submit the first pull request, who will review it, and who owns the release decision. If those names cannot be provided before signing, treat the proposed team as a presentation rather than an allocation.
Refusing repository access removes your ability to inspect progress independently. Status reports can describe activity, but the repository shows whether code is arriving in reviewable changes, whether another engineer is reviewing it, and whether requested corrections are being made. Ask for access from the agreed start of delivery and specify the role your technical lead requires. If the supplier offers screenshots or a final transfer instead, decide whether you are willing to discover the condition of the code only after your switching options have narrowed.
An unverifiable portfolio proves little because screenshots and project descriptions do not establish who performed the work. Confidentiality may prevent a supplier from naming many clients, especially in white-label relationships, but it should still be able to demonstrate its process or discuss a public example it is permitted to identify. Ask what part of the delivery the proposed team completed and request evidence that does not expose protected client information. If every example is anonymous and no claim can be tested, assess the supplier through a paid pilot rather than treating the portfolio as evidence.
Unsolicited outreach is a reason to begin verification, not an automatic reason to reject a supplier. Ablion also gains some new business through outbound contact, so claiming that credible development companies never approach agencies would be misleading. The real warning sign is a sender who cannot identify the contracting entity, introduce the proposed delivery people or provide evidence for the claims in the message. Apply the same checklist regardless of who started the conversation, and stop when the evidence does not survive it.
A pilot should be real enough to expose working habits but contained enough to discard without affecting a client commitment. Choose a small internal workflow, integration adapter, reporting screen, or migration utility with a clear purpose and a result another developer can inspect. Give it normal constraints, including an existing codebase, acceptance conditions, and a review route. Keep it away from production data, launch dependencies, and anything your client expects to see.
A bad pilot is a coding exercise with no delivery pressure, dependencies, or need to clarify a business rule. It may show whether somebody can produce a function, but not how the supplier works when the brief is incomplete or an assumption proves false. An oversized pilot is equally poor because stopping it becomes difficult. If failure would force you to renegotiate a client date, you have moved beyond due diligence.
Leave one important ambiguity in the brief deliberately, but do not set an artificial trap. For example, request a dashboard showing the monthly value of customer orders without specifying whether cancelled and refunded orders belong in the total. A careful team will recognise more than one defensible meaning and ask which status, date, and currency rules apply. A weak team will choose an interpretation silently, build the screen, and present the number as correct.
Watch how the question arrives, not only whether it is eventually asked. The engineer should identify the decision, explain its effect and record the answer where a reviewer can find it. A message such as “Please clarify the dashboard” transfers analysis back to you, while a useful question names the competing interpretations and recommends a default. That distinction predicts how much delivery management your agency will need to provide later.
Blocks are another part of the test. Introduce a believable dependency, such as missing sandbox credentials for an external service, and observe whether the team reports the blocked task, states what can continue and identifies what it needs. A useful report arrives while you still have options and separates elapsed time from productive progress. A poor one appears after the engineer has waited quietly or worked around the dependency without approval.
The pilot should also create a safe opportunity for the supplier to be wrong. Point out that a delivered result fails an agreed edge case, then look for a direct acknowledgement, a corrected plan and an explanation of any delivery effect. Defensiveness, hidden rework or an attempt to redefine the agreement will be harder to manage under client pressure. The recovery tells you more than a demonstration in which nothing is challenged.
Review the delivery trail as closely as the code. Check for understandable commits, independent review, resolved corrections and setup instructions that allow somebody outside the original author to run the work. Compare the written status with what the repository shows. A polished demonstration cannot compensate for missing tests, unresolved comments or documentation produced only after you request it.
A failed pilot does not require catastrophic code. It may produce a technically adequate result through silent assumptions, late warnings, shifting ownership or repeated prompting from your delivery lead. It may reveal that the named engineer never appears, repository access is delayed or a correction becomes an argument about scope. Those results show that the supplier would consume management capacity even if individual tasks eventually reached completion.
Finding this behaviour in a contained pilot costs a limited piece of work and an uncomfortable decision. Finding it six weeks into client delivery means the agency may have exposed the repository, built a schedule around the supplier and used much of its recovery margin. Replacing the team then requires knowledge transfer while the client continues to expect progress. The pilot buys evidence before those dependencies form. Ablion welcomes being assessed on that basis.
We have set out the questions we think an agency should ask us as firmly as it asks anyone else. Here is where we stand on the ones that can be answered in public.
On project-based work your contact is the project manager who runs the build, not the engineers. That is a real trade-off and worth weighing: a single owner keeps the thread in one place, but technical questions travel through someone. If you want your delivery lead in direct contact with named engineers, in your own channels, that is the dedicated team model, and we set it up that way from the start. Decide which you want before signing, because it changes how the engagement runs day to day.
We do not hand over code or repository access at the start. Access follows the agreed milestones and payments, and the points at which you receive it are written into the contract before work begins. Intellectual property and code transfer to you in full on the terms in that contract, after payment rather than before, and we will show you the clause before you sign rather than describing it in an email.
Our confidentiality terms cover your client’s identity, not only yours. We will not name you or your client in our own marketing without your permission.
We keep almost all work inside our own team. Where a piece of work needs a skill we do not hold, or capacity we cannot free in time, we occasionally bring in a trusted specialist. When that happens, the contract does not change: Ablion remains the single point of accountability for delivery, and everyone who touches your project signs the same confidentiality terms, including those protecting your client’s identity. If you want our position on a particular engagement, ask, and we will tell you.
We accept a paid pilot before a full engagement, and we think it is a sensible way for an agency to start.
We answer questions about company registration details, staff figures, turnover, rates, contract mechanics and termination terms in a direct conversation supported by documents, rather than publishing them on a marketing page. We will identify the contracting entity, provide relevant corporate and contractual records for review, explain the proposed commercial structure, and answer reasonable due-diligence questions about continuity and exit arrangements. Where confidentiality or data protection limits what can be shared, we will state the limit and provide suitable redacted evidence instead of substituting a general assurance. This is the same principle an agency buys when it appoints a white-label partner: commercially sensitive information is disclosed to the people who need it, through the right channel, with evidence.
If you want to apply this checklist to us, work with us as your development team and bring the difficult questions to the first conversation. We will answer what can be answered directly and identify the evidence available for the points that require verification.
Ask who will write and review the code, whether you can meet them, how blocks are escalated, and when repository access begins. Check the written terms for intellectual property, confidentiality, subcontracting, change control and handover. For every answer, request evidence such as a contract clause, redacted pull request, handover checklist, or conversation with the proposed engineer.
Verify the contracting entity through the relevant official company register and compare its legal name with the proposal and contract. Registration alone does not establish delivery competence, so meet the proposed team, inspect repository evidence, and test a portfolio claim where confidentiality permits. Companies House explicitly warns that putting information on its register does not mean the information has been verified or validated.
Yes, when the pilot is real, contained and disposable. Use a small internal workflow or integration with one deliberate ambiguity, then observe whether the team asks a precise question, reports blocks early, and responds constructively when an assumption is wrong. Keep the pilot away from production data, client-facing commitments, and anything that would make walking away difficult.
Trace every place where the supplier’s identity might appear, including commit authors, email domains, staging URLs, deployment accounts, monitoring alerts, documentation, and support tickets. Put the visibility rules in writing and test them before client-facing work begins. The confidentiality terms should also cover your client’s identity and prevent the supplier from naming your agency in its marketing without permission.
Watch for salesperson-only access, unnamed engineers, agreement with every requirement, delayed repository access, and portfolio claims that cannot be tested. Treat vague answers about onward subcontracting as a serious warning, especially when the supplier distinguishes “core development” from other work without identifying who can access the project. Unsolicited contact alone is not disqualifying; failure to provide evidence afterwards is.
