Hiring a software house is a big decision. You are trusting a team with money, time and often a core part of your business. Most problems on software projects do not start in the code. They start in the first few conversations, when expectations are vague and nobody writes things down.
These ten questions work with any agency, including ours. Ask them early. Listen for clear, specific answers. A good team will be glad you asked.
Can I see similar work and talk to the people who built it?
A portfolio shows what a team has shipped. It does not show how they got there. Ask for projects close to yours in size and type, then ask to speak with someone who worked on them.
A good answer points you to real, live projects and explains what the team did on each one. If you want a starting point, our portfolio lists the projects we can walk you through.
Be careful if every example is a mockup, or if the agency cannot say which parts they built.
Who exactly will work on my project?
Many agencies sell with senior people and deliver with whoever is free. You want to know who your project manager is, who writes the code and who designs the screens.
A good answer names roles, and ideally people. It also tells you what happens if someone leaves halfway through. Ask whether any work is passed to subcontractors.
How do you estimate, and what is in and out of scope?
An estimate is only as good as the scope behind it. Ask how the team breaks the work down and what assumptions they made.
A good answer comes with a written scope that lists features, platforms and integrations. It also lists what is not included. That second list matters as much as the first, because it is where most disputes come from later.
How will we communicate and how often will I see progress?
Silence for six weeks followed by a big reveal is a warning sign. You should see working software regularly, not only status reports.
A good answer includes:
- one named point of contact
- a fixed rhythm for updates, such as weekly
- demos of working features at set points
- a shared place to track tasks and decisions
How do you handle changes mid-project?
Your needs will change once you see the product taking shape. That is normal. What matters is how changes are priced and approved.
A good answer describes a simple process: you request a change, the team estimates its effect on cost and timeline, and nothing starts until you agree. Ask how small changes are handled too, so they do not pile up unnoticed.
Who owns the code, designs and accounts?
This question gets skipped more than any other, and it causes the most pain later. You should own what you paid for.
A good answer confirms in writing that the source code, design files and content belong to you once paid. Domains, hosting, app store accounts and analytics should be registered in your name, with the agency given access, not the other way around.
How do you test before launch?
Ask what gets tested, by whom and on what. "We test everything" is not an answer.
A good answer covers testing on real phones and browsers, not only on a developer's laptop. It mentions a staging version you can review before anything goes live, and a clear way to report bugs during that review.
What happens after launch?
Software needs care after release. Operating systems update, libraries age and users find bugs nobody expected.
A good answer explains what support is included and for how long. It also covers ongoing maintenance options and how fast the team responds to an urgent issue versus a minor one. If you want to edit text and images yourself, ask whether a content management system is part of the build.
How do you handle security and my data?
Even a small app may store customer details, passwords or payment information. You need to know the team takes this seriously.
A good answer covers how passwords and personal data are stored, who has access to your servers, how access is removed when someone leaves the project and how backups work. The team should also be willing to sign a confidentiality agreement if you need one.
What does payment look like?
Payment terms tell you a lot about how a team works. Large upfront payments with vague deliverables put all the risk on you.
A good answer ties payments to milestones, such as approved designs, a working first version or launch. Each milestone should have a clear, checkable outcome. Our FAQ explains how we structure this, if you want an example to compare against.
Red flags to watch for
Pay attention to how the agency answers, not only what they say. Be cautious if you hear:
- a fixed price before anyone has asked about your requirements
- no written scope, or a scope that only lists features without exclusions
- reluctance to put code and account ownership in the contract
- no plan for testing on real devices
- vague answers about who will do the work
A good software house will answer these questions without hesitation, because it already works this way. If you are planning a custom software project, take these questions to every agency on your shortlist and compare the answers side by side.