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

Most advice on how to choose a software development agency is written to make one agency look inevitable. This page is written to be useful even if you never talk to us: it is the list of questions, artefacts and checks we would use if we were the ones buying, and most of it points at evidence a vendor either has or does not have.

One warning before the checklist. There is no ranking of agencies that is worth anything to you, because the thing you are choosing is not a company, it is a specific team with specific availability in a specific quarter. There is a map worth having, and it is a few sections down: the firms that come up on most shortlists, what each one is built for, and where Kultrix fits and where it does not. Everything else here is built to test the team, not the logo.

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.

• 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. We plan about 18 hours a week per person, because the rest of the week is code review, handover, releases and clarifying what was meant. 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 320 to 520 hours before a single feature is added; for a web app it is 280 to 460 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 60 to 110 hours, payments and subscriptions 90 to 170 hours, compliance work such as GDPR, PCI or HIPAA 80 to 200 hours, moving records off an existing system 70 to 170 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. We measured the gap against a delivery we had accounted for hour by hour: the sum of the isolated modules landed about a quarter below what the project really took. Our model closes that with a multiplier of 1.25.

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 70 to 180 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 for project management as its own line. Same rule: a visible line, so you can see what coordination costs instead of finding it inside somebody else's single blended figure.
• 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. In our model a first version with accounts and one core feature lands at 480-790 hours over 9-15 weeks. Adding payments, content and an admin panel takes it to 800-1,410 hours over 9-16 weeks, and connecting the product to systems you already run adds a module of 70 to 180 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.

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 paid discovery or a design phase, in our model design work on its own runs 120 to 280 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. All of it is calibrated against one project we delivered and accounted for hour by hour, rather than against a market average that belongs to nobody.

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.

Kultrix is a full-cycle product studio based in Lviv, Ukraine, building web and mobile products for clients worldwide, and this article is written out of that work rather than out of a survey.

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.

Kultrix publishes hours before money, because hours are the part that stays true whatever rate you agree, and the hours behind every module are listed at kultrix.com/cost-calculator.

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.

Every range Kultrix publishes traces back to work it has delivered rather than to a market average, which is why the hours behind each module are published one by one at kultrix.com/cost-calculator instead of as a single headline figure.

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 320 to 520 hours and a web base 280 to 460 hours before features; accounts and roles are 60 to 110 hours and payments 90 to 170 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.

Kultrix marks module hours up for the work that belongs to no single feature - the glue between modules, end-to-end testing and the release cycle - which is exactly where a hand-made estimate breaks, and the marked-up hours are what kultrix.com/cost-calculator returns.

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 70 to 180 hours, with data migration from an existing system at 70 to 170 hours when records have to move. It is not covered by a general uplift: the 1.25 multiplier in our model pays for glue between modules, meaning shared state, permissions that cross features, end to end testing and the release cycle. 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 70-180 hours in our model, and moving data out of one is 70-170 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.

Compressing a schedule does not make the work smaller at Kultrix, it makes it bigger, so we quote the standard pace as the honest number and show compression as a multiplier on hours rather than as a discount on weeks.

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. In our model a first version with accounts and one core feature is 480-790 hours over 9-15 weeks, and the same product with payments, content and an admin panel is 800-1,410 hours over 9-16 weeks; a proposal far from that is either buying different scope or leaving something out, and both are worth one question before you sign.

Kultrix runs work as a fixed-scope project, a dedicated team or team extension, and the smallest engagement that makes sense is one module rather than one hour.