How to choose a software house: questions to ask before signing

Choosing the vendor affects a project more than choosing the technology. This guide covers what to check, what to ask in the first conversations and which signs should raise a red flag.

In short

  • Look for projects similar to yours - the scale and type of problem matter more than the industry.
  • Ask for references you can actually talk to, not just logos on a website.
  • Ask how often you will see working progress and who tests the software.
  • Check the contract for source code, copyright, warranty and how changes are billed.
  • Be wary of a quote without questions and a deadline promised before the scope is known.

Projects and references

A portfolio shows whether the company has built something similar. The similarity of the problem matters more than the industry: an app for field staff, an ERP integration, a system with many roles. A company that built a similar system in another industry often understands yours faster than one from your industry that mostly built websites.

Ask for contact with one or two clients. A short call tells you more than a presentation: were deadlines kept, how did communication work, what happened when something went wrong.

Questions for the first conversations

  1. What does the first stage look like - analysis, mock-ups, estimate?
  2. How often will I see working progress, not just a report?
  3. Who exactly will work on the project, and will the team stay the same?
  4. Who tests the software and when - along the way or only at the end?
  5. How do you bill scope changes during the project?
  6. Where will the source code live, and when does copyright pass to me?
  7. What does the warranty cover, and what is the response time for critical bugs?
  8. Who maintains the system after launch, and what does it cost?

Warning signs

  • A price given straight away, with no questions about scope, integrations and users.
  • A deadline promised before the project is understood.
  • No testing in the team, or "the client tests in production".
  • A vague answer about source code and copyright.
  • A single contact person, with no view of the team or the progress.
  • A very low rate for a large scope - it usually means something was left out.

What to look for in the contract

The contract should describe the scope or how it will be agreed, the schedule of stages and acceptances, the billing model, the handover of code and copyright (with defined fields of use), the warranty and bug response times, and how changes are requested and priced. Have a lawyer review it - this guide is not legal advice.

How 2Simple works

The first call takes 30 minutes and is an analysis, not a sales pitch. We show progress every 2-3 weeks, and when the interface is being built - a working demo. We bill the hours actually worked and hand over the source code, documentation and copyright at acceptance.

Frequently asked questions

How many offers should I collect?

Usually three to five. More offers mean more work comparing them and less time to talk to each vendor.

Is a large or a small company better?

A large company has more resources; a small one usually gives a single client more attention and direct contact with the people writing the code. What matters more than size is whether the company has done similar projects and who exactly will work on yours.

Is it worth starting with a small paid stage?

Yes. An analysis or a prototype is a good test of the cooperation: you see how the company works before signing for the whole project.

Related

Let's talk about your project

Describe in a few sentences what you want to build or improve: an app, a platform, an integration or a process. We reply within one business day. The first call is an analysis, not a sales pitch.

Write to us or email office@2simple.it