5 Questions to Ask Before Hiring a Software House

Hiring a software house is a big decision. You are trusting an outside team with your budget, your timeline, and often a core part of how your business runs. Yet many founders choose a vendor based on a polished pitch deck and the lowest quote, then discover the real problems three months in.

The good news: most of those problems are predictable, and you can surface them before you sign anything. Here are five questions worth asking every software house you talk to, along with what a good answer sounds like and which red flags should make you pause.

1. Have you built something similar, and can I talk to a past client?

Why it matters

A portfolio shows what a team can make. It does not always show how they behave when deadlines slip, requirements change, or something breaks in production. Relevant experience shortens the learning curve, and a conversation with a past client tells you what working together actually feels like.

"Similar" does not have to mean the same industry. An e-commerce checkout, a multi-tenant ERP, and a map-based marketplace all involve different problems. Ask for work that matches the shape of your project: a customer-facing app, an internal tool, an AI-driven feature, and so on.

A good answer

• They show live products you can actually open, not just mockups.
• They explain the problem, their role, and the trade-offs they made, honestly including what they would do differently.
• They offer to connect you with a past client, or explain clearly why a particular client is under NDA.

Red flags

• Only screenshots, with no live links and no detail on what the team actually built.
• Vague claims like "we have worked with hundreds of companies" with nothing to back them up.
• Reluctance to put you in touch with anyone, ever.

2. Who exactly will work on my project, and how will we communicate?

Why it matters

The people in the sales meeting are often not the people writing your code. Knowing who is on your team, and how much of their time you actually get, tells you a lot about quality and speed. Communication is the other half: most failed projects do not fail because of bad code, but because expectations drifted quietly for weeks.

A good answer

• A named point of contact (a project manager or lead developer) who owns your project day to day.
• A clear picture of the team: roles, seniority, and whether anyone is shared across other projects.
• A defined rhythm, such as weekly progress updates, regular demos of working software, and a shared channel for quick questions.
• Access to a staging environment so you can see progress yourself, not just hear about it.

Red flags

• "Our team will handle it" with no names or roles.
• Work quietly outsourced to a third party you never hear about.
• Updates only when you chase them, or long stretches with nothing to look at.

3. How do you handle scope changes and pricing?

Why it matters

Your requirements will change. You will learn things from early users, spot a better workflow, or realize a feature is less important than you thought. That is normal. What matters is whether the vendor has a fair, transparent way to handle it, or whether every change becomes a surprise invoice or a quiet cut in quality.

A good answer

• A written scope with clear deliverables, plus an explicit list of what is not included.
• A simple change-request process: you describe the change, they estimate the impact on cost and timeline, and nothing proceeds until you approve it.
• A pricing model that fits your situation, whether that is a fixed price for a well-defined scope or time-and-materials for something more exploratory, and an honest explanation of the trade-offs of each.
• Payment tied to milestones you can verify.

Red flags

• A quote that is dramatically lower than everyone else's, with no explanation.
• "We'll figure out the details later" on anything that affects cost.
• Large upfront payments before any working software exists.

A cheap quote with a vague scope is rarely cheap. It usually just moves the cost to later, when you have less leverage.

4. Who owns the code and IP, and where will it be hosted?

Why it matters

This is the question founders most often forget, and the one that hurts most when it goes wrong. If you do not own your source code, you cannot easily switch vendors, bring development in-house, or show your codebase to an investor during due diligence. Hosting matters too: if the servers sit in the vendor's account, they effectively control whether your product stays online.

A good answer

• The contract states plainly that you own the source code and intellectual property once the agreed payments are made.
• Code lives in a repository you have access to (or that is transferred to you), not only on the vendor's laptops.
• Hosting, domains, and third-party accounts are registered under your company, or there is a clear plan to hand them over.
• Reasonable documentation, so another developer could pick up the project if needed.

Red flags

• Ownership that is "to be discussed" or buried in fine print.
• A proprietary platform or framework that only that vendor can maintain.
• Refusal to give you repository or server access.

5. What happens after launch?

Why it matters

Launch day is not the finish line. Real users find bugs, operating systems update, security patches are released, and your business keeps evolving. A vendor who disappears the day after go-live leaves you with software you cannot safely change.

A good answer

• A warranty period after launch during which bugs in the delivered scope are fixed at no extra cost, with the length stated in the contract.
• A clear maintenance option for ongoing updates, monitoring, and small improvements.
• For business-critical systems, an SLA that defines response times and what counts as urgent.
• A proper handover: credentials, documentation, and a walkthrough for your team.

Red flags

• No mention of support until you ask, and then only vague promises.
• Every post-launch fix billed as a new project.
• No monitoring or backups in place at launch.

---

How CodeWorks answers these questions

We would rather you ask us these questions than not. Here is where we stand, briefly:

1. Portfolio: our work spans mobile apps, web platforms, a multi-tenant ERP, an e-commerce storefront, and AI-powered location intelligence, and many of these are live products you can open on our portfolio page. [CONFIRM: whether past clients are available as references, and how to request one]
2. Team and communication: [CONFIRM: who the client's main point of contact is, typical team composition, and update/demo cadence]
3. Scope and pricing: [CONFIRM: pricing models offered (fixed / time-and-materials), change-request process, and payment milestones]
4. Code ownership: [CONFIRM: IP/source code ownership terms and whether hosting and repositories are set up under the client's accounts]
5. After launch: [CONFIRM: warranty period length, maintenance packages, and SLA availability]

Whoever you end up working with, use these five questions. A good partner will welcome them.

If you are planning a project and want honest answers to any of these, get in touch with CodeWorks. We are happy to talk it through, with no obligation.