Choosing a software development company is not simply a matter of comparing prices.

A development company is responsible for turning a business idea or requirement into a working software system. That means the company you choose can influence the product architecture, development cost, security, delivery timeline, maintainability and long-term ownership of the software.

Two development companies can receive exactly the same project brief and produce very different results.

One may identify hidden technical risks before development starts.

Another may start coding immediately.

One may challenge an unrealistic requirement.

Another may agree to everything to win the project.

One may document scope carefully.

Another may leave important details open to interpretation.

The difference usually becomes visible later, when changes become expensive.

That is why a business should evaluate a software development company before signing a contract or starting development.

The right questions are not only:

"How much will it cost?"

and:

"How quickly can you build it?"

Those questions matter, but they are only part of the decision.

A better evaluation asks:

Does this company understand our business problem?

Can it explain the technical approach clearly?

Can it identify risks before development begins?

Does it have a disciplined delivery process?

Who will actually work on the project?

Who owns the code and infrastructure?

How are security and quality handled?

What happens when requirements change?

What happens after launch?

This guide provides a practical framework for evaluating a software development company before hiring one.

This is the ninth guide in our pre-development documentation series. Where our previous guide covered what you should bring to a development company, this one covers how to evaluate the company itself — alongside the rest of the series: the documentation checklist, technical documentation, the architecture document, the requirement document, the scope document, requirements vs scope vs specifications vs SOW, and acceptance criteria.

---

Quick Answer: What Should You Ask a Software Development Company Before Hiring Them?

At minimum, ask questions across these areas:

Area	Questions to Ask
Business Understanding	Do you understand the problem we are trying to solve?
Experience	Have you built systems with similar complexity?
Team	Who will actually work on the project?
Process	What happens between discovery and development?
Requirements	How do you turn our idea into documented requirements?
Scope	How do you define what is included and excluded?
Architecture	Who designs the technical architecture?
Technology	Why are you recommending this technology stack?
Security	How are security requirements handled?
Testing	How do you test the software before release?
Integrations	How do you handle third-party systems and APIs?
Project Management	How will progress and issues be communicated?
Changes	What happens when requirements change?
Ownership	Who owns source code, infrastructure and accounts?
Deployment	Who deploys and operates the software?
Documentation	What documentation will be delivered?
Support	What happens after launch?
Commercials	What exactly is included in the price?
Risks	What risks do you see in our project?
References	Can you demonstrate relevant previous work?

The quality of the answers matters more than the number of questions asked.

A good development company should be comfortable discussing difficult questions rather than trying to avoid them.

---

1. Do You Understand What Problem We Are Trying to Solve?

This should be one of the first questions.

You are not hiring a development company simply to write code.

You are hiring a company to solve a business or product problem using software.

A strong company should be able to explain your problem back to you in its own words.

For example:

"Your primary issue is that customers currently rely on manual processing, which creates delays and requires unnecessary staff involvement. The first version should therefore focus on automating the customer submission and internal approval workflow."

That demonstrates understanding.

A weaker response is:

"Yes, we understand. We'll build the platform."

The difference matters.

If a company cannot explain why the software is needed, it may not fully understand what it is building.

---

2. Have You Built Something With Similar Complexity?

This does not necessarily mean you should ask:

"Have you built exactly the same application?"

Exact industry experience can be useful, but technical complexity is often more important.

For example, a company building:

• Multi-tenant SaaS
• Payment systems
• Enterprise integrations
• AI applications
• Real-time platforms
• Complex workflows

should have experience with the corresponding technical challenges.

Ask:

• What similar systems have you built?
• What was the scale?
• What were the difficult parts?
• What would you do differently now?
• Can you demonstrate the relevant work?

A company should be able to explain what it actually did rather than simply display a list of logos.

---

3. Who Will Actually Work on My Project?

This is one of the most important questions.

The people involved during sales discussions are not necessarily the people who will develop the software.

Ask:

• Who is the project manager?
• Who is the technical lead?
• Who is responsible for architecture?
• Who will write the code?
• Who handles QA?
• Who handles deployment?
• Who is the main technical contact?

Also ask:

Are these people already assigned to the project?

