How to Choose a Software Development Company: Ask for the Test Count

To choose a software development company, ask for evidence a sales deck cannot fake: how many automated tests a comparable project has and what fails its build, a bug their process caught, who writes and reviews the code, and who owns the repository. Firms that engineer well answer with numbers and links. Firms that sell well answer with adjectives.

This is the general guide, for buyers anywhere choosing a firm anywhere. If you are looking at firms in Bangladesh specifically, the Bangladesh vetting checklist adds weighted scoring, time-zone overlap and local verification. Both guides rank nobody and can be applied to RAITHub as strictly as to any other firm.

Why ask a software company for its test count?

Because it is a single question that is easy to ask, hard to fake and revealing either way. A firm that tests seriously knows the number; a firm that does not has to change the subject.

Portfolios show what a product looks like. They do not show whether the next release will break the last one, which is what decides your cost after launch. Automated tests are the part of engineering quality that leaves a countable trace in the repository. A number such as "1,024 tests on a comparable project" can be followed up: how were they counted, what do they cover, and does a failing one block a release?

The count is not the goal, and a high number can hide weak tests. That is why it is the first question, not the only one. Its real value is the conversation that follows. A team that can tell you which layer of tests caught a specific bug, and show you the regression test they added afterwards, has a working quality system. A team that answers "we do thorough QA" has a sentence.

Which evidence questions separate real engineering from a sales deck?

Questions whose answers are numbers, names, links or a screen share. Ask each firm the same ones and write down the answers; a vague answer to a specific question is an answer.

Ask	A good answer	A weak answer
How many automated tests does a comparable project have?	A number from a real codebase, and how it was counted	"We test everything thoroughly"
What fails your build?	Specific gates: type errors, failing unit, integration or end-to-end tests, a project-specific safety check	"Our QA team signs off"
Can I see a red build?	Yes, on a screen share, with the reason it failed	"Our builds don't fail"
Show me a bug your process caught before users did	A dated example, the root cause and the regression test added	No example, or only bugs a client reported
Who writes and who reviews the code on my project?	Named people you can meet, with review required before merge	"Our team" with no names until after signing
Do your checks run the same commands as the deploy target?	Yes, with an example of a problem that only showed on the host	"It works on our machines"
How often do your releases need a fix straight afterwards?	A rough rate, and how they recover when it happens	"Never"
Whose accounts will the repository, hosting and domain be in?	Yours, from day one, with the firm added as a collaborator	The firm's, transferred at the end
When does the IP become mine?	As the work is created, through present assignment	"On final payment"
What will I see every week?	Working software in a demo, and a written changelog	A status report
What would make you tell me not to hire you?	A specific list of projects they are the wrong fit for	"We can do anything"

The question about releases that need a fix afterwards comes from DORA's research programme, which measures software delivery with metrics including change lead time, deployment frequency, change fail rate and failed deployment recovery time (DORA's software delivery performance metrics). Few small firms track these formally. A firm that can at least describe them for a real project is thinking about delivery the right way.

What do published test counts look like?

Specific, tied to a named platform, and dated. These are RAITHub's, as an example of the format to ask any firm for, not as a benchmark.

Platform	What it is	Automated tests	A safeguard you can ask about
TheSkinProof	Multi-vendor marketplace; the founder's own venture, built and run by RAITHub	750+	Coverage thresholds enforced in CI
Sundor Skin	B2B wholesale platform built for a client, 146 tables	530+, plus 20 SQL assertion suites	Build fails if a buyer-scoped table lacks a row-level-security policy
PropDesk	Property-management SaaS with 4 user roles	1,024	Details in the case study
RAITHub website	This site, its admin and content management	400+ (September 2026)	A regression test for every update schema

Notice two things. TheSkinProof is labelled as the founder's own venture, because evidence from your own product is not the same as a client reference, and a buyer should know which is which. And each row has a safeguard you can ask about, because the count alone proves little. The method behind the numbers is in how RAITHub tests software.

How do you verify what a software company tells you?

With sources the firm does not control and work you can inspect. Four checks cover most of the risk.

1. A screen-shared tour of a real repository, under NDA if needed. Look for tests next to the code, a CI configuration, and commit messages that explain why a change was made.
2. A live product you can use, with its URL. Case studies without live URLs, numbers or a problem that went wrong are marketing.
3. Reference calls you make yourself. Ask what was late, what broke after launch, and whether they would hire the firm again.
4. A small paid trial task of one to two weeks. Judge the pull request, the tests, the questions asked and how progress was reported, not only the result.

Two things sound strong and prove less than they seem. Headcount says nothing about who will work on your project. Certifications such as ISO 27001 show a managed security process, which matters for procurement, but not that the code is well tested.

Which engagement model should you choose?

Match the model to how certain your scope is. A defined first release suits fixed scope at a fixed price; an evolving product after launch suits a dedicated team paid monthly.

Your situation	Model that usually fits	What to insist on
A first release with a feature list you can write down	Fixed scope, fixed price	A written spec, a change-request process, tests in the scope
A live product whose roadmap changes month to month	Dedicated team, monthly	Named people, continuity, a weekly demo, a short notice period
One existing problem: a bug, a failing deploy, a slow page	A single fixed-quote fix	Reproduction, root cause and a regression test
A struggling codebase nobody fully understands	A diagnostic first, then a fixed-scope plan	A written audit before any rebuild is proposed

If what you want is individual engineers placed in your own team and managed by you, that is a different kind of provider, and you should look for one that specialises in it. RAITHub offers fixed scope and dedicated teams only. The trade-offs between the two main models are covered in dedicated team vs fixed price.

