How to Choose a Software Development Agency: A Buyer's Checklist

Before you shortlist anyone

Most bad vendor decisions were made before the first call, by starting the search with a description too vague to compare answers against. Three things are worth writing down first.

• What has to be true at launch. Not a feature list, the outcome. If you cannot say what would make the first release a success, every proposal will look reasonable.
• What you already run. Your CRM, your billing, your data, your identity provider. This is the single most common source of late surprises, and vendors cannot estimate what you have not told them about.
• Who decides. One person with the authority to settle scope questions in a day. Vendors cannot fix an internal decision bottleneck, and the good ones will ask about it on the first call.

With those three written down, a proposal becomes checkable. Without them, you are comparing writing styles.

Where to look, and what a directory profile actually proves

Directories, referrals and portfolios are how the shortlist gets built, and each proves less than it looks.

A directory profile proves that someone filled in a form. Reviews are the useful part, but only when you read them properly: how many there are, whether they are marked verified, and whether the projects described resemble yours.

Clutch, for example, verifies reviews using reviewer-provided information and online research, checking proof of identity and work history, and publishes reviews it cannot verify as Not Verified (Clutch, How Does Clutch Verify Reviews?). So the label carries information. The count carries more.

Here is ours, since it would be dishonest to give you a test we would not sit: Kultrix was founded in 2023 and has two reviews on Clutch, both five stars (our Clutch profile). Two is a small sample. It tells you those two projects went well; it does not tell you what happens across fifty. A vendor with forty reviews has genuinely told you something we have not, and if review volume is what you need in order to sign, that is a legitimate reason to pick someone else.

What we would trust more than any profile: a reference call with a client whose project failed or nearly did, and who still recommends them. Every agency can produce a happy reference. Ask for the one that went sideways.

The agencies people usually shortlist, and what each one is for

Ask three people who have run this search and roughly the same names come back. The useful question about them is not who is best, because they are not versions of one company competing on a single axis. They are set up for different jobs, and a shortlist gets much shorter once you know which job you are buying.

Everything below is what each firm publishes about itself, linked to the page it publishes it on, so you can check the summary instead of trusting it. We have not worked with any of them, none of this is a review, and the order is not a ranking. Read it as a map, then use the questions further down on whichever names survive.

• thoughtbot - when you want to read how a team works before you hire it. thoughtbot describes itself as small teams of designers and developers collaborating closely with clients, working remotely with teams in your timezone, across product strategy, design and development, with Ruby on Rails and Hotwire prominent in the engineering list. The unusual part is that the method is public: the thoughtbot playbook is free and licensed Creative Commons Attribution-NonCommercial, so you can judge how they run a project before the first call rather than after the first invoice. Fits an early product where strategy, design and build should sit with one small senior team. Not the shape you want if you need a large staffed programme.
• Netguru - when the product is commerce and the buyer is a large brand. Netguru dates itself to 2008, gives Poznan in Poland as its headquarters, and positions itself around digital commerce: AI-driven platforms, marketplaces and omnichannel experiences alongside software engineering, product design, QA and product management. It names IKEA, Volkswagen, OLX and Vinted among its clients and holds B Corporation certification, which answers a procurement question as much as a values one. Fits a retail or marketplace programme that has to pass a corporate vendor review. Heavier than a first version usually needs.
• Intellias - when the software has a vehicle or a regulated industry attached. Intellias presents itself as an AI-enabled product engineering partner, and its centre of gravity is mobility: software-defined vehicle and digital mobility solutions, digital cockpits, AD and ADAS features, AUTOSAR-based architecture, sensor fusion and over-the-air updates for OEMs and Tier 1 suppliers, with further practices in retail, financial services and insurance, healthcare and iGaming. Its published locations run across Europe, the Middle East, Asia and the United States. Fits work where domain knowledge is most of the job and the vocabulary alone would sink a generalist. Wrong shape for a small consumer app.
• N-iX - when you are an enterprise buying a long programme. N-iX dates itself to 2002, gives Malta as its headquarters with delivery offices across Europe, the Americas and India, and describes enterprise software engineering as its business: cloud, data engineering and analytics, application modernisation, QA automation, embedded and IoT, and game development. It names Bosch, Siemens, eBay and Inditex among its clients. Fits multi-year programmes with a procurement department and a supplier audit attached. Not the cheapest way to find out whether an idea works.
• MobiDev - when the hard part is the model, not the screens. MobiDev says it has been building and modernising software products since 2009, and its published AI list is unusually specific for an agency: defect detection, forecasting, recommendation systems, biometric authentication and pose estimation, next to ordinary mobile and web engineering. Retail, hospitality, fitness, sports, healthcare, manufacturing and fintech are the domains it names. Fits a product whose value sits in a model that has to hold up on real data. Overkill when the product is forms, records and a payment.
• Cleveroad - when you do not yet know whether you are buying a project or a team. Cleveroad publishes several ways to buy rather than one: product discovery, MVP development, a dedicated team, staff augmentation, IT consulting and CTO as a service, across healthtech, logistics and supply chain, fintech, marketplaces, retail, travel and education. That range is genuinely useful when the engagement shape is the open question. The flip side is that you still have to decide which model you are in, because they price differently and they behave differently once the work starts.
• Uptech - when you want a product team rather than a build shop. Uptech makes a product mindset its main claim, in its own words focusing on delivering business value rather than only writing code, and says it works with everyone from bootstrapped startups and venture-backed scale-ups to large enterprises. It lists offices in the United States, Estonia, Ukraine, Poland and Cyprus, with mobile work in Flutter and React Native alongside AI, cloud and web engineering, and fintech, healthcare and marketplaces among its domains. Fits a founder who wants argument about the product, not only estimates against a backlog. If you already know exactly what to build and want it built to spec, you are paying for a service you have decided not to use.

