How to Choose a Software Development Company

How to choose a software development company comes down to three checks, in this order. Delivery evidence on a system like yours comes first. Next come contract terms that put the repository in your account from day one and pass the rights per paid milestone. Then come the named engineers, and a paid pilot tests all three.

What matters most when choosing a software development company

A weighted vendor scorecard turns those checks into a comparable score. It adds communication and price, and weights all five criteria by what each costs to get wrong. Delivery evidence carries 30 percent and code ownership 25 percent, so the two criteria hardest to repair after signing make up more than half the score.

Delivery evidence (30%)

Delivery evidence leads because no contract clause can fix a team that has never solved the hard part of the build. "Similar" means similar on that hard part, not on the industry label. A team that reconciled live carrier feeds for a logistics platform has solved a problem closer to a hospital lab integration than a team that built a hospital's marketing site.

Ask for the system's name, its scale and a person who ran it. When that past client is under NDA, a walkthrough of the architecture with the engineer who built it is a fair substitute, since follow-up questions show who did the work.

Code ownership (25%)

Code ownership comes second because its problems surface only at the exit, after the money is spent. Missing IP rights or a vendor-held repository (where the code and its history live) stay hidden until the buyer must negotiate for software it already paid for. The draft contract therefore deserves as much evaluation time as the reference calls.

CorLab Tech's own published terms meet this standard: the client holds the source code, the database schema and the data from the first sprint, and handover is a contract clause.

The team that will do the work (20%)

People on sales calls are often not the people who will write the code. Ask the proposal to name each engineer with role and weekly hours, since a senior engineer booked for a few hours a week will write little of the code.

The statement of work, the document that fixes the scope of one phase, should then list those engineers as key personnel. Replacing one should need the client's approval and a handover overlap, because an engineer swapped out in month two takes the project's context along.

Once AI writes part of the code, the team's process matters as much as its names. When I built an AI agent prototype in three days, GPT and Supabase generated most of the interface plumbing, and I still debugged authentication and message broadcasting by hand. My build log for that agent closes on the working assumption: "AI-generated code is helpful, not perfect, so expect to debug."

Ask how the vendor reviews code written with AI assistants. A vendor that uses coding agents should be able to name its review step, including who reads generated code, which tests and security scans it must pass, and who approves the merge. That answer belongs in writing, next to the names in the proposal.

Communication and time-zone overlap (15%)

Time-zone overlap sets how fast a blocking question is answered: a team 7 hours ahead of New York shares about 2 hours of a 9-to-6 day. A question raised in New York after about 11 a.m. waits for the team's next morning. That rhythm suits a weekly demo and daily written updates, not a stream of live decisions. Ask too who answers when production breaks outside those hours.

That 7-hour gap is CorLab Tech's own, between its headquarters in Chișinău, Moldova, and New York; its office in Falls Church, Virginia, works on New York time. For about three weeks in March and one week around late October, when US clocks and European clocks change on different dates, the Chișinău gap is 6 hours and the overlap 3.

Price (10%)

An early quote measures how much of the scope the vendor understood, not what the project will finally need, which is why price carries the lowest weight. A low number with no listed assumptions can mean the hard parts, such as integrations and data migration, were left out of the estimate.

Scoring the shortlist

Rate each shortlisted vendor from 1 to 5 on every criterion, multiply each rating by its weight and add the results, so the best possible score is 5.0. A vendor rated 4, 3, 5, 4 and 2, in the table's order, scores 0.30×4 + 0.25×3 + 0.20×5 + 0.15×4 + 0.10×2 = 3.75.

The weights are a working model for a typical custom build, not an industry standard. Some answers end the evaluation whatever the total, such as a refusal to put the repository in the client's account or no clear answer on how production data is protected.

How to check experience you cannot see

A vendor's past work is best checked through the people who used it, since case studies show only what the vendor chose to publish. A reference call and a detailed review show how the team behaved when the schedule slipped, the scope changed or a production system failed.

Case studies and directory rankings, such as lists of top custom software development companies, still help build the long list. Read a set of software development case studies for the systems integrated, the data volume, and what went live and when, and drop vendors whose case studies name no system and no go-live date.

Clutch, a B2B review platform, marks a review as verified after it confirms the reviewer's identity and work history. It still publishes reviews it could not confirm, labeled as not verified, and those reviews do not count toward the provider's Clutch score.

A verified review confirms who wrote it, not that every statement in it is accurate. The reviewer's role shows how close they were to the work, and the project size and length show how much of the team they saw. Recent reviews from projects close to yours carry the most weight, because teams change.

On a reference call, the useful questions are about problems. Ask what went wrong and how the vendor broke the news, and whether the engineers who started the project finished it. Then ask how the final scope compared with the first estimate and why it moved.

For a complex system, ask which integration or data migration carried the most risk, and what the team did when real data broke the plan. Last, ask whether they would hire the same team for a system that matters more to their business.

A reference from a project that ran into trouble is the strongest test, since vendors pick references that flatter them. A vendor that cannot offer one should explain why before it reaches the shortlist.

Engineering habits are the last thing to check, and the hardest to fake. Ask to see one merged pull request, the record of a code change with its review and tests. It should come from the vendor's internal or open-source work, or from a client project whose owner agreed, since showing a past client's code without permission is itself an ownership breach.

Judge what it shows against the size of the change. Little discussion is fair on a one-line fix, but on a new integration or a schema migration, approval within minutes and without comments means review there is a formality.

Contract terms that protect you

The contract decides who controls the software if the relationship ends. Five clauses carry most of that control: IP assignment, repository ownership, code escrow, termination and handover, and the warranty period. The first two matter most, because without them a client can pay for software whose rights it cannot prove or whose code it cannot reach.

IP assignment

IP assignment, a signed transfer of copyright and the other IP rights in the code from the vendor to the client, is the legal half of ownership. Under US law, commissioned work counts as a work made for hire only if it fits one of nine categories and both sides sign an agreement saying so. The U.S. Copyright Office lists those categories, and a custom application rarely fits any of them.

In the US, copyright belongs first to the author, which for an employee's code is the employer, so an outside vendor owns what its team writes until it signs the rights over. A transfer is valid only in a writing the owner signs, so contracts pair any work-for-hire wording with an express assignment. Without one, the client may hold only an implied license, with a scope a court decides.

With a vendor outside the US, the law where the code is written can decide who owns it first. The contract should name a governing law and use a present assignment ("hereby assigns") rather than a promise to assign later. The vendor should also confirm in writing that it holds signed assignments from every employee and individual contractor whose work it passes on.

Moral rights need their own line. They let the original author object to changes or demand credit, and some countries do not allow them to be sold with the copyright. The contract therefore includes a waiver where local law allows.

Rights should transfer as each milestone is paid. Pre-existing vendor libraries are licensed rather than assigned, under a perpetual, irrevocable, worldwide and royalty-free license to use, modify and sublicense to the client's contractors, with source code delivered.

AI-generated and open-source code

Code generated by AI may carry no copyright at all. The U.S. Copyright Office's 2025 report concludes that output without enough human authorship is not protected, so for that code the client's protection comes from the contract, confidentiality and control of the repository.

The vendor should also list every AI tool that touches the client's code and confirm each tool's terms rule out training on client code and limit how long inputs are retained. Patient or personal data stays out of any tool not covered by the right data agreement: a business associate agreement (BAA) for US patient data or a data processing agreement (DPA) for EU personal data.

Open-source code needs a list of every component and its license. Most, such as MIT or Apache, ask for little beyond credit and a license copy. A few GPL-family licenses can oblige the client to share the source of software built on them. That happens when such code ships in a mobile app or installed product, or under the AGPL when a modified component runs behind a web service.

Repository, deployment and escrow

Repository ownership is the practical half. The repository sits in the client's own GitHub, GitLab or Azure DevOps account, where the client keeps the owner role and the vendor's engineers get write access without admin rights. The main branch is protected against force-pushes, which keeps the full history intact.

A stricter test than ownership is whether another team could deploy the system without calling the vendor. That needs the deployment pipeline, database migrations and infrastructure configuration in the repository, and cloud, domain, app-store and API accounts opened in the client's name, with secrets in the client's secret manager.

Escrow matters when the client depends on code or services it cannot hold itself, such as a licensed vendor platform. An escrow agent releases the deposited code on agreed triggers, usually insolvency, and a test build at each major release shows the deposit still compiles.

Exit and warranty

Handover terms name what the vendor delivers at exit, including code, credentials, infrastructure access, documentation and a fixed number of handover hours. Exit runs on a stated notice period, longer for the vendor than for the client, and the handover duties survive termination.

The warranty period needs a definition as much as a length. It should name what counts as a defect, meaning behavior that fails an acceptance criterion both sides signed, and separate it from a change request. The clock should start at acceptance rather than at delivery, and bug fixes billed as new work from launch day are a red flag.

All five clauses belong in the master services agreement, the umbrella contract that every statement of work sits under, and counsel should review it before signing. The pilot then runs as the first statement of work under it, or under a short standalone agreement with the same terms. The full contract, in this guide, means the statement of work for the main build.

Run a paid pilot before the full contract

A paid pilot is a short engagement, usually two to four weeks, in which the team builds one slice of the system before the full contract. It tests the team on real work, and failure costs only a fee and some weeks. In deciding how to choose a software development company, it is the one step that tests delivery instead of claims.

Its trade-off is the delay, usually one or two sprints, and work that may be thrown away if the vendor fails. Because the repository sits in the client's account from day one and the IP passes when the pilot fee is paid, even discarded work stays the client's, and ownership is tested before the larger commitment.

The first week should produce written requirements for the slice, with acceptance criteria the client has read and signed. Those criteria are what the pilot is judged against at the end, so they cannot be written after the code. For a data-integration slice they might look like this, with the thresholds set per project.

I built a live lesson platform for my university department spec-first, with the requirements written before any code. In the build log for that platform I wrote: "Requirements written first are where design errors surface, while they are still sentences."

From the second week, each demo should run on realistic data rather than on a script prepared for the meeting. The slice is smaller than a first version of the product, but it should exercise the hardest integration, because that is where estimates go wrong.