What are the red flags when choosing a software development company?

Any one is a reason to walk away, or to get it fixed in writing before you sign.

• No test count, or tests offered as an optional extra that can be cut to lower the price.
• A fixed price quoted before anyone has asked detailed questions about your scope.
• Repositories, hosting or domains registered in the firm's name.
• IP that transfers "on final payment" rather than as work is created.
• The senior person from the sales call is not on the project.
• Case studies with no live URLs, no numbers and no problem that went wrong.
• Savings claims such as "cut costs by 70%" with no source.
• Pressure to sign quickly, or a discount that expires in days.

The cost side of these warnings, including how missing tests turn a low rate into a higher total, is in the hidden cost of cheap offshore development.

Does it matter where the company is based?

Less than how it works. Location changes cost, time-zone overlap and legal jurisdiction; it does not decide quality. The evidence questions above work in any country.

What location does change is how you communicate. With a large time difference, written handoffs and a weekly demo matter more than meetings, so ask for a fixed daily overlap window in writing. The trade-offs are in nearshore vs offshore software development.

How does RAITHub answer these questions?

With the same kinds of evidence this guide asks for, so you can test the method on us first.

• Test counts: TheSkinProof 750+, Sundor Skin 530+, PropDesk 1,024, this website 400+, as in the table above.
• A bug the process caught: a zod 4 behaviour change that turned admin reorders into data wipes, found in pre-launch review on 27 September 2026 with every check green, fixed with a regression test per schema (write-up).
• Who writes and reviews: RAITHub is a founder-led studio founded in 2024 in Dhaka, working with clients worldwide. Rupak Amin, Founder and Lead Engineer, reviews the architecture on every engagement.
• Ownership: full IP through a present-assignment clause, and an NDA before detailed discussion.
• Price: no published rates. A free 15-minute technical audit, then a fixed written quote with its assumptions; see pricing.
• Certification: RAITHub is not SOC 2 or ISO certified; its practices are on the security page.

When RAITHub is the wrong choice

• Your procurement requires a SOC 2 or ISO certified vendor.
• You want engineers placed inside your team under your own management.
• You need a large team assembled within weeks.
• You need delivery in a language other than English.
• You are building a regulated fintech or health product without a compliance partner.

If none of those apply, test RAITHub against the table above: book the free 15-minute technical audit for a new build, or for an existing codebase, and ask for the test count.

Last reviewed: 29 September 2026.

Frequently asked questions

How do I choose a software development company?

Ask every shortlisted firm the same evidence questions: the test count on a comparable project, what fails their build, a bug their process caught, who writes and reviews the code, and who owns the accounts and IP. Verify with a repository tour, reference calls and a small paid trial.

What questions should I ask a software development company before hiring?

How many automated tests a comparable project has, what blocks a release, whether you can see a failed build, who will write and review your code, whose name the accounts will be in, when IP transfers, and what you will see each week.

Why does the number of automated tests matter?

It is a countable trace of whether quality work actually happens. The number alone proves little, but a firm that knows it can usually explain what the tests cover and what they have caught, which is the real evidence.

Should I run a paid trial before hiring a software company?

For a large engagement, yes. One to two weeks of real, paid work shows the code, the tests, the questions asked and the progress reporting, for a small fraction of the cost of a failed project.

Fixed price or dedicated team: which is better?

Neither in general. Fixed scope at a fixed price suits a first release you can specify; a dedicated monthly team suits a product whose roadmap keeps changing. Choose by how certain your scope is.

Does RAITHub offer staff augmentation?

No. RAITHub offers fixed-scope builds and dedicated teams. If you want individual engineers placed in your own team under your management, a provider that specialises in that will suit you better.

How is this guide different from the Bangladesh version?

This guide applies to firms anywhere and centres on evidence questions. The Bangladesh checklist adds weighted scoring, time-zone overlap from Dhaka and ways to verify firms in that market.

"Every company I talk to says they're great and shows me a nice portfolio. How do I actually tell who can deliver?"

Treat claims as unproven until the evidence backs them. Ask for countable traces: the test count on a comparable project, what fails their build, a bug their process caught, and who writes and reviews the code. Then verify with a repository tour, two reference calls and a small paid trial of one to two weeks. A firm that cannot show these, or will not run a trial, is telling you something.

Which software development company should I hire to build a production app I can maintain and own outright?

Choose a firm that puts the repository in your organisation from the first commit, assigns the IP to you through present assignment, and writes tests gated in CI. RAITHub works this way as a dedicated team or fixed-scope build, not staff augmentation, so you own the code throughout. Test any shortlist against the evidence questions and a paid trial before committing.

Is hiring a development agency a good alternative to building an in-house engineering team?

For a first product or a defined scope, often yes: an agency gives you design, engineering and testing without the hiring time and fixed payroll. An in-house team suits a product that is the long-term core of the business. Many founders use an agency to ship the first version, then hire in-house once demand and the roadmap are clear.

How long does choosing a software development company usually take?

Expect two to four weeks from shortlist to signature. Briefing and quotes take a week or so, reference calls and a repository walkthrough a few days, and the paid trial that reveals the most runs one to two weeks. Building the vetting time into your plan is cheaper than discovering a weak fit three months into a build.

Can I use AI code tools to vet a firm's work instead of running a paid trial?

AI can flag obvious issues in a code sample, but it cannot judge whether a team asks the right questions, handles scope changes well or owns a bug under pressure. A one-to-two-week paid trial on your real product shows all of that. Use AI to help review the trial output; do not let it stand in for the trial.