And where Kultrix sits on that map. We are small, founded in 2023, and the job we are built for is a first version or a focused rebuild where the same people do the discovery, the design, the build and the release. That is the reason the estimate model behind our calculator is published on this site instead of described on a call: at our size, being checkable is the only credential we have that a larger firm cannot produce in an afternoon.

The boundary is the honest one from the section on team size. If your programme needs a supplier audit, a bench deep enough to drop a specialist in for three weeks, or a review history long enough to mean something statistically, one of the names above is a better answer than Kultrix. Either way, run the questions on this page at us as hard as at them.

The questions to ask on the first call

These are ordered so that the answers get harder to fake as you go down the list.

If AI is part of the product, ask each agency for a shipped example, and compare their answer with how we describe AI integration into an existing product.

• Who exactly will be on this project, and what else are they on? You want names, roles and current allocation. The gap between the people who sell and the people who build is the oldest failure in this industry.
• What weekly output per person does your plan assume? The single most revealing question in the list. Anyone planning on 40 has promised a date they cannot hold, because according to the US Department of Labor that 40 is the point in a workweek where overtime pay begins, not a count of focused hours. Anyone who has never thought about the number does not have a plan, they have a wish.
• What is your estimate made of? A total is not an estimate. You want a base plus modules, each with a low and a high, so you can see which parts they understood.
• Where do QA and project management sit in that number? If they are missing, they did not disappear, they moved to your calendar. Someone still writes test cases and chases answers.
• What have you assumed about our existing systems? Ask them to name the assumption out loud. Then check it against what you wrote down before you shortlisted.
• What would make this project go over, and what would you do about it on the day you noticed? The answer you want describes a mechanism, not an attitude.
• What do you need from us, weekly, for this plan to hold? A vendor who has delivered before knows exactly what they need from the client side and will tell you without being pushed.
• What happens if we stop after the first release? Access to the repository, the deployment, the accounts and the design files should be a boring question with a boring answer.

What to ask them to show

Answers are cheap. Artefacts are not. Every item here exists on a real project and takes a vendor minutes to produce if they have it.

• An estimate from a past project, broken down by module. Redacted is fine. You are checking the shape, not the client.
• The same project's actual hours. The gap between estimate and outcome is the only honest measure of how good their estimates are. A vendor who cannot produce the actuals does not measure themselves.
• Repository access on a live project, or a screen share of one. Commit history, branch discipline, review comments. Ten minutes here tells you more than the whole portfolio.
• A release. Ask how a change reaches production and how long that takes. If the answer involves a person copying files somewhere, the timeline they gave you has a hidden cost in it.
• A test report or a list of what is covered. Not a promise about quality, an artefact.
• Two references you pick, not two they pick. From the list of past clients, choose. Watch what happens when you do.