A strong answer gives you visibility into the actual team.

---

4. How Do You Turn Our Idea Into a Technical Plan?

A good development company should have a process between:

"We have an idea."

and:

"Developers are writing code."

Ask what happens during this stage.

A mature process may involve:

Discovery

↓

Requirements

↓

Scope

↓

Technical planning

↓

Architecture

↓

UX/UI

↓

Estimation

↓

Development

The exact process differs from company to company.

The important thing is that the company should have a clear way of turning ambiguity into a buildable project.

---

5. Will You Help Define the Requirements?

A business may know what it wants to achieve without knowing how to document every software requirement.

Ask:

"Do you help us turn our business requirements into formal product and technical requirements?"

This is especially important for non-technical founders.

A strong development partner should be able to ask questions such as:

• Who are the users?
• What happens today?
• What should change?
• What are the business rules?
• What are the edge cases?
• What is required for the MVP?
• What should be postponed?

A company that simply takes a vague feature list and immediately starts coding may be creating unnecessary risk.

---

6. How Do You Define Project Scope?

Ask:

"How do you determine what is included in the project and what is not?"

A good scope process should identify:

• Included features
• Excluded features
• Platforms
• Integrations
• Deliverables
• Client responsibilities
• Development responsibilities
• Dependencies
• Assumptions
• Milestones

The scope should be documented.

Do not rely on:

"We discussed it during the call."

Important commitments should exist in writing.

---

7. What Happens When We Request a New Feature?

This question reveals a lot about project maturity.

You want to know whether the company has a clear change process.

Ask:

"If we add a feature after development starts, how do you assess the impact?"

A professional process should consider:

• Technical impact
• Design impact
• Testing impact
• Timeline
• Cost
• Architecture
• Dependencies

The company should not simply say:

"Sure, we'll add it."

That may sound helpful during sales.

It becomes a problem when the project has to absorb unlimited new work without changing the schedule or budget.

---

8. Who Designs the Software Architecture?

Architecture should not be left to whichever developer happens to start first.

Ask:

"Who is responsible for the architecture?"

Then ask:

"Can you explain why you are recommending this architecture?"

The answer should connect architectural decisions to requirements.

For example:

"We're choosing this architecture because the first release has a limited user base, but the system needs a path to independent scaling for the data processing component."

That is a reasoned answer.

A weak answer is:

"This is the architecture we normally use."

The fact that a company uses an architecture frequently does not automatically make it appropriate for your project.

---

9. Why Are You Recommending This Technology Stack?

Technology selection should have a reason.

Ask:

"Why this framework?"

"Why this database?"

"Why this infrastructure?"

"Why this architecture?"

A good answer should consider:

• Project requirements
• Team expertise
• Performance
• Security
• Maintainability
• Integration requirements
• Expected growth
• Cost
• Existing systems

Be cautious when technology is selected mainly because:

"Everyone is using it."

Popularity is not a sufficient architecture strategy.

---

10. What Are the Major Technical Risks You See?

This may be the most revealing question in the entire conversation.

Ask:

"What concerns you about this project?"

A good development company should identify risks.

Examples:

• Complex legacy integration
• Unclear data quality
• Third-party API limitations
• Migration complexity
• Security requirements
• Performance expectations
• Uncertain AI behaviour
• Tight timeline
• Unclear business rules

A company that says:

"There are no risks."

is not necessarily giving you confidence.

Every meaningful software project contains uncertainty.

A competent team should be able to identify it.

---

11. What Assumptions Are You Making?

Ask the company to list its assumptions.

For example:

• Client will provide API credentials.
• Existing customer data can be exported.
• A third-party provider supports the required workflow.
• Final designs will be available by a certain stage.
• Client approvals will be provided within an agreed timeframe.

This is important because an estimate built on incorrect assumptions can quickly become inaccurate.

---

12. What Is Included in the Estimate?

Never evaluate a software proposal only by the final number.

Ask:

"Exactly what does this estimate include?"

Look for:

• Discovery
• Design
• Development
• Backend
• Frontend
• APIs
• Integrations
• Testing
• Deployment
• Documentation
• Project management
• Post-launch support

