AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms12
Questions to ask
Before any contract is signed
6
Red flags
Visible during the sales process
4
Engagement models
And where the risk sits in each
1
Clause that matters most
IP assignment to you, in writing
Know what you're comparing
Not every firm that writes software is the same kind of business
The label on the website rarely tells you how the work is actually delivered. Before comparing proposals, work out which of these you are talking to — because a staffing firm and a product studio can quote the same project and mean completely different things by it.
Full-service software development company
Owns delivery end to end: discovery, architecture, design, engineering, testing, deployment, and support. You buy an outcome, and the firm is accountable for how the team is shaped to reach it. The right fit when you don't have an engineering organisation of your own, or don't want to manage one for this project.
Software development agency
Often used interchangeably with the above, but agencies frequently grew out of web and design work and are strongest on customer-facing products. Ask how much of their recent work was back-end systems, integrations, and data — not just interfaces.
Staff augmentation firm
Supplies engineers who join your team and work under your management. You own the process, the backlog, and the outcome. Excellent when you already run engineering well and need capacity; a poor fit when what you actually need is someone to take ownership.
Freelancers and marketplaces
Individual contractors, sourced directly or through a platform. Flexible and fast to start for narrow, well-defined tasks. The risk is continuity: when a single contractor leaves, the knowledge of the system usually leaves with them.
Offshore outsourcing vendor
Large delivery centres optimised for volume. Can work well for stable, well-specified systems. Evaluate time-zone overlap, who your day-to-day contact actually is, and how often the team assigned to you changes.
Product studio
Builds new products from zero, often with strategy and design leading. Strong for early-stage validation and MVPs; ask how they handle the handover to the team that will run the product after launch.
The build-or-hire decision
A development company, an in-house team, or freelancers
There is no universally right answer. The honest comparison is about how quickly you need to start, how long the system will live, and who will own it when the first version is done.
| Option | Best when | Watch for | Who holds the knowledge |
|---|---|---|---|
| Software development company | You need a complete team quickly and a single party accountable for delivery | Vague ownership terms, team rotation, and handover quality | Shared — and it should be written down for you |
| In-house team | The software is your core product and will be developed for years | Months to hire, and senior engineers are hard to retain | Your employees |
| Freelancers | The work is narrow, well specified, and short-lived | Continuity, code review, and security practices | Individual contractors |
| Hybrid | You have a technical lead but need delivery capacity around them | Blurred accountability between your lead and the vendor | Your lead, if documentation is enforced |
The checklist
Twelve questions to ask every software development company
Ask each firm on your shortlist the same questions, in writing, and compare the answers side by side. Vague answers are information too.
1. Who, specifically, will write the code?
Ask for the names and seniority of the engineers who will be assigned — not the team that appears in the pitch. Ask whether they are employees or subcontractors, and where they are based.
2. Who owns the code and the IP?
The contract should assign all intellectual property to you on payment, including source code, designs, and documentation. Check for exceptions: proprietary frameworks you'd be licensing forever are a lock-in by another name.
3. Where does the code live from day one?
The healthiest answer is a repository in your organisation's account, with you as owner, from the first commit. Code delivered as a zip file at the end is a warning sign.
4. How is scope agreed — and changed?
Ask to see how they turn a brief into a scope, and what a change request looks like in practice. A good firm can explain exactly what happens when priorities shift halfway through a sprint.
5. What does 'done' mean?
Look for written acceptance criteria per feature, automated tests, and a review step before anything merges. 'Done' should mean deployed and verified, not 'the developer says it works'.
6. How do you test and release?
Ask about continuous integration, test coverage on business logic, staging environments, and rollback. You want to hear about a pipeline, not a person who deploys on Fridays.
7. How do you handle security?
Dependency scanning, secrets management, access control, and how production data is handled during development. If you are in a regulated industry, ask for experience with that regime specifically.
8. How do you use AI in delivery?
Most firms now use AI coding tools. The useful question is what review stands between AI-generated code and production, and whether your code or data is sent to third-party models.
9. Can we speak to past clients?
Case studies are curated. A reference call with a client whose project had problems — and how they were resolved — tells you far more than a polished success story.
10. How will we communicate?
Cadence, tools, time-zone overlap, and who your single point of contact is. Ask how you will see progress: working software on a preview URL beats a weekly status deck.
11. What happens after launch?
Support terms, response times for production incidents, and who is on call. Launch is the beginning of a system's life, and most of its cost comes after it.
12. How do we leave?
Notice periods, handover obligations, documentation, and access transfer. A firm confident in its work will make leaving easy — which is exactly why you'd stay.
Warning signs
Red flags that show up before you sign
Most failed projects were visible in the sales process. These are the signals worth walking away from, or at least pressing on.
A price before questions
A detailed number offered before anyone has asked about your users, integrations, or data means the estimate is a sales tool, not a plan.
The team you meet isn't the team you get
Senior people run the pitch; juniors you never met run the project. Ask to meet the actual lead engineer before signing.
Ownership is deferred
Repository access 'at the end of the project', or IP that transfers only after a final milestone that keeps moving.
Everything is possible
No pushback on scope, timeline, or technology choices. Good engineers disagree with clients regularly — politely and with reasons.
No written process
They cannot show you what a sprint review, a change request, or an incident report looks like, because none exist.
Pressure to commit long-term
Long minimum terms before any work has been delivered. Trust should be earned in increments, starting with a scoped first phase.
Engagement models
How the contract structure moves the risk
The engagement model decides who carries the risk when estimates turn out wrong. Choose it deliberately rather than accepting whatever the first proposal assumes.
| Model | How it works | Best for | Risk sits with |
|---|---|---|---|
| Fixed scope | A defined deliverable, agreed up front, delivered in milestones | Well-understood projects with stable requirements | Mostly the vendor — so expect a careful discovery phase first |
| Dedicated team | A standing team working through your roadmap month to month | Products that evolve continuously after launch | Shared; you steer priorities, the vendor owns delivery quality |
| Staff augmentation | Individual engineers join your team under your management | Organisations with strong engineering leadership already | Mostly you, because you own the process |
| Time and materials | Billed for time spent against a loosely defined backlog | Exploratory work where scope genuinely can't be fixed | Mostly you — insist on frequent, visible progress |
What drives cost, whichever model you pick: how clearly the scope is defined, the number of systems to integrate, compliance and security requirements, and how much of the work is new versus rebuilt. Be wary of comparing proposals on headline figures alone — two firms quoting the same brief are often pricing different amounts of testing, documentation, and support.
Verify before you trust
How to check a firm's claims without taking their word for it
Every proposal claims senior talent and on-time delivery. These are the ways to find out whether it's true before the project depends on it.
Read reviews on independent directories
Clutch and GoodFirms verify reviews with the client directly. Read the critical ones and the vendor's replies — how a firm responds to a bad review is a preview of how it handles a bad week.
Look at code, not screenshots
Ask for a sample repository, open-source contributions, or a walkthrough of a codebase they maintain. Structure, tests, and documentation are hard to fake.
Start with a paid discovery phase
A short, scoped engagement that produces an architecture, a risk list, and a real plan. It's the cheapest way to see how a team thinks — and the output is yours even if you choose someone else.
Run a first milestone before a long commitment
A small, real deliverable shows you the team's communication, code quality, and honesty about progress far better than any sales call.
Next steps
Where to go from here
If you're evaluating DEV.co as one of the firms on your list, these pages answer the questions above for us specifically.
Questions
Questions buyers ask
What teams ask before a first call.
Ownership. Make sure the contract assigns all intellectual property to you, that the code lives in a repository your organisation owns from the first commit, and that you can take the system to another team without the vendor's permission. Almost every other problem can be fixed mid-project; losing control of your own code cannot.
Location matters less than time-zone overlap and communication discipline. A remote team with several hours of daily overlap, a named lead, and working software you can review every two weeks will usually outperform a local team without those habits. If your industry has data-residency or on-site requirements, those take priority.
Three to five is usually enough. Ask each the same written questions, request a short discovery proposal rather than a final quote, and hold reference calls with the two finalists. Comparing more firms than that tends to produce more proposals, not better decisions.
The terms overlap and many firms use both. In practice, agencies often come from web and design work and lead with user-facing products, while firms describing themselves as software development companies more often emphasise back-end systems, integrations, and long-term support. Judge by the portfolio and the team, not the label.
Normalise them. List what each includes for discovery, design, testing, documentation, deployment, and post-launch support, and note who owns the code and on what terms. Differences in headline figures often come down to one firm leaving out testing or support that another has included.
Discovery and architecture decisions written down, a repository and environments set up in your accounts, a prioritised backlog you agree with, and a first increment of working software on a preview URL. If a month passes without anything you can click on, raise it immediately.