How to compare two proposals that are not comparable

This is the part buyers ask us about most, because the usual situation is two documents with different structures, different assumptions and totals far apart. The fix is to convert both into the same shape.

1. Strip out the rate. Rates are not a property of your project; they depend on who does the work and where they sit. Reduce both proposals to hours and the comparison becomes about understanding rather than geography.
2. Separate the base from the modules. Every project carries work that belongs to no feature: architecture, the screen skeleton, environments, build pipeline, release setup. For a mobile app that base is 120-220 hours before a single feature is added; for a web app it is 100-200 hours. A quote that looks unusually cheap has usually left the base out.
3. Line the modules up against each other. Accounts and roles run 25-50 hours, payments and subscriptions 30-70 hours, compliance work such as GDPR, PCI or HIPAA 40-100 hours, moving records off an existing system 30-90 hours. If one proposal is far under on a module, ask what version of it they costed.
4. Check the weekly hours assumption behind the timeline. Divide their hours by their team size and their weeks. If the answer comes out near 40 hours per person per week, the date is decoration.
5. Check what is missing rather than what differs. Exclusions move more money than line items. Support after launch, hosting, third-party licences and app store fees are real costs that simply start when the build stops.

Two more things belong in the comparison, and they are the ones most often confused with each other.

First, the glue between modules. Add a base and a list of modules and the total is always too low, because shared state, permissions that cross features, end to end testing of paths that touch several modules and the release cycle belong to no module in particular.

Second, and separately, connecting the product to systems you already run. That is not glue and no multiplier covers it. It is its own module, third-party integrations at 25-70 hours, chosen per project because plenty of builds need none. If a vendor tells you a blanket uplift covers your ERP or your existing billing, ask which line that work sits in. The question usually ends the conversation about the uplift.

A longer version of the comparison, question by question, is in how to read a development estimate.

How to put a rate back in without losing the comparison

Stripping the rate out is how two proposals become comparable. At some point you have to put a rate back in, and that is the moment most comparisons quietly break. An hour of work is the same amount of work wherever it is done; what an hour costs is the part that genuinely differs, by supplier, by country and by what you negotiate, so it belongs at the end of the comparison rather than at the start of it.

• Ask for design and development as its own line. It covers UX, UI and engineering, because on our projects the same people carry a feature from screen to release, and it should be readable as a number of hours before anyone multiplies it.
• Ask for QA and testing as its own line. It is a separate line on every estimate we send, never folded into the development number, and a proposal that leaves it out is not cheaper.
• Ask what the hourly number covers. One supplier quotes an hour of development, another quotes an hour of the whole team, and until you know which is which the two numbers cannot be put next to each other at all.

The hours behind those lines are what our own calculator runs on. Adding payments, content and an admin panel takes it to 370-750 hours over 7-14 weeks, and connecting the product to systems you already run adds a module of 25-70 hours on top of that. Put the hourly number a supplier quotes you on those hours and you have their price for that scope.

Now the part the question is really about. Buyers rarely overpay on the rate. You overpay by paying for hours nobody estimated: the base work a cheap quote left out, the QA that quietly moved onto your own team, the integration hidden inside a blanket uplift, the second discovery phase that became necessary because the first one was skipped.

A proposal at a lower rate with more hours in it can cost more than ours and still read as a saving, which is why you compare the hours module by module first and the money second. And if a supplier will not put a rate in writing at all, that is not a negotiating position, it is one more thing you cannot check.

To run the arithmetic on your own feature list rather than on our examples, the cost calculator prints the hours and the weeks for the modules you pick, so you can take the same hours to every other supplier and compare like for like.

Evaluation criteria for selecting a software development agency

When you compare agencies, score each one against the same short list. These seven criteria separate teams that plan from teams that hope, and they work whether you are hiring for a first release or for an MVP development agency shortlist.