Two proposals can have similar prices while containing very different levels of work.

---

13. Is the Estimate Fixed or Based on Assumptions?

Ask:

"What does this estimate depend on?"

A company should explain whether the estimate is:

• Fixed
• Time and materials
• Range-based
• Milestone-based
• Based on an initial discovery phase

There is nothing inherently wrong with a variable estimate.

Software projects contain uncertainty.

The important thing is understanding what causes the estimate to change.

---

14. What Happens If the Project Takes Longer Than Estimated?

This question should be answered before the project starts.

Ask:

"What happens when the actual effort exceeds the original estimate?"

The answer should explain:

• Why the overrun occurred
• Who is responsible
• How additional work is approved
• How costs are handled
• How the timeline changes

A transparent company should be comfortable discussing overruns before they happen.

---

15. How Do You Manage Requirements?

Ask:

"Where are requirements documented and how are changes tracked?"

You want to know whether the company has a clear process for:

• Requirements
• Approvals
• Priorities
• Changes
• Acceptance criteria

A project where requirements live entirely in chat messages is difficult to manage.

---

16. How Do You Track Project Progress?

Ask what you will see during development.

A useful project should have some visibility into:

• Completed work
• Current work
• Upcoming work
• Blockers
• Risks
• Milestones
• Defects

You do not necessarily need to control the team's internal workflow.

But you should have enough visibility to understand whether the project is moving according to plan.

---

17. How Often Will We Review the Product?

Software should not be developed in complete isolation for months and then revealed at the end.

Ask:

"How frequently will we see working software?"

Frequent review helps identify misunderstandings earlier.

A practical process may include:

Requirement approval

↓

Design review

↓

Development iteration

↓

Working software demonstration

↓

Feedback

↓

Testing

↓

Acceptance

The exact cadence depends on the project.

The principle is simple:

Feedback should happen before problems become expensive.

---

18. What Is Your Testing Process?

Ask:

"How do you test the software before asking us to accept it?"

A strong answer should cover more than:

"The developers test it."

Ask about:

• Functional testing
• API testing
• Integration testing
• Regression testing
• Browser testing
• Mobile testing
• Performance testing
• Security testing
• User acceptance

Not every project requires every type of testing.

The company should nevertheless be able to explain what testing is appropriate for your project.

---

19. Who Performs QA?

Ask whether testing is:

• Developer-only
• Performed by dedicated QA engineers
• Automated
• Manual
• A combination

The team structure matters.

Developers testing their own code is useful, but independent QA can identify issues that the original implementer may overlook.

---

20. What Are Your Acceptance Criteria?

Ask:

"How will we determine that a feature is finished?"

A mature development company should use defined acceptance criteria.

That means a feature should have measurable conditions such as:

• Expected behaviour
• Validation
• Error handling
• Permissions
• Integration behaviour
• Performance expectations

This is far better than:

"We'll know when it looks finished."

---

21. How Do You Handle Security?

Ask:

"How is security considered during development?"

Depending on the project, discuss:

• Authentication
• Authorization
• Data protection
• Secrets
• API security
• Access controls
• Logging
• Infrastructure
• Backups
• Security testing

A strong company should be able to explain security in practical terms.

Be cautious of vague statements such as:

"Security is taken care of."

Ask what that actually means.

---

22. How Do You Handle Sensitive Data?

If the system processes sensitive information, ask:

• Where is the data stored?
• Who can access it?
• How is access controlled?
• How is it protected?
• How is it backed up?
• How is it removed?
• What gets logged?

The answer should be connected to the actual system requirements.

---

23. How Do You Handle Third-Party Integrations?

Ask:

"What happens if an external API fails?"

A mature answer should address:

• Timeouts
• Retries
• Error handling
• Logging
• Recovery
• Duplicate requests
• Partial failures

An integration is not complete simply because the success case works.

---

24. How Do You Handle Data Migration?

If an existing system is involved, ask:

"How will you evaluate and migrate our existing data?"

The team should discuss:

• Data quality
• Mapping
• Validation
• Transformation
• Migration testing
• Historical records
• Rollback or recovery

Do not assume:

"Export and import."

