In this guide 6 sections
Choose by who will do the work, not by the name on the proposal. Big IT houses suit governed, multi-country programmes. Small firms suit a defined product with senior people in direct contact. Ask who writes the code, the smallest project accepted and what you receive at handover.
Who actually writes your code?
A large firm sells with its senior partners and delivers with a pyramid, so the people in the pitch meeting are rarely the people in your sprint review. Junior developers do most of the typing, juggling tickets in Jira, while a delivery manager filters every question between you and them.
Small firms often work the other way round. The founder who scoped the job may also review every pull request. That is quick. It also means one resignation, one illness or one wedding season can stall your project for a month while the founder hunts for a replacement.
Ask for named people, their experience and their weekly hours on your job, and meet them before you sign anything. If the answer is vague, assume the pitch team will vanish once the contract is countersigned.
- Names and roles of the delivery team
- Hours each person gives to your project
- Who reviews code before it ships
- What happens if a key person leaves
Minimum project size decides more than quality does
Large firms bake overhead into every engagement. They need a job big enough to justify a project office and a weekly status deck. A modest internal tool may fall under their floor. Or it may arrive wrapped in ceremony you never asked for.
Smaller shops take work the big ones decline. A booking portal, a quoting tool, a dispatch app or a warehouse barcode scanner can start within weeks, often from a shared Slack channel and a Figma mockup. The limit shows up in the other direction, because a five-person shop asked to run a multi-country rollout will struggle.
Match the weight of the firm to the weight of the job. A courier-tracking widget does not need a programme director, and a bank’s core ledger migration should not rest on three freelancers and a shared spreadsheet.
Speed, access and how decisions get made
Inside a large firm, a change request travels through a change board, a commercial review and a revised statement of work. Each step makes sense for a bank. For a family-owned distributor it turns a one-day tweak into a three-week email chain.
A small firm can decide on a call. You message the lead developer on Tuesday and see the fix on Thursday. Speed has a price, though, because fewer written controls means you must insist on tickets, demos and a release log yourself.
Check how you will reach a senior person when invoicing breaks late on a Sunday. The answer shows whether support is a rota or one overworked phone. A mobile number beats a ticket portal.
- Turnaround for a small change request
- Who approves scope changes on their side
- Escalation route when a release fails
- Demo rhythm, weekly or fortnightly
Handover, ownership and the day you leave
Whichever you pick, you must be able to walk away. Insist on the source repository in your own account, the cloud hosting under your company name, the domain registrar login and every third-party API key.
Large firms usually include a formal exit clause. Small firms often have nothing in writing. Ask for documentation that a stranger could follow, covering setup steps, environment variables, database schema and deployment notes.
A project handed over as a zip file on a pen drive is not handed over. Put a short exit clause in the contract before work begins, not after the first dispute.
When the big firm is the right answer
Pick the large company when the programme touches many countries, needs auditors’ sign-off, must run on a mandated platform or calls for hundreds of people at once. Procurement teams at listed companies often require exactly that scale, along with the paperwork that comes with it.
Pick the small firm when you need a working first version, direct access to the builders and room to change your mind. Be frank about your own size too. If you have one owner and no internal IT person, heavy process will bury you.
This week, write down the three outcomes you need from the first release and ask both kinds of firm to describe only those.
Vendor comparison worksheet
One printed sheet with two columns, large firm and small firm. Eight rows run down the side: named team, weekly hours, smallest project accepted, change request turnaround, senior contact route, repository and hosting ownership, exit clause and documentation list. Every row takes a rating from one to five and a line of notes.
Open a blank worksheet to printQuestions owners ask
Is a small software firm riskier than a large one?
The risks differ rather than grow. A small firm leans on a few people, so key-person loss hurts. A large firm can hand you a rotating team that never learns your business. Check continuity either way.
Can a large IT company take a small project?
Some will, often through a mid-market arm or a partner. Expect more process and a slower start. Ask whether the senior people from the pitch will sit on your job.
Should I ask for references?
Yes. Speak to a client of similar size who went live a year ago. Ask what broke after launch and how quickly the firm answered the phone.
Can I split work between the two?
Often. A large firm can run the core platform while a small firm builds the customer app on top. Agree the interfaces and who owns what in writing first.