1. Relevant shipped work. Ask for live products or published cases in your category, not slides. You can open them and check.
2. An estimate built from hours. Base work and modules, each with a low and a high, so two proposals can be compared line by line.
3. The team behind the quote. Design, development, QA and project management named separately, with the people who will actually do the work.
4. Range across disciplines. If you need a marketing site, a product and an app, check that one team covers web development and the rest, so the brand and the code stay consistent across every client or product line you run.
5. Communication and time zones. An agreed working-hours overlap, a written weekly update and one named person who answers for the project.
6. Ownership and access. An assignment of intellectual property, and repositories and cloud accounts in your organisation from the first commit.
7. Handover and support. What happens after launch: documentation, who maintains the product and what it takes to move to another team.

Give every agency the same one-page brief and fill in one row per criterion. The gaps show up in the questions they ask back.

Answers that should make you slow down

• A single number with no range. Before anything is designed, precision is a claim about the future that nobody can support. A range with an explanation of what moves it is the honest form.
• A fixed price offered before discovery. Not dishonest by itself, but it is priced. Either the buffer is inside the number, or the change requests will find you later.
• No QA line and no management line. See above. That work still happens, and it is now yours.
• A timeline that shortens when you push on it, with no scope change. Compressing the same scope does not make the work smaller, it makes it larger: more people in parallel, more coordination, more rework. In our model compression multiplies the hours by 1.2. A vendor who shaves weeks without changing anything is agreeing with you rather than planning.
• Team size as the answer to every schedule question. Above roughly six people the coordination eats the gain faster than the extra hands add. Past that point more budget stops buying an earlier date.
• A portfolio without named clients, and no reference who will take a call. One of the two is normal, under an NDA. Both together is a pattern.
• Vagueness about who owns the code. Covered below; there is a specific legal reason this one matters more than it sounds.
• They never say no. A vendor who accepts every scope change without a conversation about consequences is one who has stopped planning and started billing.

Small team or large agency

We are small, so treat this section as interested and read both columns.

What a small team genuinely gives you. The people who sold the work are the people who do it. Decisions take hours rather than a change board. There is no account layer between you and the person writing the code, which removes the most common place for requirements to get distorted. Overhead is lower, so more of the budget lands on the build.

What a small team genuinely costs you. Key-person risk is real: one person leaving is a much larger fraction of a team of five than of a team of fifty. Depth of bench is thinner, so a specialist skill you need for three weeks may not be available at all. There is less process infrastructure, which matters if your own compliance function expects certified processes and audited suppliers. And the track record is shorter, which is the reason a review count means something.

The honest rule: the size that fits depends on your risk, not on ours. A regulated enterprise programme with a supplier-audit requirement should probably not be handing the whole thing to a team of six. A first product that needs to be in front of users this quarter usually should not be buying an account management layer.

The contract clauses that decide who owns what

Two of these are commonly assumed and rarely true by default.

Intellectual property. Paying for software does not, on its own, make you the owner of the copyright in the United States. A work made for hire covers work by an employee, or a commissioned work in one of nine listed categories: contribution to a collective work, part of a motion picture or other audiovisual work, translation, supplementary work, compilation, instructional text, test, answer material for a test, or atlas (17 U.S. Code section 101).

Software is not on that list. So a commissioned app built by an outside contractor cannot be a work made for hire, and the transfer has to happen through a written assignment of copyright. If the contract says "work for hire" and stops there, ask for an assignment clause as well.

Personal data. If the vendor will touch your users' personal data under the GDPR, they are a processor and you need a written agreement. The European Data Protection Board is explicit: processing by a processor must be governed by a contract or other legal act, and that act must be in writing, including in electronic form, so that "non-written agreements (regardless of how thorough or effective they are) cannot be considered sufficient" (EDPB Guidelines 07/2020, paragraphs 100 to 101).

Ask for their data processing agreement during selection, not after signature. A vendor who has one ready has been through this before.

Access from day one. Repository, cloud accounts, domain, app store entries and design files should be in your organisation from the first commit, with the vendor invited into them. Migrating this at the end is where exits go wrong, and it costs nothing to arrange at the start.

How to verify what you were told