is the full migration strategy.

---

25. What Happens During Deployment?

Ask:

"How does the application move from development to production?"

The company should be able to explain:

• Environments
• Build process
• Testing
• Deployment
• Database migrations
• Configuration
• Rollback
• Monitoring

Production deployment should be a planned process, not an improvisation.

---

26. Who Owns the Infrastructure?

This is an extremely important question.

Ask:

"Will the production infrastructure be in our accounts or yours?"

Where practical, clients should understand who controls:

• Cloud account
• Domain
• DNS
• Database
• Storage
• Source control
• Third-party services

A development company managing infrastructure is not automatically a problem.

The problem is unclear ownership and lack of access.

---

27. Who Owns the Source Code?

Ask directly:

"Who owns the source code after the project is completed?"

Do not leave this ambiguous.

Also clarify:

• Repository ownership
• Access rights
• Intellectual property
• Third-party components
• Open-source dependencies
• Documentation
• Deployment configuration

The contract should reflect the agreed ownership model.

---

28. Will We Have Direct Access to the Code Repository?

Ask:

"Will the client have access to the source repository?"

Also establish:

• Who owns the repository
• Who has administrator access
• How access is handled after project completion
• Whether development happens in the client's environment or the agency's

This affects long-term independence.

---

29. What Documentation Will You Deliver?

Ask for a specific list.

Possible deliverables include:

• Architecture documentation
• API documentation
• Deployment documentation
• Environment documentation
• Administrator documentation
• User documentation
• Database documentation
• Handover documentation

Do not accept:

"We'll provide documentation."

Ask:

"Which documentation is included?"

---

30. What Does Handover Include?

A proper handover may include:

• Source code
• Repository access
• Infrastructure access
• Domain access
• Third-party accounts
• Deployment instructions
• Environment variables
• Architecture documentation
• API documentation
• Database information
• Monitoring
• Backup procedures

Ask:

"What exactly will we receive when the project is handed over?"

---

31. What Happens After Launch?

Launching the application is not necessarily the end of the engagement.

Ask:

• Is bug fixing included?
• For how long?
• Is maintenance available?
• Who monitors production?
• Who handles incidents?
• How are enhancement requests priced?
• Is ongoing development available?

The post-launch model should be clear before development starts.

---

32. What Is Included in Post-Launch Support?

Ask specifically what support covers.

There is a significant difference between:

Bug fixing for delivered functionality

and:

Ongoing development and feature enhancement.

The first may be covered under a defined support period.

The second is generally additional development work.

The distinction should be clear.

---

33. What Happens if We Want to Change Development Companies?

This is an uncomfortable question.

Ask it anyway.

"If we eventually move the project to another development team, can we take the software with us?"

The answer should cover:

• Source code
• Documentation
• Infrastructure
• Databases
• Credentials
• Third-party accounts
• Build and deployment process

A healthy engagement should not depend on artificial lock-in.

---

34. Can You Show Us the Actual Team's Experience?

Ask to understand the people who will actually work on the project.

The company may have an impressive portfolio.

The relevant question is:

Who is doing this work?

Ask about:

• Technical lead
• Developers
• QA
• Designer
• DevOps
• Product or project manager

Experience should relate to the complexity of your project.

---

35. Can We Speak to Previous Clients?

Relevant references can be valuable.

Instead of asking only:

"Are your clients happy?"

Ask more useful questions:

• Was the project delivered as expected?
• How was communication?
• Were estimates reliable?
• How did the team handle changes?
• How was post-launch support?
• Did you retain ownership and access?

The objective is to understand how the company behaves during a real project.

---

36. What Happens When Something Goes Wrong?

No serious software project goes perfectly.

Ask:

"Tell us about a project where something went wrong and how your team handled it."

This can reveal much more than a polished case study.

A mature company should be able to discuss:

• Technical failures
• Delayed dependencies
• Scope changes
• Unexpected complexity
• Production issues

and explain how the team responded.

---

37. What Happens When You Disagree With the Client?

This is another useful question.

A development team should not agree with every client request automatically.

Sometimes the technically correct answer is:

"We don't recommend doing that because it creates a security or scalability problem."

