Before you ask for a quote
Hiring a software company means handing someone part of your business that you probably cannot review line by line. You will not read the code, but you will live with it: the slow screens, the bug that keeps coming back, the simple change that somehow takes two weeks. That is why the decision has to go beyond price and a good first impression.
Before you talk to vendors, write a short brief: the problem the project solves, who will use it, what must be ready in the first version and whether there is a date that cannot move, like a launch or a sales season. That brief makes answers easier to compare and shows you who is actually listening and who is reading from a script.
Portfolio: ask for work that is live
Polished screenshots on Dribbble or Behance do not prove that anything works. Ask for links to shipped projects: the website that loads, the app you can install, the store that takes real orders. Open them on your phone, click around, fill in a form and see whether the page stays fast on a mobile connection.
Ask what the company actually did on each project. Did they build all of it or only the design? Did they take over a half-finished system? Do they still maintain it? A serious team answers without hesitation and, when an NDA is in place, explains what they can and cannot show.
If your project has a specific requirement, such as recurring billing, an ERP integration or an AI feature, ask whether they have built something similar and ask to see it running. Experience with your type of problem matters more than experience with whatever framework is trending.
The process, from discovery to delivery
Ask what happens between signing and launch. A good answer has clear stages: understand the business, define scope, design the screens, build, test and ship. When a vendor jumps straight from the quote to coding, the questions that should have come up in discovery show up halfway through the project, when changes cost more.
Pay attention to delivery rhythm as well. Short milestones with test builds you can open on your own phone or browser let you correct course early. The opposite pattern, months of silence followed by one big reveal, is where the worst surprises come from.
- What is the first stage, and what do I get when it ends?
- Will I see a prototype of the screens before development starts?
- How often will I get a build to test?
- Who tests the product, and on which devices?
- What happens if I want to change something midway?
Who does the work and how you will communicate
The people who sell the project are not always the people who build it. Some agencies sign the deal and pass the work to freelancers or another company, and the client only finds out when quality drops or nobody can answer a technical question. Subcontracting is not wrong in itself, but it should be disclosed upfront. Ask who will work on your project, whether they are in-house and whether you can talk to the developers when needed.
Agree on how communication will work: which channel, how often you get updates and who the point of contact is on each side. A short weekly call covering what was done, what comes next and what is blocked beats dozens of scattered messages. If you are hiring a nearshore team, for example a Brazilian company working with a client in the US or Europe, ask about overlapping hours and the language used day to day. And notice how the vendor communicates during the sales process. If replies take days now, they rarely get faster after the contract is signed.
Code, domain and accounts: who owns what
This is the question many people forget and later regret. Do you own the source code? Is the domain registered to your company? Are the hosting, database, App Store, Google Play and payment accounts in your name or in the vendor’s?
The situation to avoid is everything living in the vendor’s accounts. If the relationship ends, you lose access to your own product or have to negotiate to get it back. Ideally the code sits in a repository you can access, the main accounts are in your name and there is enough documentation for another team to pick up the work.
Ask which technologies they will use and why. A mature, well-documented stack makes it easier to hire someone else later. A proprietary tool that only that agency knows how to run locks you in.
Contract and scope in writing
A good proposal describes the deliverables in enough detail to prevent arguments later: screens, features, user roles, integrations, what is out of scope, the timeline for each milestone, the price and the payment terms. Phrases like "complete management system" or "an app like our competitor’s" are not scope, because each side will picture something different.
Read carefully what happens when something changes. Something will change, because every project teaches you things nobody knew at the start. The contract should say how changes are assessed, quoted and approved before they enter the schedule. Also check the warranty period for bug fixes after delivery, confidentiality, how personal data is handled under the privacy law that applies to you (GDPR, CCPA or LGPD) and the terms for ending the engagement.
What happens after launch
Launch is when real usage starts, and real usage is what reveals the fixes you need. A screen that breaks on one specific phone, a flow customers do not understand, a third-party integration that changes version without warning. Ask who handles that, how fast and how it is billed.
Ask whether there is a maintenance plan, what it covers (bug fixes, security updates, small improvements, monitoring) and how new features are handled. A vendor that ships and disappears leaves you searching for someone new to work on code they have never seen, and that restart is rarely cheap.
Red flags before you sign
Some behaviors show up before the contract and say a lot about how the project will go:
Be wary of heavy jargon used to impress, too. People who know the subject can explain in plain language why a choice makes sense for your case.
- A quote sent without a single question about your business, your users or your rules.
- A deadline that is too short for the scope, promised before they understand the project.
- A "we can do anything" answer to every request, with no risks flagged and nothing suggested for later.
- Reluctance to show live projects or to say who will build yours.
- Code, domain and accounts kept in the vendor’s name.
- Full payment upfront, with no milestones tied to deliverables.
- A proposal with no mention of what is out of scope.
Questions to bring to the meeting
If you want a script, take these questions to every vendor and compare the answers side by side. Beyond the content, notice who answers clearly and who dodges.
At BG Coding, we only quote after we understand the project, and the proposal comes with defined scope, timeline and price, split into milestones you can follow. The code and the accounts belong to the client. If you are comparing vendors, feel free to use this same list with us.
- Can I see projects similar to mine running live?
- What are the stages, and what do I get at each one?
- Who will work on the project, and who do I talk to day to day?
- How often will I test a new build?
- Will the code, domain and accounts be in my name?
- How are scope changes handled?
- What is included after launch?