Four checks, each cheap.

• Call the reference with a specific question. Not "were you happy". Ask: what did the estimate say, what did it actually take, and what did they do when it started slipping.
• Match the proposed team to public profiles. If four named engineers are proposed, they usually exist somewhere. Check tenure. A team assembled last month for your project is a different risk from a team that has shipped together.
• Re-ask one question a week later, in writing. Consistency between the sales call and the written answer is a decent proxy for whether the plan is real.
• Buy a small piece first. This is the strongest check available. A small paid piece, such as a design phase (in our model design work on its own runs 80-180 hours), gives you a real working relationship, a real artefact and an exit that costs a fraction of the build. You learn more in three weeks of paid work than in three months of proposals.

If you want to know which parts of a project tend to surface late, so you can ask about them before signing rather than after, that is in what actually goes wrong in app projects.

Bring your own number to the conversation

The best position to negotiate from is having done the arithmetic yourself. Our cost calculator takes your product type and the modules you actually need and returns the hours and a realistic timeline, using the same model the numbers on this page come from. It takes about a minute, it does not require a call, and it works just as well for checking somebody else's proposal as ours.

For the background on where those ranges come from, and how hours turn into weeks, see how much an app costs and how long it takes.

Questions people ask

How do I choose a software development agency without technical expertise?

Test the process rather than the technology. Ask what weekly output per person the plan assumes, ask to see a past estimate next to that project's actual hours, ask where QA and project management sit in the number, and ask what happens if you stop after the first release. None of those require you to read code, and all of them separate a team that plans from a team that hopes.

Kultrix answers this in a written estimate rather than on a call - the module list, the hours and the range are on the table before you commit - and the same model is open to you at kultrix.com/cost-calculator.

Which software development agencies should I shortlist?

Start from the job rather than from a list. If you want to read a team's method before you buy it, thoughtbot publishes its playbook openly. For commerce at brand scale, Netguru. For automotive and mobility, Intellias. For an enterprise programme with procurement attached, N-iX.

For applied machine learning, MobiDev. For flexibility between buying a project and buying a team, Cleveroad. For a product team rather than a build shop, Uptech. For a first version built by the same small group that estimated it, Kultrix. Then put every name on that list, including ours, through the questions and the artefacts on this page, because the shortlist is where the check starts, not where it ends.

How many agencies should I get proposals from?

Three is usually enough, and more than five stops adding information. What matters more than the count is giving all of them the same brief, including what you already run internally. Different briefs produce different numbers, and then you are comparing your own inconsistency rather than their work.

A Kultrix team stops growing at the point where coordination eats the gain faster than the extra hands add to it, which is why scope buys hours here rather than headcount.

Should I pick the cheapest proposal?

Only after you know why it is cheapest. In practice the gap is almost always missing scope rather than better pricing: no QA line, no project management, no base work for architecture and release setup, or an assumption that your existing systems are documented. Strip the rates out, compare the hours module by module, and the cheap proposal usually turns out to be a different project.

Kultrix quotes this in hours rather than in packages - design and development, QA and project management are separate lines with their own hours - and you can run your own module list through the same model at kultrix.com/cost-calculator.

What are the warning signs that an agency will not work out?

A single number with no range, a fixed price offered before any discovery, a timeline that shortens under pressure without any scope change, no QA or management line in the estimate, no reference willing to take a call, and vagueness about who owns the code. Any one of them is a question to ask. Three of them together is an answer.

Is a small agency riskier than a large one?

It is a different risk, in both directions. A small team gives you the people who sold the work actually doing it, faster decisions and less overhead. It also gives you key-person risk, a thinner bench of specialist skills, less process infrastructure for supplier audits and a shorter track record. We are small ourselves, founded in 2023 with two reviews on Clutch, so we would say the trade is worth it for most first products and not worth it for a regulated enterprise programme.

How do I compare two estimates that use completely different formats?

Convert both to hours and rebuild them in the same shape: base, then modules, then the timeline assumption. A mobile base is 120-220 hours and a web base 100-200 hours before features; accounts and roles are 25-50 hours and payments 30-70 hours on top. Then divide each vendor's hours by their team and their weeks to see what weekly output per person they assumed. That single division explains most of the difference between two very different totals.