A good development partner should be willing to challenge decisions professionally and explain why.

You are not paying a technical team merely to say yes.

You are paying for technical judgment.

---

38. How Do You Handle Technical Debt?

Ask:

"How do you manage technical debt during the project?"

A strong team should acknowledge that trade-offs sometimes have to be made.

The important thing is whether those trade-offs are:

• Identified
• Documented
• Prioritized
• Addressed deliberately

Technical debt becomes dangerous when the team does not know it exists.

---

39. How Do You Handle Documentation Changes?

Ask:

"When architecture or requirements change, how do you keep the documentation aligned?"

A good process may update:

• Requirements
• Scope
• Specifications
• Architecture
• Acceptance criteria
• Deployment documentation

Outdated documentation creates unnecessary risk.

---

40. What Do You Need From Us to Keep the Project on Track?

This question is often overlooked.

A good development partner should clearly tell you what the client needs to provide.

Examples:

• Timely approvals
• API credentials
• Business decisions
• Content
• Designs
• Data
• Test users
• Third-party accounts

This helps prevent delays that neither side anticipated.

---

Red Flags to Watch For

Certain answers should make you investigate further.

"We can build anything."

This usually tells you very little.

A competent team should be willing to discuss constraints.

"Everything is included."

Ask for the exact scope.

"We don't need documentation."

That may be appropriate for a tiny prototype.

It is a concern for a serious production system.

"We'll decide the architecture later."

Architecture can evolve, but important technical decisions should not be postponed without reason.

"Don't worry about the details."

Details matter when they affect cost, security, scope or delivery.

"Our team works internally, so you don't need repository access."

That may create unnecessary dependence.

"We'll give you the code at the end."

Ask who owns the repository and infrastructure from the beginning.

"Testing is included."

Ask what testing means.

"Security is part of everything we do."

Ask what specific controls and processes apply to your project.

"We'll figure it out during development."

Some discovery should happen during development.

Major unknowns should not be used as a substitute for planning.

---

Green Flags in a Development Company

Good signs include a company that:

Asks difficult questions

They want to understand the business rather than simply sell the project.

Identifies risks

They tell you what may be difficult.

Challenges unrealistic assumptions

They explain why a proposed approach may be problematic.

Separates scope from future ideas

They help prioritize.

Explains technical choices

They can defend architectural decisions in plain language.

Documents requirements

Important decisions do not live only in conversations.

Defines acceptance criteria

Completion has a clear meaning.

Talks about ownership early

Code and infrastructure ownership are not treated as an afterthought.

Discusses failure scenarios

They think beyond the happy path.

Has a clear handover process

They understand what happens after development ends.

---

A Practical Vendor Evaluation Framework

Before choosing a development company, evaluate it across several categories.

1. Business Understanding

Can they understand your problem?

2. Technical Capability

Can they solve the technical problems your product actually has?

3. Architecture

Can they explain how the system should be designed?

4. Delivery Process

Do they have a predictable way to move from requirements to production?

5. Quality

Do they have a meaningful testing and QA process?

6. Security

Can they explain how your system and data will be protected?

7. Communication

Will you have enough visibility and access to make decisions?

8. Ownership

Will you retain appropriate control over the software and infrastructure?

9. Commercial Clarity

Can they explain what is included and what creates additional cost?

10. Post-Launch Support

What happens after the software goes live?

Price should be evaluated alongside these factors.

Not instead of them.

---

How to Compare Two Software Development Proposals

Suppose Company A quotes:

$50,000

Company B quotes:

$70,000

It is tempting to choose Company A.

That can be a mistake.

Before comparing the numbers, compare:

• Scope
• Features
• Architecture
• Team
• QA
• Security
• Integrations
• Documentation
• Deployment
• Support
• Ownership
• Timeline
• Change process

You may discover that the cheaper proposal excludes several items that the more expensive proposal includes.

A lower price is not necessarily a lower total cost.

---

Questions to Ask About the Proposal Itself

Before accepting a proposal, ask:

• Is the scope documented?
• Are exclusions documented?
• Are assumptions documented?
• Are milestones defined?
• Are deliverables defined?
• Are payment conditions clear?
• Is change management explained?
• Are client responsibilities documented?
• Are support terms clear?
• Is ownership clear?
• Is handover defined?