Judge the pilot on behavior as much as output. Check whether the team raised questions early, whether the people named in the proposal appear in the commits, and whether the vendor can explain any change in the estimate. Many firms selling custom software development services offer paid discovery, which tests analysis; the pilot also tests delivery.

The pilot's revised estimate gives the buyer a first realistic view of custom software development cost before the larger commitment. A scope the pilot has mapped well can then run as fixed price, while a scope that is still moving suits time and materials.

My own three-day AI agent prototype ran end to end with a live interface, and it still proved only part of what production needs. I was plain about that in the same build log: "Three days answered the technical question of whether the parts fit together."

A pilot of a few weeks answers the same kind of question. Security, performance under load and readiness for production still need their own milestones in the full contract, with acceptance tests agreed before that part of the build starts. The pilot itself should end with a written decision to proceed, change the scope or stop, made against the acceptance criteria signed in its first week.

How to choose a custom software development company for a regulated product

For a regulated product, the same scorecard applies with two extra checks. In healthcare software that handles patient data, the first is which data agreements the vendor's access to that data requires, under HIPAA in the US and GDPR in the EU. The second is real clinical integration work.

Patient data under HIPAA and GDPR

Under HIPAA, a covered entity is a healthcare provider, health plan or healthcare clearinghouse, and a vendor that creates, receives, maintains or transmits protected health information (PHI) for one is a business associate. A vendor handling PHI for a health-tech company that is itself a business associate becomes one too, and routine support or admin access to systems holding PHI can be enough. The HHS page on these contracts lists what the agreement must cover, from Security Rule safeguards to breach reporting.

A BAA is needed when the client is a covered entity or business associate and the vendor handles its PHI. A consumer health app outside HIPAA needs none, though the FTC Health Breach Notification Rule and state health-privacy laws may apply. Work done only on synthetic or client-de-identified data may not need one.

HIPAA is US law. In the EU, GDPR Article 28 requires a DPA with any vendor processing personal data for the client, and data de-identified under HIPAA is often still personal data under GDPR.

Transfers to a vendor in a country without an EU adequacy decision, Moldova included, also need standard contractual clauses or another Article 46 safeguard, separate from the DPA. New sub-processors need the client's prior written authorization, specific or general.

Clinical integration evidence

Integration evidence carries as much weight as compliance paperwork. HL7 v2, the message format many hospital systems use for admissions and lab results, differs between feeds through optional fields, local code tables, version differences and Z-segments a site defines for itself. FHIR, the newer standard most often used through web APIs, varies by EHR vendor, FHIR version and implementation guide, so a claim of FHIR support says little on its own.

Ask for a system that exchanged real messages with a live clinical feed, not only with a sandbox. In a pilot, the slice exercises that integration against sample messages the client has de-identified, or against the EHR vendor's sandbox, while live-feed onboarding with the hospital's IT team starts in parallel.

One question sits upstream of all these checks: whether the product needs a custom build at all. The trade-offs of bespoke software in general, and of custom vs off-the-shelf healthcare software for clinical products, settle that question; a comparison of top healthcare software companies then helps build the shortlist.

Red flags

The most serious red flag is a vendor that keeps the code repository closed until final payment. Other warnings carry less weight but add up. They include a team nobody can name, undisclosed subcontractors, references that never answer, a fixed quote given before any discovery and a contract with no handover terms.

A closed repository turns the last invoice into a hold over the whole system. Until the client pays in full, it cannot audit the code, cannot ask another team to review it and cannot continue the work if the relationship breaks down.

Vendors usually defend the practice as protection against non-payment. That risk is real, but milestone payments with IP passing per paid milestone cover it without holding the client's code. A vendor that rejects this arrangement should say why, and a reference from a past client can confirm how its last dispute ended.

A team nobody can name is a warning because the schedule in the proposal was built on people the buyer has not met. A quote produced within days for a system with several integrations suggests the integrations were guessed. References that never answer, or reviews that all arrive in the same month, deserve a direct question before the vendor reaches the shortlist.

Undisclosed subcontracting touches both the IP clause and data protection. The vendor can assign only rights it holds in writing, so work from an unnamed third party may leave a gap in the assignment. Under HIPAA, the vendor must sign its own business associate agreement with each subcontractor that handles PHI, and under GDPR no sub-processor joins without the client's prior written authorization.

Without handover terms, the cost of leaving is negotiated at the worst moment, when the relationship is already failing and the vendor holds the credentials. Ask any software development partner on the shortlist to put the exit terms in the first draft of the contract.

Sources and method

Mihai Dascal, the author, is a co-founder of CorLab Tech, a software development company, so every check in this guide applies to CorLab as much as to the vendors it competes with. The CorLab Tech terms quoted above come from its own published About page.

Each legal, regulatory and platform statement links to its primary source: the U.S. Copyright Office, HHS, the FTC, the GDPR text, the European Commission, NIST and Clutch's own help pages, all checked on October 15, 2026. The scorecard weights, red flags and pilot criteria are the author's working model, not research findings, and the contract guidance describes common practice, not legal advice for a specific agreement.