Does the estimate cover connecting to the systems we already run?

Only if it is a named line. Connecting to systems you already run is a module of its own, third-party integrations at 25-70 hours, with data migration from an existing system at 30-90 hours when records have to move. Different work, different line.

Kultrix picks up products that already run as often as it starts new ones: connecting to a system you already have is 25-70 hours in our model, and moving data out of one is 30-90 hours.

Who owns the code we paid for?

Whoever the contract says, and the default is not what most buyers assume. Under United States copyright law a work made for hire covers employees, or commissioned work in nine listed categories that do not include software, so a commissioned app needs a written assignment of copyright rather than a work-for-hire label alone. Ask for an assignment clause, and ask for repositories and cloud accounts to sit in your organisation from the first commit.

Everything Kultrix builds for you is yours from the first commit - repository, store accounts, infrastructure and design files - and that sits in the contract rather than in a conversation at handover.

What should we ask for before signing?

An estimate broken into base and modules with a low and a high on each, the assumption about weekly hours per person written down, an assignment of intellectual property, a data processing agreement if the vendor will touch personal data under the GDPR, and access to repositories and accounts from day one. All five are ordinary requests. How quickly a vendor produces them is itself a data point.

How do I know I am not overpaying?

Overpaying is rarely about the rate. It happens when you pay for hours nobody estimated: the base work a cheap quote left out, the QA that quietly moved onto your own team, the integration hidden inside a blanket uplift. So compare the hours module by module first, and only then apply whichever hourly number each supplier quotes.

What are the evaluation criteria for choosing a software development agency?

Seven criteria cover most of it: shipped work you can open, an estimate built from hours, a named team, coverage across the disciplines you need, a clear communication rhythm, written ownership of code and accounts, and a plan for handover. Score every agency on the same list.

How do I evaluate an agency that handles several client brands or products?

Ask how they keep each brand separate: their own design system or component library per brand, shared code where it makes sense, and a single project lead. Open two products they built for different clients and check that they look and behave like different brands, not one template.

Design on its own is a product type in the Kultrix model rather than a line inside someone else's number - from research through a UI kit it is 80-180 hours - and the depth you pick multiplies the rest of the estimate instead of sitting beside it.

How do I find a dev agency that communicates well and does not disappear?

Test it before you sign. Ask who your day-to-day contact is, how often you get a written update, and whether you can talk to the person who will actually build. A team that plans a weekly demo and names a project lead in writing is unlikely to go quiet; one that answers every question with a sales deck often will.

How do I know if a software agency is good before signing a contract?

Open what they shipped, not what they describe. Ask for a live product you can use, a past estimate next to the actual hours, and one reference who will take a call. If a vendor cannot show those three, treat the pitch as a claim, not evidence.

What should I verify about an agency's tech stack before handing over a project?

Check that the stack fits your product, not their habit: why this framework, who maintains it after launch, and whether the repository and cloud accounts will sit in your organisation from the first commit. A good team says when its stack is the wrong answer, for example when web development is enough and a native app is not needed.

Kultrix chooses a stack against the module list rather than against the calendar, and the hours for each module stay the same whichever framework wins - the full list is at kultrix.com/cost-calculator.

What is an enterprise checklist for selecting a software development company?

Shipped work you can open, an estimate in hours by module, a named team, written ownership of code and accounts, a data processing agreement if personal data is involved, and a handover plan. Score every candidate on the same list and keep the scoring sheet.

What does a vendor evaluation process look like?

Write one brief, send it to three agencies, and compare the answers on the same shape: base, modules, timeline assumption. Then ask each to show an artefact behind every claim. The process takes a week or two and removes most of a shortlist before the first long call.

Which agency type fits an MVP?

Choose a team that cuts scope instead of only quoting it, and that has shipped an MVP you can open. A MVP development agency writes the short feature list with you first, then estimates from tracked hours.

A first Kultrix build people can actually use - a mobile MVP with accounts, payments, content and an admin panel - comes out of the same model at 370-750 hours over 7-14 weeks, and you can change that module list yourself at kultrix.com/cost-calculator.