If the proposal is vague, ask the company to make it specific before signing.

---

The Ortem Software Development Partner Test

At Ortem Technologies, we believe a development partner should pass five basic tests before a client trusts them with a serious software project.

1. Understanding

Can they explain your business problem accurately?

2. Thinking

Can they identify risks, assumptions and trade-offs?

3. Building

Can they explain how the solution will actually be developed?

4. Ownership

Will you retain appropriate control over the software, data and infrastructure?

5. Accountability

Can they explain how they measure delivery, quality and completion?

If a company can answer these questions clearly, the conversation is usually much more productive.

---

The 20 Questions We Recommend Asking

When evaluating a software development company, ask these questions directly:

1. What do you understand our business problem to be?
2. What assumptions are you making about the project?
3. What risks do you see?
4. What would you change about our initial idea?
5. How will you define the requirements?
6. How will you define and control project scope?
7. Who will actually work on our project?
8. Who is responsible for architecture?
9. Why are you recommending this technology stack?
10. How will the software be tested?
11. How will security be handled?
12. How will external integrations be handled?
13. How will changes affect timeline and cost?
14. What exactly is included in the estimate?
15. What exactly is excluded?
16. Who owns the source code and infrastructure?
17. What documentation will we receive?
18. What happens during handover?
19. What support is available after launch?
20. What happens if we eventually move the project to another development team?

The answers to these questions will tell you considerably more about a company than a sales presentation alone.

---

What You Should Expect From the First Serious Conversation

A good development discussion should not feel like:

"Tell us your idea and we'll give you a price."

It should feel more like:

"Let's understand the business problem, users, workflow, constraints, technical dependencies and desired outcome. Then we can determine what needs to be built, what architecture makes sense and how the project should be planned."

That difference matters.

The first conversation should reduce uncertainty.

It should not simply produce a quotation.

---

You Are Hiring a Technology Partner, Not Just Developers

Developers write code.

A technology partner does more.

A strong development company should help you:

• Clarify requirements
• Identify technical risks
• Define architecture
• Prioritize features
• Control scope
• Build the software
• Test the software
• Deploy it
• Document it
• Hand it over
• Maintain it when required

This is especially important when the client does not have an internal technical team.

The development company may effectively become the client's technical team for the duration of the project.

That makes the quality of the partnership much more important than the hourly rate alone.

---

Final Takeaway

Choosing a software development company is a technical, commercial and strategic decision.

Before hiring a development team, you should understand:

Whether they understand your business problem.

Whether they have relevant technical experience.

Who will actually work on your project.

How they define requirements and scope.

Who is responsible for architecture.

Why they are recommending their technology choices.

How they identify and manage risks.

How they handle testing and security.

How they manage third-party integrations.

What happens when requirements change.

What is included in the estimate.

What is excluded.

Who owns the source code and infrastructure.

What documentation you will receive.

How handover works.

What happens after launch.

What happens if the relationship ends.

The cheapest development company is not necessarily the best choice.

The most expensive company is not necessarily the best choice either.

The better question is:

Which development company gives us the clearest path from our business problem to a working, maintainable and properly owned software product?

Look for a company that asks difficult questions.

Look for a company that challenges weak assumptions.

Look for a company that documents decisions.

Look for a company that explains technical choices rather than hiding behind jargon.

Look for a company that is comfortable discussing failure, risk, scope and ownership before you sign the contract.

Most importantly, look for a company that understands that its responsibility is not simply to write code.

It is to help turn a business requirement into software that can actually be built, tested, launched, operated and maintained.

At Ortem Technologies, we believe the right software development relationship starts with a conversation about the problem, not a conversation about the price.

Because when the problem is understood properly, the technology becomes easier to design.

And when the technology is designed properly, the project has a much better chance of succeeding.

Once you have proposals in hand from asking these questions, the next step is comparing them properly — see how to compare two software development proposals.

Want to see how we would answer these twenty questions for your actual project? That is exactly what our custom software development discovery call is for.

Ask us these questions directly →