Choosing a Development Partner: A 12-Point Checklist

Why the choice matters more than the quote

The gap between a good and bad development partner is not 20% on price — it is whether you get working software at all. A mediocre partner at half the price still costs more, because you pay twice: once for the failed build and again for the team that rebuilds it. The industry is full of second-attempt projects for exactly this reason, and it is a pattern we see across every market, not a local quirk.

Price also fails as a quality signal in both directions. Some five-figure agencies subcontract to the same freelancers you could have hired directly; some small studios ship excellent work at a fraction of agency rates because their production method is genuinely cheaper. That is why the checklist below measures behaviour and terms, not headcount or hourly rates.

The 12-point checklist

Score each candidate one point per check passed. Ten or more: proceed with confidence. Seven to nine: proceed, but tighten the contract around whatever failed. Below seven: keep looking, whatever the price. The checks are ordered roughly by when you can perform them — the first few need nothing but a browser.

• 1. They show you live, shipped products you can click — not mockups or screenshots.
• 2. You can talk directly to the person who will actually build your project, not only a salesperson.
• 3. They ask questions about your business before talking about technology.
• 4. They push back on at least one thing in your brief — a feature to defer, a risk you missed.
• 5. The price is fixed or firmly capped, in writing, before any work starts.
• 6. The quote states what is excluded, not just what is included.
• 7. Code lives in a repository you own (your GitHub) from the first week, not delivered at the end.
• 8. Deployment goes to cloud accounts you own — hosting, domain and databases in your name.
• 9. They can explain their quality process — code review, testing, and who checks AI-generated code before it ships.
• 10. Warranty terms are written down: what counts as a bug, for how long, at whose cost.
• 11. The contract assigns intellectual property to you on payment, in plain words.
• 12. They respond quickly and specifically during the sales stage — days, not weeks; answers, not brochures.

The checks that are truly non-negotiable

If you shorten the list to two items, keep the written price (check 5) and repository ownership (check 7). A written fixed or capped price moves the risk of slow work onto the builder, which is the only place the incentive to work efficiently does any good. An open-ended hourly arrangement on a vaguely scoped project is how a $3,000 idea becomes a $30,000 invoice — a pattern common enough across the market to treat as the default outcome, not the exception.

Repository ownership is the other keystone because it removes the partner's strongest hostage position. When the code sits in your GitHub and runs on your cloud from week one, a dispute in month two costs you a relationship, not your product. Any pushback on this — 'we deliver at the end', 'our platform hosts it' — converts a service purchase into a lock-in, and you should price that risk accordingly.

Red flags that should end the conversation

Some findings are not points to deduct — they are reasons to stop. Each of these has a benign-sounding explanation and an ugly base rate, and none of them improves after the contract is signed.

• No live product anywhere — every 'example' is a design file or a site 'currently in redevelopment'.
• Full payment demanded up front. Deposits are normal; 100% before work is not.
• The price cannot be written down 'because it depends'. Scope discovery is real, but it ends with a number on paper.
• Your code will live only on their platform or their accounts, with export 'available on request'.
• They agree with every single thing in your brief, instantly. Nobody who has shipped software believes every brief is perfect.
• Pressure to sign this week to hold a price or a slot. Software teams with genuine demand do not sell like gym memberships.

What the market charges, and why price filters badly

Clutch's published pricing guide puts most listed software development companies between $25 and $49 per hour, with typical rates of $25–$49 in markets such as India, Ukraine and the Philippines against $100–$149 in the US, Canada and Australia, at the time of writing. Run the arithmetic on an identical project and the spread becomes vivid: two developers for four weeks at 40 hours each is 320 hours, which prices anywhere from 320 × $25 = $8,000 to 320 × $149 = $47,680 before a single line of scope differs.

Neither end of that range tells you whether the software will work, and AI-assisted production has broken the price-quality correlation further. Across PINCLER's 79 documented projects, every build is fixed between $500 and $2,500 with a median of $1,450 — not because each hour is cheaper, but because the hours themselves collapsed; the dataset behind those figures is published at /research/what-you-can-build. Price mostly tells you the production method and the postcode. The checklist tells you the discipline, which is the thing you are actually buying.

The failure statistics your checklist is up against

The base rates justify the caution. The Standish Group's CHAOS research has reported that only around 31% of software projects succeed outright, with roughly 50% challenged and 19% failing altogether. McKinsey's study with the University of Oxford across more than 5,400 IT projects found the large ones running 45% over budget on average and delivering 56% less value than predicted — and 17% went so badly they threatened the company's existence.

Two useful readings for a buyer. First, most of the carnage in that research involves large, long projects; the same CHAOS research consistently finds small, tightly-scoped projects succeeding at several times the rate of large ones. That is itself a selection criterion: prefer a partner who insists on splitting your idea into small, shippable phases over one who proposes a single grand build. Second, none of those failed projects hired a partner who looked bad on paper. The checklist exists because glossy proposals and confident calls are what the failures looked like from the inside, too.

Vetting an AI-assisted studio specifically

AI-assisted development is now the norm rather than a niche: Stack Overflow's 2025 Developer Survey found 84% of developers using or planning to use AI tools in their work, up from 76% the year before, and Google's DORA research in 2024 reported 75.9% of respondents relying on AI for at least part of their job. The same surveys carry the caveat that matters to a buyer — 46% of developers in the Stack Overflow survey said they do not trust the accuracy of AI output, and DORA found 39% with little or no trust in AI-generated code.

So check 9 deserves extra weight when the studio is AI-first: ask precisely who reviews AI-generated code before it ships, and listen for named humans with senior experience rather than 'the AI tests itself'. At PINCLER the split is explicit — AI writes boilerplate, tests and first-draft interfaces; senior engineers own architecture, security, review and release — and the tooling mix across our 79 documented projects is public: GPT on 76 projects, Cursor on 75, Claude Code on 63, Claude on 55. A studio that cannot describe its review process this concretely is asking you to trust a keyboard.

Running the checklist in one week

The whole evaluation fits into five working days without rushing anyone. Day one: write the one-page brief — problem, users, core workflow, integrations, what done means — and send the identical document to your three candidates. Days two and three: perform the browser checks yourself while you wait; live products, contract templates if published, and how each firm describes its quality process are all findable before a single call. Days four and five: hold the calls, ask for the written quote, and score every candidate against the same twelve lines.

Two details make the week decisive rather than merely busy. Ask each candidate the same three questions in the call — what would you cut from this brief, what is the riskiest part, and what do you need from me — because the answers separate teams that have shipped from teams that have pitched. And keep a note of response times: the gap between 'quote promised' and 'quote received' is the most honest preview of the project cadence you will get, and it costs nothing to measure.

Scoring in practice: what the comparison usually reveals

Run three candidates through the twelve checks and a pattern almost always emerges: the spread on checklist score is wider than the spread on price. It is common to see a mid-priced candidate outscore both the cheapest and the most expensive — because the checklist measures production discipline, and discipline is not what you are billed for; it is what you silently lose money without.

For transparency, here is how PINCLER answers the same twelve checks: fixed price between $500 and $2,500 in writing within one working day; code in your GitHub and your cloud from the start; AI-assisted production with senior engineers owning architecture, review and release; and a written bug-fix warranty of 14 to 60 days by tier. We publish this because we think every studio should be scoreable the same way. If you are drawing up a shortlist, a free 30-minute call is an efficient way to run us through your own checklist — or start with the use-case page closest to your project, which lists the price and timeline before you ever speak to us.