How to choose the right development partner — 7 questions you should ask

The most important questions to ask a development partner are about process, code ownership, quality practices, team composition, and long-term support. Here are seven concrete questions — with green and red flags for each answer.

There are thousands of software companies in Norway. Prices vary by a factor of five. Everyone promises "quality," "agile development," and "modern technology." How do you tell the ones who actually deliver from those who just sell hours?

In this article, we share seven questions you should ask potential development partners — and what the answers should tell you.

Why partner selection is critical

According to the Standish Group's CHAOS Report 2024, 66% of all IT projects fail — either by exceeding budget, delivering late, or not meeting the actual needs. The most common cause isn't technology, but communication and misunderstanding of requirements.

A good development partner dramatically reduces the risk of project failure. A bad partner can cost you hundreds of thousands in wasted development, plus the delay of starting over with someone else.

Question 1: How do you start a new project?

What you should hear: That they start by understanding the business problem — not the technology. A good partner spends time mapping processes, users, and goals before proposing a solution.

Red flag: If they jump straight to technology choices, estimates, or wireframes in the first meeting without understanding the problem, it's a sign they'll build what they know, not what you need.

At UNOS SOFTWARE AS, we always start with business analysis. When we built Splice, we spent weeks at driving schools before writing a single line of code. That investment in domain understanding was decisive for the product's success.

Question 2: Who owns the code?

What you should hear: "You own everything we build." Without exceptions.

Red flag: Some consultancies retain ownership of parts of the code — typically "frameworks" or "platform components" they reuse across clients. This creates dependency and makes it difficult to switch partners.

Code ownership checklist

Question	Expected answer
Do we own all source code?	Yes, unconditionally
Do we get access to the Git repository?	Yes, continuously during the project
Is the code based on open source?	Yes, no proprietary frameworks
Can we take the code to another vendor?	Yes, without restrictions

We always build on open standards — TypeScript, Next.js, Azure — precisely to ensure our clients are never locked in to us. Read more about our technology stack.

Question 3: How do you handle changes along the way?

What you should hear: That they expect changes and have a structured process for handling them. Iterative development with close feedback means course corrections happen along the way.

Red flag: "We deliver what's in the contract." This rigid approach means you need to know everything upfront — which is unrealistic for software projects.

Also a red flag: "We take everything as it comes, no problem." Boundless flexibility without consequences means scope is never controlled, and the budget blows out.

The healthy middle ground is clear milestones with room for adjustments within an agreed framework.

Question 4: Can I talk to the developers directly?

What you should hear: "Yes, absolutely." In a good partnership, you have direct contact with the people building your product.

Red flag: If all communication goes through a project manager who "translates" between you and the developers, you lose nuance and misunderstandings arise. This is especially common at larger consultancies where the project manager sells one thing and the developers deliver another.

Question 5: What happens after launch?

What you should hear: A clear plan for operations, maintenance, and further development. Launch isn't the end — it's the beginning.

Red flag: If the partner only focuses on "the project" and has no offering for what comes after, you're left with a solution nobody maintains.

What a maintenance agreement should cover

• Security updates and dependency maintenance
• Bug fixes and support
• Monitoring and alerts
• Agreed response time for critical issues
• Option for further development

We offer maintenance agreements for all projects we deliver, focused on keeping the solution secure and up to date over time. Read more about our approach to cloud and infrastructure.

Question 6: How do you ensure quality?

What you should hear: Concrete practices — automated tests, code reviews, CI/CD pipeline, staging environment. Not just "we focus on quality."

Red flag: Absence of automated testing, or statements like "we test manually at the end." Manual testing at the end of a project is too late and too expensive.

Quality indicators

Practice	What it means
Automated tests	Bugs are caught early, regressions are prevented
CI/CD pipeline	Code is tested and deployed automatically
Code review	More than one person sees the code
Staging environment	You can test before it goes to production
TypeScript strict mode	Type errors are caught by the compiler

Question 7: Can you show similar projects?

What you should hear: Concrete examples with details about challenges, solutions, and results. Even better if you can contact references directly.

Red flag: Vague descriptions without details, or just "we've worked with large companies." Size says nothing about quality.

What you should ask references

• Did they keep the budget?
• Were they delivered on time?
• How was communication during the project?
• Would you use them again?
• What would you do differently?

Our approach

At UNOS SOFTWARE AS, we don't build software for the sake of building software. We start with the business problem, choose technology that fits the problem, and deliver solutions our clients own completely.

We offer the full spectrum of consulting services — from technical advisory and architecture reviews to full-stack software development and system integration.

Want to discuss a project? Get in touch for a free consultation. We're happy to answer all seven questions.

---

Sources and further reading

• Standish Group (2024). "CHAOS Report 2024: Decision Latency Theory." standishgroup.com
• Cohn, M. (2009). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley.
• McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press.
• Anskaffelser.no (2025). "Guide for procurement of IT consulting services." anskaffelser.no
• ICT Norway (2025). "Industry statistics for Norwegian IT sector." ikt-norge.no