A polished portfolio can help you shortlist providers, but it does not tell you how your project will run. Ask a candidate to walk through a similar technical problem, explain a trade-off, and show what you will receive at handoff.
Ask every shortlisted company to respond to the same brief and work through one representative scenario. You are testing judgment and transparency, not looking for a vendor that agrees with every requested feature or gives the fastest confident quote.
Related service: Custom Software Development- 01Write one consistent problem and workflow brief.
- 02Shortlist for relevant technical and domain constraints.
- 03Run a structured discovery and reasoning interview.
- 04Request a comparable scope, assumptions, and delivery model.
- 05Score quality, security, ownership, communication, and cost.
- 06Verify references or artifacts appropriate to the engagement.
- 07Contract around milestones, acceptance, change, and exit.
SECTION 01
Give every company the same evaluation brief
Describe the business problem, current workflow, primary users, systems involved, representative inputs and outputs, risk constraints, decision owner, and desired first outcome. Remove unnecessary solution prescriptions unless a technology is a real constraint. This lets teams show how they reason rather than repeat your feature list.
Ask the company to identify what it would need to learn before estimating, the smallest coherent release, its largest technical risks, and alternatives to custom development. A team that recommends configuration or a hybrid where appropriate is protecting the decision, not losing interest in the project.
SECTION 02
Score evidence across eight dimensions
Use a weighted score that reflects your project. A regulated data application may weight security and verification more heavily; a product discovery may weight product reasoning and user research. Record evidence and uncertainty beside each score so one charismatic presentation does not dominate the decision.
| Dimension | Evidence to look for | Warning sign |
|---|---|---|
| Problem understanding | Workflow map, assumptions, exceptions, outcome measures | Immediate feature and technology prescription |
| Scope discipline | Phases, exclusions, acceptance criteria, change rule | Everything is included in a fixed promise |
| Architecture | Tradeoffs tied to load, data, integrations, and ownership | Technology names without decision reasoning |
| Security | Threats, requirements, permissions, secret handling, verification | Security deferred until launch |
| Quality | Risk-based tests, representative data, release and rollback evidence | QA means only a final manual pass |
| Communication | Decision log, demos, risks, named owners, escalation path | Status is reported only as percent complete |
| Ownership | Buyer-controlled accounts, source access, documentation, exit plan | Vendor-held infrastructure without portability |
| Commercials | Assumptions, included roles, recurring costs, change terms | Low headline number with material exclusions hidden |
SECTION 03
Use one live scenario to test technical judgment
Choose a real difficult case: an integration sends duplicate events, two users edit a record, a payment succeeds but the callback fails, a role changes mid-process, or a data migration total does not reconcile. Ask how the team would discover, design, test, observe, and recover from it.
A credible answer distinguishes business rules from technical mechanisms, asks about consequence, and describes idempotency, audit, alerts, fallback, and user communication where relevant. It should surface choices rather than claim there is one universal architecture.
Discovery
What must be true, who decides, and what happens in the current process?
Design
Where is the source of truth and how are permissions and failures handled?
Verification
Which tests and production signals show the scenario works?
Recovery
How can the team retry, reverse, reconcile, or continue manually?
SECTION 04
Ask for verifiable security and quality requirements
NIST SSDF provides secure development practices that can be integrated into the lifecycle, and OWASP ASVS provides requirements that can be used during procurement and verification. You do not need to mandate every control blindly. Ask how the company tailors requirements to your data, threats, deployment, and consequence of failure.
Quality strategy should cover acceptance behavior, permissions, integration failures, data migration, accessibility where applicable, performance, browsers or devices, backup restoration, observability, and rollback. Ask which tests are automated, which remain manual, and what must be demonstrated before release.
SECTION 05
Normalize proposals before comparing price
List discovery, UX, product management, engineering, QA, infrastructure, security, project coordination, launch, documentation, warranty, support, and third-party services for each proposal. Note buyer responsibilities and assumptions. Only then compare the total investment and the confidence behind it.
Contract milestones should produce inspectable outcomes: an approved workflow, tested prototype, working vertical slice, migration rehearsal, or production-readiness review. Payment terms and methodology can vary, but acceptance and change decisions should be visible to both parties.
SECTION 06
Watch for certainty without discovery
Be cautious when a company promises an exact date and price from a short feature list, cannot explain testing beyond “our QA team handles it,” avoids account ownership questions, recommends a complex stack before learning constraints, or treats every requirement as equally urgent.
Also avoid turning procurement into unpaid speculative design across many companies. A focused paid discovery can be the right next step when uncertainty is real. Define its deliverables, ownership, time box, and how another team could use the results if you do not continue.
SECTION 07
Frequently asked questions
What should I look for in a custom software company?
Look for workflow understanding, scope discipline, relevant architecture reasoning, secure development, risk-based QA, transparent communication, buyer-controlled ownership, and commercial clarity.
How do I compare software development proposals?
Normalize scope, disciplines, assumptions, exclusions, agreed test results, recurring costs, ownership, support, and change terms. Then compare price and confidence on the same basis.
Should I ask for a fixed price?
A fixed price can fit a bounded, well-understood scope. If material uncertainty remains, a time-boxed discovery or phased estimate may be more honest. In either model, assumptions and change handling must be explicit.
Does the software company need to be located in the USA?
Location is one operating factor, not a quality guarantee. Evaluate communication overlap, legal terms, data access, security, delivery evidence, and ownership. A distributed team can serve U.S. businesses when those controls are clear.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Secure Software Development Framework (SSDF) Version 1.1National Institute of Standards and Technology
- Application Security Verification StandardOWASP Foundation
- Web Security Testing GuideOWASP Foundation
- Software Developers, Quality Assurance Analysts, and TestersU.S. Bureau of Labor Statistics
- SaaS Lens: General design principlesAmazon Web Services
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy