How to Choose a Software Development Company: A Checklist From an IT Services Team Working Since 2019
An honest buyer's checklist from people who sit on the other side of the table: fixed price vs time and materials vs a dedicated team, the contract clauses that matter, the red flags, and how to test a vendor with a small paid pilot first.
Who wrote this: Snakescript Solutions LLP, the IT services company that runs Wope. Wope is our product brand; this article is about our services work.
- Choose the engagement model before the vendor: fixed price, time and materials, or a dedicated team on a monthly fee. Each moves the risk to a different side.
- Get the names of the engineers who will write your code, not just the people who pitched.
- Put code and IP ownership in the contract, and have the work happen in your repositories and accounts from day one.
- Ask how hours are recorded and proven. A timesheet is a claim; screenshots and task-level logs are evidence.
- Run a small paid pilot of two to four weeks before you sign anything large.
To choose a software development company, decide first how you want to pay (fixed price, time and materials, or a dedicated monthly team), then check in writing who will do the work, who owns the code, where it lives, how hours are proven and what happens if you leave. Test the shortlisted vendor with a small paid pilot before signing a large contract. The location of the company matters far less than these five checks.
We are Snakescript Solutions, an IT services company registered in India that has been delivering client work since 2019. We sit on the vendor side of this conversation every week. This is the checklist we would want a careful buyer to use on us, including the parts that make our job harder.
Pick the engagement model first
Most disappointments with an outsourced team start with the wrong contract shape, not the wrong people. There are three common models.
| Fixed price | Time and materials | Dedicated team / monthly subscription | |
|---|---|---|---|
| How you pay | One agreed price for an agreed scope | Hourly or daily rate for hours worked | A fixed monthly fee for named people or a set number of hours |
| Who carries the risk | Vendor on cost; you on scope | You, on cost | Shared; you can stop at the end of a month |
| Changing direction | Hard; every change is a change request | Easy | Easy |
| What to watch | Padded estimates and corner-cutting near the deadline | Hours that drift with no visible output | Paying for a seat that is not fully used |
| Best for | Small, well-specified work with a clear finish line | Discovery, fixes, work you cannot specify yet | Ongoing product work and iteration |
Fixed price feels safe because the number is known. In practice the vendor pads the estimate or reads the scope narrowly, and every new idea becomes a negotiation. It works when the scope is genuinely fixed.
Time and materials and monthly models are better for products, because products change as you learn. Their weakness is visibility. If you cannot see what the hours bought, you are trusting a number on an invoice. That is why the checklist below spends so much time on how hours are proven.
If you are deciding between hiring, a fractional engineer and an agency for AI work specifically, we compare those three routes on cost and speed in In-house vs fractional vs agency.
What to check before you sign
1. Who exactly works on your project
Ask for the names of the engineers who will write the code, their seniority and what they have built before. Ask to speak with at least one of them before you sign. The person who runs the sales call is often not the person who opens the pull requests. Write the named people into the contract, along with what happens if one of them is replaced: notice, a handover period, and your right to interview the replacement.
2. Code and IP ownership, in writing
Do not assume that paying for code means you own it. The contract should say that the code, designs and documentation are assigned to you, and when that happens. Some vendors transfer ownership on each payment, some on final payment. Either can be fair, but you should know which, and you should know what happens to work in progress if the relationship ends early. Ask a lawyer in your own jurisdiction to read this clause; it is the one that matters most.
3. Your repositories and accounts from day one
The simplest protection against every ownership problem is location. The code should live in your GitHub or GitLab organisation, the cloud resources in your AWS, GCP or Azure account, and the domains and app-store listings under your name. The vendor's engineers get access as members you can remove. If a vendor wants to build in its own repository and "hand over at the end", ask why.
4. How hours are recorded and proven
For any hourly or monthly engagement, ask what evidence sits behind the invoice. A manual timesheet is a claim. Better evidence links time to work: hours logged against named tasks, commits and pull requests you can see in your own repository, and, increasingly, a desktop time tracker that takes random screenshots while the clock runs. We explain how screenshot-based tracking works, and what it does and does not prove, in Time tracking with screenshots. You can also see how we run the work on Wope.
5. Communication and time-zone overlap
Agree the cadence before the work starts: a written update at a fixed time, a working demo on a fixed day each week, one technical point of contact, and a shared chat channel with the engineers themselves rather than only a project manager. Agree the hours of overlap too, in writing, and which time zone they are in.
6. Testing and code review
Ask how code gets from an engineer's laptop to production. Good answers mention peer review before merging, automated tests that run on every change, a staging environment you can see, and someone other than the author checking the work. Ask to see a real, anonymised pull request.
7. Security and access
Ask how credentials are stored and shared, whether engineers use personal or company devices, and whether production access is limited to the people who need it. Give each engineer an individual account, never a shared login, so access can be removed one person at a time.
8. Exit and handover terms
Every engagement ends. Read the exit clause as if you were leaving next month. How much notice is required? What documentation will you receive? Will the engineers spend time handing over to your next team, and is that time billed? If the code already lives in your accounts, the answer to "what happens if we leave" is short, which is the point.
Red flags
- Vague estimates. A single number with no breakdown of tasks, assumptions or unknowns. A good estimate shows its working and says which parts are uncertain.
- No named engineers. "Our team" is not an answer to "who will write the code".
- Code held hostage. Work in the vendor's repository, deployment from the vendor's cloud account, or source code released only after a final payment with no access in the meantime.
- No written scope. If the scope lives only in a call recording, every disagreement becomes your word against theirs.
- Hours with no trail. Invoices that cannot be matched to tasks, commits or any other evidence.
Run a small paid pilot first
The most reliable way to choose a software development company is to pay one to do a small piece of real work. A good pilot:
- Is real. A feature, an integration or a fix you actually need, not a test exercise.
- Is short. Two to four weeks, with a clear definition of done.
- Is paid. Unpaid trials attract vendors who will cut corners to win the contract. Paying makes it a normal piece of work you can judge fairly.
- Runs in your setup. Your repository, your cloud account, your chat. This tests the working relationship as well as the code.
- Is reviewed. At the end, have someone you trust read the code, look at the tests, and check the hours against the work delivered.
A pilot shows how the engineers ask questions, whether updates arrive when promised, and whether your next engineer could pick up the code.
Outsourcing software development to India
India is one of the most common destinations for offshore development teams, and everything above applies equally to an Indian vendor. A few points are specific.
Time zones. India Standard Time is UTC+5:30 and does not observe daylight saving. That makes India 4.5 hours ahead of the UK in summer and 5.5 hours in winter, and 3.5–4.5 hours ahead of central Europe, so UK and EU clients share most of their morning with an Indian team's afternoon. Against US Eastern time the gap is 9.5–10.5 hours, so US clients usually agree a fixed overlap window, either early in the US morning or late in the Indian evening, and rely on written handoffs for the rest. Ask a vendor exactly which hours they will be online for you.
Cost. Rates for developers in India are generally lower than in the US or UK, but they vary widely with seniority and the kind of company. Compare total cost for a defined outcome, including your own time managing the work, rather than the hourly rate alone.
The legal entity. Indian vendors are commonly private limited companies or limited liability partnerships (LLPs). An LLP under India's Limited Liability Partnership Act, 2008 is a body corporate and a legal entity separate from its partners, and it files with the Registrar through the Ministry of Corporate Affairs. Ask for the registered name and registration number and check them on the Ministry of Corporate Affairs website before signing.
Contracts and payments. Agree in writing which country's law governs the contract, the currency of the invoice, how international payments will be made and who bears transfer fees, and how taxes are handled on both sides. Your accountant will want to see this before the first invoice, not after.
How we work at Snakescript
As one example of the checklist in practice, here is how we work. Snakescript Solutions LLP is registered in India and has done IT services work since 2019. On snakescript.com we describe ourselves as an AI-first product studio building chat, voice and agent products, alongside web and mobile platforms and automation on n8n and Make.com. The site lists three ways to engage: a fixed-price AI Sprint of two to four weeks, a Fixed Build once scope is clear, and a monthly embedded AI Team. It also commits to weekly working demos, a shared channel with the engineers, one technical point of contact, peer review before merging to main, and client ownership of code, designs, infrastructure and documentation.
We also build our own products: Voice Ninja voice agents, the Pensovo reading app, Wiseroll, Written People, and WopeAI Tracker. WopeAI Tracker is our own desktop time tracker, with random screenshots and task-level hours. Our engineers use it every day, so clients can see the work behind the hours they are billed.
Wope (wope.ai) is our product brand for businesses that want a senior engineer without a fixed project: a fractional senior AI engineer on a monthly subscription, from $1,200 a month. See our products and Wope pricing. For anything else, you can reach us at official@snakescript.com.
The short list of questions to ask
- Who exactly will write the code, and can I speak to them before we sign?
- Where will the code, cloud resources and accounts live from day one?
- When does ownership of the code and IP pass to me, and what does the contract say?
- How are hours recorded, and what evidence will I see with each invoice?
- How is code reviewed and tested before it reaches production?
- Which hours will you be online in my time zone?
- What happens, step by step, if I end the contract next month?
- Can we start with a two-to-four-week paid pilot?
A vendor that answers all eight clearly, in writing, is worth a pilot. One that hesitates on the first three is not.
Frequently asked questions
How do I choose a software development company?
Pick the engagement model first, then check five things in writing: the named engineers on your project, code and IP ownership, work in your own repositories and accounts, how hours are recorded and proven, and what happens at handover. Then run a small paid pilot before committing to a large contract.
What questions should I ask a software development company?
Who exactly will write the code and how senior are they? Where will the code live from day one? How are hours tracked and can I see the evidence? How is code reviewed and tested? What do I get, and how fast, if I end the contract?
Is fixed price or time and materials better for software development?
Fixed price suits small, well-defined work where the scope will not change. Time and materials or a dedicated monthly team suits products where you expect to learn and change direction, provided you can see where the hours go.
Is it safe to outsource software development to India?
It can be, if you treat it like any other vendor decision: verify the company is registered, keep the code in your own accounts, sign a contract that assigns IP to you, and start with a small paid pilot. The risks come mostly from weak contracts and poor visibility, not from the location.
How much time-zone overlap is there between India and the US or UK?
India Standard Time is UTC+5:30 with no daylight saving. That puts it 4.5–5.5 hours ahead of the UK and 9.5–10.5 hours ahead of US Eastern time, so UK and EU clients get a shared working afternoon, while US clients usually agree a fixed overlap window early in their morning.