Questions to Ask a Software Development Agency Before Hiring
The most expensive moment in a software project is rarely the invoice. It is the question nobody asked during the interviews: who owns the code, who fixes defects after launch, and who is actually on the team once the sales call ends. Most agencies answer expected questions well. This guide gives you 42 questions to ask a software development agency, chosen to surface the answers it might not volunteer, along with what a strong reply sounds like and what to ask for as proof.
TL;DR
Screen every agency with the same ten questions in a 20 to 30 minute call, then use the full set of 42 for second-round diligence and pre-contract review.
Ask for evidence with every answer: a sample test plan, an architecture note, an anonymized status report, or a reference you can call.
Treat ownership, security, and exit questions as gates rather than scoring points. An unclear answer on source code or accounts should pause the process.
Compare proposals on the same assumptions, including exclusions, hosting, support, and handover, because the headline price hides most of the difference.
Score finalists on a weighted 100-point scorecard, then confirm your choice with reference calls, paid discovery if scope is uncertain, and a lawyer's review of the contract.
Quick Answer
Before hiring a software development agency, ask who will actually build your project, which similar systems they have delivered, how scope and acceptance are defined, how security and testing are verified, what the estimate assumes and excludes, who owns the code and accounts, and what support and exit terms apply. Request documents for every answer.
Table of Contents
Why These Questions Matter
A software agency interview is a sales conversation by default. Good questions change that. They move the discussion from capability claims to documents, named people, and written terms you can compare across vendors, whether you are commissioning custom software development for a client portal, an internal dashboard, a workflow tool, or an integration between existing systems.
This guide takes a different angle from a general overview. If you are still deciding whether to build, buy, or integrate, start with Articsledge's guide to choosing a custom software development company and the build versus buy comparison. Here the assumption is that you are already talking to agencies and need precise things to ask, what a credible answer contains, which document proves it, and which replies should slow you down.
Each numbered question follows the same logic: the wording to use, why it matters, what a strong answer looks like, and what to request or do next. Examples about a client portal, operations dashboard, approval workflow, or API integration are hypothetical and labeled as such. Standards such as NIST's Secure Software Development Framework give you useful vocabulary, but citing a standard does not prove an agency follows it, and rules that vary by country are flagged where they arise.
Prepare Before the Interview
Agencies answer sharply when you ask sharply. A one-to-two-page brief lets every agency respond to the same problem, which is what makes proposals comparable. If your team is still debating scope, Articsledge's guides to web app development cost and web app development timeline show what usually drives both. Cover these points:
Problem: the pain, who feels it, and what it costs in time, errors, or lost revenue.
Users and workflows: who signs in, what each role may do, and the five to ten tasks the software must support.
Must-haves: what release one cannot ship without, separated from what can wait.
Platform: whether you expect a web application, a mobile app, or both.
Integrations and existing systems: the CRM, accounting, identity, or document tools to connect, and who administers them.
Data: what must move, what condition it is in (see the primer on data quality), and whether it includes personal or regulated information.
Security and accessibility expectations: data types, access rules, and a target such as WCAG 2.2 level AA.
Budget and timing: a realistic range and any fixed dates.
Stakeholders: who decides, who approves, and who tests.
Success metric: a baseline and a target, such as approval turnaround time.
Hypothetical example: "Our account managers spend about six hours a week chasing document approvals for 40 active clients. Release one should let clients sign in, review deliverables, and approve or comment. Messaging can wait." That is enough for a good agency to ask intelligent follow-up questions.
Decide in advance whether a custom build is the right route at all. Subscription software, low-code tools, a freelancer, or an internal hire can each win for small, standard, or short-lived needs. Compare them using the custom software versus SaaS analysis and the internal tool development guide. An agency that agrees with every point in your brief is less useful than one that challenges it.
First-Call Questions to Ask a Software Development Agency
A first call of 20 to 30 minutes should screen for fit, not settle details. Ask the same ten questions of every agency so the answers line up. Each points to the full numbered question later in this guide, where you will find what a strong answer includes.
Fit: Which delivered project is closest to ours in complexity, and what did your own people build? (question 1)
Team: Who would work on our project, and are any of them subcontractors? (questions 12 and 13)
Process: What happens before you give us an estimate? (questions 5 and 6)
Scope: What would the smallest useful first release include? (question 7)
Quality: How do you verify security and quality before a release? (questions 19 and 23)
Estimate: What does your estimate assume, and what does it exclude? (question 31)
Ownership: Who owns the code, repository, hosting accounts, and data when we finish? (questions 34 and 36)
Collaboration: What do you need from us each week? (question 27)
Support: What does support look like after launch, and what does it cost? (question 41)
Honesty: When would you advise us not to build this? (question 3)
A short call cannot verify any of this. Its job is to see whether the agency answers specifically, offers to send documents, and asks you good questions back. Agencies that move straight to price are showing you how they sell and, often, how they scope.
Questions About Agency Fit and Relevant Evidence
Fit is more than an industry label. An agency that built a booking portal may suit your approval workflow better than one that built brochure websites in your sector. These four questions test relevance and honesty before you invest time in detailed proposals.
1. Which delivered project is closest to ours in complexity?
Industry labels mislead; complexity predicts surprises. A strong answer compares your project with theirs on users, roles, integrations, data volume, and compliance, and admits where the match is only partial. Ask for a walkthrough of a live or staging system and for the names of the people who built it. Be cautious if every example is a different kind of system, or if the agency cannot say what it personally built.
2. What measurable outcomes did those projects produce, and may we speak to the client?
Outcomes should be stated the way the client would state them, with a baseline: approval time, error rates, adoption. A credible agency offers references willing to talk, or explains a confidentiality limit and arranges a private demo instead. Website testimonials are marketing; a reference call, a staging walkthrough, or a client-approved case summary is verifiable. Be wary of results with no baseline and no source.
3. When would you advise us not to build custom software?
This question tests honesty. A strong agency names the cases: a standard process that software as a service already fits, a small workflow that low-code can cover, or a need that an integration layer such as iPaaS can handle. It can also say when a freelancer or internal hire is cheaper. Ask what it would do if your answer is "buy." If an agency never says no, discount its yes.
4. Tell us about a project that went badly. What changed afterward?
Every agency has one. A useful answer identifies the cause (unclear scope, a late integration, staff turnover), what the agency did for the client at the time, and what it changed in its process. Ask whether that client would speak with you. Blame placed entirely on the client, or "we have never had one," suggests limited awareness of delivery risk.
Questions About Discovery, Requirements, and Scope
Discovery is where scope becomes a plan, and weak discovery is a common source of change orders. Articsledge's guide to custom web application development describes how the process typically runs; these seven questions test whether an agency does it well.
5. How do you turn our business goals into requirements?
Look for a method, not a template: stakeholder interviews, observation of real workflows, user roles, constraints, and a written restatement of the problem for you to correct. Ask for a sample discovery output, such as a user-story map or requirements document with client details removed. Be cautious if requirements come from a feature checklist, or if the agency quotes a price before asking who the users are.
6. Is discovery paid or included, and what do we own at the end of it?
Both models can be legitimate. Paid discovery lets an agency invest senior time and produces something you can take to other agencies for comparison; included discovery is often shallower. Ask for the deliverables (requirements, wireframes, an estimate range, a risk list), the duration, and whether you may use the output elsewhere. Be wary of "free" discovery that locks you in, or paid discovery with no defined output.
7. How do you define and prioritize a minimum viable product?
An MVP is the smallest release that tests the idea with real users, not a cheap version of everything. Strong agencies rank features by user value and risk, propose a lean first release, and show what is deferred and why. Ask for the ranked list. Be cautious when "MVP" means a long feature list, or when nothing is ever cut.
8. How are acceptance criteria written, and who signs them off?
Acceptance criteria are testable statements of what done means, such as "a client user can approve a document and the account manager is notified within one minute." A strong answer shows plain-language examples, names a sign-off owner on your side, and links each criterion to a test. Ask for a sample. Phrases like "user-friendly" or "fast" with no measure are a warning.
9. What do you do when requirements are unclear or assumptions may be wrong?
Uncertainty is normal; hiding it is the problem. Good agencies list assumptions in the proposal, attach a confidence level to estimates, and isolate unknowns in a short discovery step. Ask for the assumptions list and which three would most change the cost if they proved false. Be cautious of a fixed price with no assumptions, since the risk usually returns as change orders.
10. How will you assess integrations before you estimate them?
Integration is where optimistic estimates fail, because each connected system brings its own API limits, permissions, and quirks. A strong answer includes reading the third-party documentation, confirming API access, testing a sample call, and agreeing a fallback if access is restricted. For a CRM integration or a connection through middleware, ask which risks surfaced on similar work. Be cautious if the agency assumes any API will simply work.
11. How will we measure whether the software worked?
Success should be defined before building: shorter approval time, fewer manual entries, faster client onboarding. A good agency helps you set a baseline and target, builds the reporting you need, and agrees when you will review results after launch. Ask how metrics will be collected and who owns them. If success means only "delivered on time," outcomes remain your problem.
Prefer plain text? Explore Custom Web Application Development to see how project assessment and scoping work at Articsledge.
Questions About the Team, Architecture, and Integrations
Technical questions need not be technical for you to ask. You are looking for named people, reasons behind choices, and artifacts an independent reviewer could assess. A grounding in software engineering helps, but this section keeps the vocabulary light.
12. Who exactly will work on our project, and how senior are they?
Proposals often showcase senior leaders who then step back. A strong answer names the delivery team, their experience, and their time allocation, and says who covers frontend, backend, design, and QA. Ask for short profiles and for commitments about replacing people. Be cautious if the team is described only by job titles, or if the people on the sales call will not be on the project.
13. Do you use subcontractors or freelancers, and how are they bound?
Subcontracting is common and not a flaw, but it must be visible. Ask which work is outsourced, where those people are based, how they are bound by confidentiality and IP assignment, and whether the agency stays responsible for their output. Get the disclosure in writing, with your approval required for changes. Refusing to disclose is a red flag; disclosing and managing it is a sign of maturity.
14. Who is the accountable technical lead, and how much of their time do we get?
Someone must own architecture decisions and answer for quality. A strong answer names one person, states a weekly time commitment, and explains who steps in if they leave. Ask to meet them before you sign. A technical lead spread across many projects with no cap can leave your project drifting between decisions.
15. Why this technology stack for us, and which alternatives did you reject?
The right framework and hosting approach depend on your users, integrations, security needs, and who will maintain the system later. A strong answer ties each choice to your requirements, names the trade-offs, and considers how easily another team could support it. Ask for a one-page decision record in plain language. Be cautious if the answer is simply what the agency always uses. If machine learning features are involved, see the guide to choosing an AI development agency.
16. How do you keep the code maintainable?
Maintainability decides what change costs in year two. Look for mandatory peer review, coding standards, automated tests, current documentation, and a habit of logging shortcuts as technical debt to repay later. Ask for the coding standards and an example code review. If the agency says the source code is the documentation, plan for a costly handover.
17. How do you manage third-party dependencies and API changes?
Your application will depend on libraries, services, and APIs outside the agency's control. A strong answer inventories dependencies, scans them for known vulnerabilities, pins versions, and watches for breaking changes. It may also produce a software bill of materials, the formal record of components described in the 2021 Commerce Department minimum elements report. Ask who monitors changes and who pays when a vendor deprecates a feature.
18. What load and performance should we plan for, and how will you check it?
Most business tools do not need exotic scale, and over-engineering costs money. A strong answer asks about user counts, data volume, and peak periods, proposes a proportionate design, and agrees measurable targets such as page response times under expected load. Ask when load testing happens and what would force a redesign. Be cautious of claims that the system will scale infinitely, with no numbers.
Want the details first? See what Articsledge can build for client portals, internal tools, dashboards, and integrations.
Questions About Security, Privacy, Quality, and Accessibility
Security claims are cheap; demonstrations are not. Frame these questions around practices you can see and documents you can read. NIST's Secure Software Development Framework describes high-level secure development practices and notes that buyers can use it to communicate with suppliers. OWASP's Application Security Verification Standard lists requirements for testing web application security controls. Neither is a certificate an agency can hold, and neither guarantees a secure product.
19. Which secure development practices do you follow, and how can you evidence them?
A strong answer describes a written lifecycle covering design review, code review, dependency scanning, secrets management, and release approval, mapped even loosely to NIST SP 800-218. Ask for the policy, a sample security checklist, and the name of the person accountable for security on your project. "We follow best practices" with no document is a weak answer, and a framework logo is not evidence.
20. How will you design authentication and role-based permissions?
Broken access control ranks first in the OWASP Top 10:2025, so permissions deserve early attention. A strong answer covers sign-in (including multi-factor options), roles, least privilege, session handling, and tests that one client cannot see another client's data. Ask for the permission matrix as a design artifact and for how an audit trail will record sensitive actions. Be cautious if roles are decided late or tested only by hand.
21. How will you protect personal and business data, and where will it be stored?
Ask where data lives, how it is encrypted in transit and at rest, who can reach production, and whether real data ever reaches test systems; Articsledge's primers on cloud security and test data explain the terms. Strong answers name the hosting region and any sub-processors. Where EU personal data is involved, GDPR Article 28 requires a processor contract; confirm with counsel what applies to you. Be wary of vague "bank-grade" promises.
22. How do you assess threats and fix vulnerabilities?
Look for threat modeling at design time, automated scanning in the pipeline, and independent testing for higher-risk systems, structured around something like OWASP's ASVS. The Top 10:2025 also lists software supply chain failures and security misconfiguration among leading risks. Ask what remediation timelines the agency commits to and request a redacted test report. "We have never been hacked" is not an answer. For background, see Articsledge's overview of cybersecurity.
23. What testing runs before every release, and who owns QA?
Quality needs layers: automated unit and integration tests, regression tests for critical paths, manual exploratory testing, and acceptance testing by your team. A strong answer says who owns QA independently of the developers, what blocks a release, and how defects are tracked. Request a sample test plan and defect report. "We test at the end" signals risk.
24. What evidence will we see before accepting each milestone?
Acceptance should rest on evidence, not on the mood of a demo. Strong answers pair each milestone with test results, a working build in a staging environment, and sign-off against the acceptance criteria. Agree the review window and how late-found defects are handled. Ask to see an anonymized acceptance record. If acceptance simply means the invoice is paid, there is no real test.
25. How do you build and verify accessibility?
WCAG 2.2, a W3C Recommendation from December 2024, defines testable success criteria at levels A, AA, and AAA, and W3C notes they can be used in purchasing and contractual agreements. For a portal, ask how sign-in meets the Accessible Authentication (Minimum) criterion and how target size and focus visibility are handled. Request a written conformance target, an audit plan mixing automated and manual checks, and a list of known gaps. Legal duties vary by jurisdiction.
Questions About Delivery, Communication, and Governance
Most project friction is communication, not code. Separate promises of good communication from contractual commitments such as demo cadence, response times, and named decision makers.
26. What will we see, and how often?
Working software beats status reports. Teams following Scrum hold a Sprint Review at the end of each sprint, which the Scrum Guide caps at one month, to inspect what was built. A strong answer commits to regular demos of working features, a shared backlog, and a short written summary of risks and budget. Ask for a sample report. Reports that track hours but never show working software are a warning. Articsledge's primer on agile methodology gives background.
27. Who decides on each side, and what do you need from us each week?
Projects stall when feedback is slow. A strong agency names one decision maker for you, asks for a realistic weekly time commitment, and lists your dependencies: system access, sample data, approvals. Write those responsibilities into the plan. If the agency asks nothing of you, its plan probably assumes nothing will go wrong.
28. How do you handle time zones, response times, and escalation?
Distance is manageable when expectations are explicit. Ask for overlap hours, response times for routine and urgent questions, and an escalation path above the project manager. For offshore teams, ask how written specifications and handoffs avoid a lost day. Compare these with the service level commitments in support terms. "We are always available" is a slogan, not a commitment.
29. How do you handle delays and change requests?
Change is normal; surprise is expensive. A strong answer describes a written change-control process: request, impact on cost and schedule, your approval, then work. It also explains how the agency warns you early about slippage and what options it offers, such as reducing scope. Ask to see the clause. Be cautious if changes are agreed in chat with no price attached.
Questions About Pricing, Estimates, and Total Cost
Quotes are hard to compare because each bundles different assumptions. Articsledge's guides to custom software development cost and client portal development cost explain the drivers; these four questions make quotes comparable.
30. Which pricing model do you propose, and why does it fit this project?
Fixed price suits a well-defined scope, time and materials suits evolving work, a dedicated team suits continuing product development, and milestone payments can sit on top of any of them. A strong answer ties the model to how certain your requirements are and says who carries which risk. Ask what happens if estimates prove wrong. A fixed price offered before any scoping is a warning.
31. What assumptions, ranges, and confidence sit behind the estimate, and what is excluded?
Estimates are predictions. Strong ones give a range or confidence level, list assumptions, and itemize exclusions such as data migration, third-party fees, accessibility audits, and training. Ask for the breakdown by phase and two or three scenarios. Be cautious when the estimate is a single round number, or when one proposal sits far below the rest with no explanation.
32. Which costs sit outside the quote?
Total cost of ownership includes hosting, monitoring, licenses, maintenance, enhancements, and your own staff time. Ask every agency to price years two and three, not just the build. Clutch's pricing guide, updated September 21, 2026, reports review-based figures: typical reviewed projects at $10,000 to $49,999, and an average of about $132,480 over roughly 13 months. The sample is self-selected, so use it to sanity-check magnitude, not to judge a quote.
33. How are payments tied to deliverables, and how do you treat contingency and scope growth?
Payments should follow accepted deliverables, not elapsed time. Ask for the schedule, what triggers each payment, and how disputed work is handled. For contingency, ask whether it is built into the estimate or billed separately, and how scope growth is priced. Be careful with large upfront payments that come without milestones or refund terms.
To share your requirements, discuss a project assessment with Articsledge.
Questions About Contracts, Intellectual Property, and Control
Contracts turn promises into obligations. This section is business guidance, not legal advice; ownership and liability rules differ by jurisdiction, so have qualified counsel review anything consequential.
34. Who owns the new code and designs, and when do rights transfer?
Do not assume you own what you pay for. The U.S. Copyright Office explains that commissioned work counts as a work made for hire only if it fits one of nine listed categories and both parties sign a written agreement saying so; otherwise ownership usually moves by written assignment. Ask whether you receive an assignment or a license, and when. Be wary of clauses that transfer rights only after every invoice, disputed or not, is paid.
35. Which pre-existing code, open-source, and third-party components will you use?
Agencies often reuse internal libraries. That can save money but leaves them owning part of your system. Ask for a list of pre-existing components, the license for each, and whether you keep a license after the engagement ends. For open-source software, ask who reviews license obligations. Be cautious of undisclosed reuse, or licenses that restrict how you can use or sell the product.
36. In whose name will the repository, hosting, domain, and data accounts be held?
The simplest protection is holding the admin accounts yourself from day one. Ask for the plan: repository under your organization, cloud accounts in your name, credentials in a shared vault, and the agency granted access it can lose. Ask what happens to data and backups on exit. Accounts held by the agency are leverage, not convenience.
37. How are confidentiality, subcontractor obligations, and warranties handled?
Look for mutual confidentiality, data-processing terms where personal data is involved, and the same obligations passed to subcontractors. Ask what warranty covers defects after delivery, how long it runs, and who pays for fixes. A warranty of best efforts with no remedy period gives you little. Get these in the contract, not in the sales deck.
38. How can either side terminate, and how are disputes and lock-in handled?
A good contract defines notice periods, payment for completed work, handover duties on exit, and escalation before litigation. Ask how data export, documentation, and knowledge transfer work if you leave, and which law and venue govern. Track renewal and support dates in contract lifecycle software or a simple calendar. Be careful with long minimum terms and exit fees that make leaving impractical.
Contract-check list: confirm these are written down before signing.
Statement of work with deliverables, assumptions, and exclusions
Acceptance criteria and a defined review window
Change-control process with cost and schedule impact
IP assignment or license, and when rights transfer
Source code, repository, and build instructions access
List of third-party and open-source components and licenses
Hosting, domain, and repository accounts in your name
Data handling, breach notice, and return or deletion
Warranty, support terms, and response times
Termination, handover, and dispute steps
Questions About Launch, Support, and Handover
Launch is not the end of the relationship, and software keeps changing after it. These four questions protect you in the first year.
39. How do you deploy, roll back, and migrate data safely?
Look for repeatable releases through a staging environment, automated checks, and a tested rollback. Many teams use DevOps practices and infrastructure as code so environments can be rebuilt. For migration, ask for a rehearsal on a copy, reconciliation counts, and go or no-go criteria. Request the release checklist and a sample migration report. "We will copy the files over" is not a plan.
40. What documentation, training, and handover will you provide?
Handover should let another competent team run the system. Strong answers list deliverables: architecture notes, setup instructions, runbooks, user guides, administrator training, and a recorded walkthrough. Ask for a sample and agree when handover counts as accepted. Missing documentation is a hidden cost, not a small gap.
41. What does post-launch support cover, and what does it cost?
Separate defect fixes under warranty from maintenance and enhancements. Ask for response times by severity, security patch commitments, hours included, rates beyond them, and what changes the fee. Get the terms in the contract or a separate service-level agreement. Support promised "as needed," with no response times, will not help during an outage.
42. How are backup, recovery, and exit readiness tested?
Ask for the backup schedule, retention, and the date of the last restore test; a backup never restored is an assumption. For critical systems, discuss recovery time and recovery point targets and whether backup as a service or disaster recovery as a service fits. Also ask what happens if the agency closes or loses a key person: who holds the credentials, code, and documentation.
Reference Checks and Independent Proof
Testimonials are written to persuade; references can be questioned. Ask for two or three clients from the last two years whose projects resemble yours, including one where something went wrong. If confidentiality limits contact, ask for a private demo, a client-approved summary, or a small paid pilot. On a reference call, ask:
Did delivery match the original scope, budget, and schedule, and what changed?
Were the people you met in sales the people who did the work?
How did the team respond to bad news and change requests?
How many defects appeared after launch, and how quickly were they fixed?
Could you run or move the system without the agency?
Would you hire them again for a project this size, and what would you change?
When references are thin, add independent evidence: a staging demo you operate yourself, a sanitized code sample reviewed by someone you trust, or a short security review. For sensitive data or complex architecture, hire a specialist reviewer who is independent of the agency before you sign. A vendor management system can keep track of what each supplier promised.
Strong Answers, Weak Answers, and What to Verify
No single phrase proves competence or incompetence; look for patterns across answers and documents.
Theme | Strong answer | Weak answer | What to verify |
|---|---|---|---|
Scope | Written scope with assumptions, exclusions, and acceptance criteria | "We will figure it out as we go" | Sample statement of work and acceptance examples |
Security | Named practices, an accountable person, and evidence | "Bank-grade security" | Secure development policy and a redacted test report |
Estimate | A range, assumptions, and itemized exclusions | One round number with no breakdown | Phase breakdown and what changes the price |
Ownership | Written IP assignment and accounts in your name | "We will sort it out later" | Draft clauses and an account setup plan |
Communication and support | Named lead, regular demos, response times by severity | "We are always available"; support "as needed" | Sample status report, escalation path, support terms |
Agency Red Flags and Follow-Up Actions
Not every unusual practice is a problem. Some agencies decline fixed prices for good reasons, and some work only in short sprints. Treat these signals as prompts to investigate.
Red flag | Sensible follow-up |
|---|---|
Final fixed price before any scoping | Ask for assumptions, a discovery step, or a range |
Refusal to name the delivery team | Request names, roles, and time allocation in writing |
Unclear ownership of code, accounts, or data | Request draft IP and account clauses before continuing |
No test plan or acceptance criteria | Ask for a sample test plan and acceptance examples |
Security guarantees without evidence | Ask for practices, policy, and a redacted report |
Pressure to pay a large sum upfront | Propose milestone payments tied to accepted deliverables |
No maintenance or handover plan | Ask for support options and a handover checklist |
Price far below every other bid | Ask for a line-by-line comparison against the others |
Separate deal-breakers from negotiable differences. Unresolved ownership, an undisclosed team, no acceptance approach, and unsupported security claims should stop the process until they are fixed in writing. Technology preferences, sprint length, time-zone overlap, and payment schedules are usually negotiable.
Weighted Agency Scorecard and Comparing Proposals
A scorecard turns impressions into a comparison you can defend. Rate each criterion from 1 (no evidence or unacceptable) to 5 (strong and evidenced). Multiply each weight by the rating divided by five, then add the results; the maximum is 100.
Criterion | Weight | A rating of 5 means |
|---|---|---|
Relevant evidence | 15 | Verified, comparable delivery |
Discovery and business understanding | 15 | Clear method, artifacts, and useful challenges to your brief |
Technical approach | 15 | Reasoned architecture and maintainable code |
Security and QA | 15 | Evidenced practices and layered testing |
Delivery governance | 10 | Named lead, demos, and change control |
Commercial clarity and total cost | 15 | Itemized, assumptions stated, multi-year view |
Contract and exit terms | 10 | Clear IP, accounts, and handover |
Verified references | 5 | Relevant references confirm the claims |
Total | 100 |
Here is a hypothetical comparison of two agencies. The ratings are invented to show the arithmetic; they are not a ranking of real vendors.
Criterion | Weight | Agency A rating | Agency A points | Agency B rating | Agency B points |
|---|---|---|---|---|---|
Relevant evidence | 15 | 4 | 12 | 3 | 9 |
Discovery and business understanding | 15 | 5 | 15 | 4 | 12 |
Technical approach | 15 | 4 | 12 | 4 | 12 |
Security and QA | 15 | 3 | 9 | 5 | 15 |
Delivery governance | 10 | 4 | 8 | 3 | 6 |
Commercial clarity and total cost | 15 | 3 | 9 | 4 | 12 |
Contract and exit terms | 10 | 2 | 4 | 5 | 10 |
Verified references | 5 | 4 | 4 | 3 | 3 |
Total | 100 | 73 | 79 |
Check Agency B: 9 + 12 + 12 + 15 + 6 + 12 + 10 + 3 = 79. Agency A totals 73. Keep deal-breakers separate from the score. Set gates before you rate anyone, for example: any rating of 2 or below on security and QA, or on contract and exit, pauses an agency until the gap is fixed in writing. Agency A's 2 on contract and exit would trigger that pause, whatever its total.
Have two or three people score independently, tie every rating to a document, and never change weights after seeing results. Adjust weights up front if your risks differ; a regulated portal might raise security to 20 and lower commercial clarity to 10.
Compare proposals like for like
Normalize proposals before scoring. Ask each agency to price the same scope, assumptions, milestones, support, and ownership terms, then add back anything excluded. Hypothetical example:
Item | Proposal 1 | Proposal 2 |
|---|---|---|
Headline price | $64,000 | $79,000 |
Data migration | +$6,000 | Included |
User acceptance testing support | +$4,500 | Included |
Security testing | +$5,000 | Included |
Handover documentation | +$2,500 | Included |
Like-for-like total | $82,000 | $79,000 |
The cheaper headline became the more expensive proposal. Also compare milestones, support terms, ownership, and delivery risk; a shorter schedule is a claim to test, not a benefit.
Planning a client portal or internal tool? Contact Articsledge to talk through your requirements.
A Step-by-Step Hiring Process
Allow several weeks. Rushing is how weak proposals win.
Write the one-page brief and confirm that custom development is justified.
Build a longlist of eight to twelve agencies from referrals, directories, and portfolios, treating reviews as a starting signal.
Run first calls with the ten screening questions and cut to three to five agencies.
Send the brief and request proposals, a named team, sample documents, and references.
Hold second-round interviews with the full question set, adding an independent technical reviewer if risk is high.
Consider paid discovery with one or two finalists to test the working relationship and sharpen scope.
Call references, score finalists, apply your gates, and normalize pricing.
Have counsel review the contract, confirm accounts and acceptance criteria, and plan kickoff with named owners on both sides.
Keep a decision log so you can explain the choice later; any project management software you already use will do.
When Articsledge May Be a Fit
Articsledge, the publisher of this guide, offers custom web application development for client portals, internal business applications, dashboards and reporting, API integrations, and workflow applications. Its service page describes a process that starts with a project assessment, defines scope (sometimes through a separately paid discovery phase), and moves through design, development, testing, deployment, and handover, with maintenance scoped separately.
Source code rights, intellectual property, hosting, and maintenance are set in each project agreement rather than assumed. Articsledge says it works remotely and also considers whether custom development is justified at all.
It is likely to suit a business with a defined problem, a realistic budget, and comfort collaborating remotely. A packaged tool, a specialist in your regulated sector, or a larger program team may suit other needs. Because Articsledge published this guide, put it through the same scorecard and ask it the same 42 questions.
A useful inquiry covers your problem, users, key workflows, systems to connect, rough budget, and timeline. Learn more about Articsledge or contact the team. Related reading: client portal versus shared drive, partner portal software, and self-service portal software.
To compare your options, explore Articsledge's development services and decide whether a project assessment is the right next step.
Frequently Asked Questions
What should I ask a software development agency first?
Start with the closest delivered project, who will work on yours, how discovery and estimates work, who owns the code and accounts, and what support follows launch. Those five questions test fit, people, process, ownership, and aftercare quickly. Ask for a document or example behind each answer.
How do I evaluate an agency without technical knowledge?
Ask for artifacts rather than explanations: a sample acceptance test, a plain-language architecture note, a status report, and a reference call. Compare how clearly each agency explains trade-offs. For sensitive or complex projects, pay an independent technical reviewer to read the proposal before you sign.
How many agencies should I interview?
Screen eight to twelve names, hold first calls with five or six, request proposals from three to five, and take one or two finalists into discovery and reference checks. Fewer than three proposals makes comparison thin; more than five adds effort without much better information.
What should a software development proposal include?
Look for scope and exclusions, assumptions, milestones, acceptance criteria, a named team, the pricing model and payment triggers, third-party costs, security and testing approach, support terms, intellectual property terms, and a handover plan. A proposal listing only features and a price leaves most risk with you.
What are common red flags when hiring a software agency?
Common ones are a fixed price before scoping, an unnamed team, unclear ownership of code or accounts, no testing or acceptance approach, unsupported security guarantees, large upfront payments, and no maintenance plan. Treat each as a prompt for follow-up, then decide whether the written answer is acceptable.
What should I ask about source code ownership?
Ask whether you receive an assignment or a license, when rights transfer, which pre-existing or open-source components are included, and who holds repository and hosting accounts. In the United States, commissioned work is not automatically made for hire, so get a written assignment reviewed by counsel in your jurisdiction.
How can I verify an agency's previous work?
Use a live or staging walkthrough, calls with two relevant references from the last two years, and, where confidentiality limits disclosure, a client-approved summary. Check the agency's actual role and which parts subcontractors built. Website testimonials alone are not verification.
Which pricing model is best?
No model wins universally. Fixed price suits clearly defined scope, time and materials suits evolving needs, and dedicated teams suit continuing product work. Many buyers start with paid discovery, then fix the price for a bounded first release. Choose by how certain your requirements are.
How do I compare expensive and inexpensive proposals?
Normalize them. Ask each agency to price the same scope and assumptions, list exclusions such as migration, testing, and handover, and add those back. Then compare staffing, milestones, support, and ownership terms. A low headline price can become the highest like-for-like cost.
What should I ask about cybersecurity?
Ask for the secure development process, access-control design, data protection, dependency scanning, testing approach, vulnerability remediation timelines, and incident notification terms. Use NIST's SSDF and OWASP's ASVS as vocabulary, request evidence, and do not accept guarantees of total security.
Should I hire an agency or freelancers?
A freelancer can suit a small, well-defined tool if you can direct the work and accept single-person risk. An agency offers more skills, QA, and continuity at higher cost. For client-facing or sensitive systems, team depth often matters more than the hourly rate.
How do I evaluate an offshore agency?
Judge people and process, not geography. Ask about overlap hours, written specifications, response times, data location, contract jurisdiction, and how handoffs avoid delays. Review-based sources such as Clutch show wide hourly-rate differences by country, so compare total cost and delivery evidence instead.
What happens if a project runs over budget?
It depends on the contract. Under fixed price, ask how scope changes are priced; under time and materials, ask for caps and weekly reporting. Require early warnings, a change-control process, and agreed options such as reducing scope. Decide the process before problems appear.
What support should I expect after launch?
Expect a defined warranty period for defects, then optional maintenance with response times by severity, security patching, and priced enhancements. Terms vary widely, so get coverage, hours, response times, and fees in writing, ideally before you sign the build contract.
When is custom software development worth paying for?
It is worth considering when a workflow is unique, client-facing, or heavily permissioned, or when packaged tools cannot connect the systems you rely on. If a configured product fits most needs, buying is usually faster. Compare options with a written brief and a three-year cost view.
Key Takeaways
Use the same ten first-call questions with every agency, then the full set of 42 for deeper diligence.
Every answer should come with something inspectable: a document, demo, test report, or reference.
Treat ownership, accounts, security, and acceptance as gates, not points to trade.
Compare proposals only after normalizing assumptions, exclusions, support, and handover, and price years two and three.
Standards such as NIST SSDF, OWASP ASVS, and WCAG 2.2 give you vocabulary, not proof of compliance.
Hold the repository, hosting, domain, and data admin accounts yourself from day one.
Use independent specialists and legal counsel for consequential security and contract decisions.
Actionable Next Steps
Write the one-page brief and name your decision maker.
Check whether buying, configuring, or integrating could solve the problem first.
Shortlist agencies and run the ten first-call questions with each.
Request proposals with a named team, assumptions, exclusions, and sample documents.
Use the 42 questions in second-round interviews, and record the evidence you receive.
Call references, score finalists, apply your gates, normalize pricing, and have counsel review the contract.
If your project is a client portal, internal tool, dashboard, integration, or workflow application, request an assessment from Articsledge and put the team through the same process.
Glossary
Acceptance criteria: testable conditions that decide whether a deliverable is done.
API: a defined way for one software system to talk to another.
Change request: a formal proposal to alter agreed scope, cost, or schedule.
Discovery: an early phase that clarifies the problem, requirements, and estimate.
Intellectual property (IP): legal rights in code, designs, and other creations.
MVP: the smallest release that tests an idea with real users.
QA: activities that check software quality before and after release.
SLA: an agreement stating service levels such as response times.
SOW: a statement of work listing deliverables, assumptions, and exclusions.
Technical debt: future rework created by shortcuts taken today.
Total cost of ownership (TCO): build and running costs over the life of the system.
UAT: user acceptance testing, where business users confirm the system works for them.
Vendor lock-in: dependence on one provider that makes switching costly.
Sources & References
Souppaya, M., Scarfone, K., and Dodson, D. (2022, February 3). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, NIST SP 800-218. National Institute of Standards and Technology.
OWASP Foundation. OWASP Application Security Verification Standard (ASVS), latest stable version 5.0.0. Project page, undated.
OWASP Foundation. OWASP Top 10:2025. 2025 edition, page undated.
W3C Accessibility Guidelines Working Group. (2024, December 12). Web Content Accessibility Guidelines (WCAG) 2.2. World Wide Web Consortium Recommendation.
U.S. Department of Commerce, in coordination with the National Telecommunications and Information Administration. (2021, July 12). The Minimum Elements For a Software Bill of Materials (SBOM). Report pursuant to Executive Order 14028.
U.S. Copyright Office. (Revised August 2024). Works Made for Hire, Circular 30. Library of Congress.
Schwaber, K., and Sutherland, J. (2020, November). The Scrum Guide. ScrumGuides.org.
Clutch. (Updated 2026, September 21). Software Development Company Pricing Guide 2026. Figures are drawn from client reviews and are not quotations.
European Parliament and Council of the European Union. (2016, April 27). Regulation (EU) 2016/679 (General Data Protection Regulation), Article 28. EUR-Lex.
Articsledge. Custom Web Application Development Services. Undated page, reviewed October 2026.
