The partner you choose will shape your project more than the technology, the framework or even the budget. A strong team can rescue an unclear brief. A weak one can waste a perfect brief, and the damage usually appears months after the contract is signed, when changing course is expensive.
The difficulty is that every company looks good in a proposal. Portfolios are polished, sales calls are smooth and every vendor claims experience in whatever you need. This guide gives you a way to see past the presentation: what to evaluate, the questions that reveal how a team really works, the warning signs, and a low-risk way to test a partnership before committing fully.
Start with your own side of the table
Before you contact anyone, get clear on what you need. Vendors can only be compared against a yardstick, and the yardstick is your own brief.
Write down, even roughly:
- The problem. What is going wrong today, and what should be different once the software exists?
- The users. Who will use it, and what must they be able to do?
- The constraints. Budget range, target dates and any systems it must work with.
- The unknowns. Which questions do you need help answering?
It does not need to be a formal specification. If you would like a structure, our guide to writing a software requirements document walks through one. A clear brief also improves the quality of the estimates you receive, because vendors are pricing the same thing.
What to evaluate
1. Relevant experience, not just impressive logos
A company that has built something similar to your project will understand its pitfalls. Ask for examples close to your problem, and ask what went wrong as well as what went well. Teams that have shipped real products have stories about difficulty; teams that only have successes to report are usually polishing.
Industry knowledge helps too. If you operate in healthcare, real estate, education or hospitality, a team that already understands the workflow will ask better questions. We describe how we approach those sectors on our industries page.
2. The people who will actually do the work
Sales teams and delivery teams are often different people. Ask to speak with the developer or lead who will be on your project, not just the account manager. You are hiring their judgement. Ask:
- Who will work on my project, and how many hours a week?
- What is their experience with this technology?
- What happens if one of them leaves mid-project?
3. Communication
Most project problems are communication problems in disguise. Pay attention to how a vendor behaves before you sign. Do they reply promptly? Do they ask good questions or simply agree with everything? Do they explain technical points in plain language?
Agree the working rhythm early: who you speak to, how often, and how progress is shown. Regular demos of working software are far more useful than status reports.
4. Process and transparency
A good team can describe how a project moves from idea to launch without hand-waving. Look for:
- Discovery first. Time spent understanding the problem before estimating it.
- Short delivery cycles. Working software shown regularly.
- Visible progress. Access to a task board, a staging site or a demo after each cycle.
- A clear way to handle change. Requirements always evolve; the question is how that is managed.
You can read how we run projects on our approach page.
5. Technical quality
You do not need to be technical to assess quality, but you should ask about it. Good signs include:
- Code in a version-controlled repository that you own.
- Automated tests for the critical parts of the system.
- Code review as a normal step.
- Documentation and a handover plan.
- Sensible security practices: protected secrets, validated input, regular updates.
If you have an in-house developer or a trusted adviser, ask them to join one technical conversation. A short review can reveal a great deal. For a sense of what we check when reviewing existing code, see signs your Laravel application needs a technical review.
6. Honesty about fit
The best vendors sometimes tell you not to build. They recommend an existing product, a smaller scope or a different technology. That may cost them a project, but it builds trust. If every answer is "yes, we can do that", be careful. Our article on custom software versus off-the-shelf covers the kind of honest conversation you should expect.
Questions that reveal how a team works
These questions are simple, and the answers say a lot.
- "What would you leave out of the first version?" Good teams cut scope confidently. Weak ones say yes to everything.
- "What are the biggest risks in this project?" A thoughtful answer shows experience. A blank one shows the opposite.
- "How do you handle changes after work has started?" Listen for a defined process, not "we are flexible".
- "Can I speak with a past client?" Confident vendors arrange this easily.
- "What happens after launch?" Support, updates and hosting should have clear answers.
- "Who owns the code and data?" The answer should be you, in writing.
- "Show me something you built that did not go as planned." Honesty here is a strong signal.
- "How will I see progress?" Look for demos and access, not just reports.
Pricing models and what they mean
How a vendor charges changes who carries the risk. Understanding the options helps you compare proposals fairly.
| Model | How it works | Good for | Watch out for |
|---|---|---|---|
| Fixed scope | One agreed price for a defined scope | Clearly defined projects | Changes are priced separately, scope disputes |
| Staged milestones | Budget released stage by stage | Products that will evolve | Needs review after each stage |
| Dedicated team | A monthly cost for a team on your roadmap | Long-running work | You must prioritise actively |
| Time and materials | Pay for hours worked | Uncertain or exploratory work | Needs good reporting and a cap |
Our custom software cost guide explains how these models play out in practice, and the question of in-house versus outsourced versus freelance is covered in dedicated team vs freelancers vs in-house developers.
Be wary of the lowest quote. A very low price usually leaves something out: testing, security, documentation or handover. Compare what is included, not only the total.
Red flags
Watch for these during the selection process.
- A quote with no discovery. A price given after a single short call is a guess.
- No questions about your users. A vendor who never asks who will use the product is not thinking about the product.
- Vague answers about who does the work. If you cannot identify the team, you do not know what you are buying.
- Pressure to sign quickly. Good proposals hold for a reasonable time.
- No mention of testing or security. Both cost time and are often quietly removed to lower the price.
- Unclear ownership. Any hint that the vendor keeps the code or locks you into their hosting is a serious problem.
- Only positive references. Everyone has a project that was difficult; a perfect record usually means it was curated.
- No plan for after launch. Software needs care once it is live.
Contract points worth checking
You do not need to be a lawyer, but read these areas carefully, and consider professional advice for larger projects.
- Scope and deliverables. What exactly will be delivered, and what is excluded?
- Ownership of intellectual property. The code and designs should belong to you once paid for.
- Payment schedule. Tie payments to delivered milestones, not just dates.
- Change process. How requests are estimated and approved.
- Confidentiality. Especially important for sensitive data and unreleased ideas.
- Support and warranty. How long defects are fixed at no cost after launch.
- Exit terms. How you can end the relationship and get your code, data and documentation.
Start small to test the relationship
The safest way to choose is to work together briefly before committing to the whole project. Options include:
- A paid discovery phase. A short engagement that produces a scope, a prototype or an architecture plan. You learn how the team works and get something useful either way.
- A small first milestone. A limited piece of the product, delivered and reviewed before the rest begins.
- A one-developer trial. If you are adding capacity, start with one person; you can see how they fit before expanding. Our pages on hiring Laravel, mobile and dedicated team engagements describe how this works.
For startups, this approach pairs naturally with building a minimum product first. Our startup page and the guide to building an MVP describe how to keep the first step small.
A simple scoring sheet
If you are comparing two or three vendors, score each from 1 to 5 on these areas, then discuss the results with your team.
- Relevant experience
- Quality of the people assigned
- Clarity of communication
- Process and transparency
- Technical practices
- Honesty and willingness to push back
- Commercial terms and ownership
- After-launch support
Do not add the scores blindly. A vendor with a low score in honesty or ownership should be eliminated regardless of the rest.
Final thoughts
Choosing a software partner is less about finding the most impressive company and more about finding the one whose way of working suits you. Look for clarity in how they communicate, evidence in what they have built, honesty in what they tell you, and fairness in what they put in writing.
If you would like to see how we work before making any commitment, start a conversation about your project. We will tell you plainly what we think, including when we think you need less than you expected.