Direct answer
Choose on how clearly a vendor defines what you are buying and who owns it afterwards, not on how long their client list is. A good proposal tells you what will be built, what will not, what it costs, how you will accept the work, and which accounts, code and domain end up in your name. If a vendor cannot put those five things in writing before work starts, no portfolio makes up for it.
This guide applies to any agency, freelancer or studio, including us. Use it as a scorecard, and score LATYNEX against it the same way. For the narrower question of an agency versus an individual, see agency vs freelancer for a website.
What to settle before you talk to anyone
Vendors can only be compared fairly if they are all answering the same question. Before the first call, write a one-page brief so every proposal is measured against the same thing.
- The problem in one or two sentences: who is stuck, doing what, today
- The first version you would be happy to launch, and what can wait (the [MVP scope guide](/mvp-scope-guide/) helps with this)
- Who will use it and who will approve it on your side
- Systems it must connect to, and data that must move in
- A deadline that is real, and the reason for it
- Your budget range, if you have one. Sharing it saves everyone time; hiding it usually produces proposals you cannot compare
Scope clarity
The strongest signal in early conversations is the quality of the questions a vendor asks. A vendor who quotes quickly without asking about users, data, roles and edge cases is either guessing or planning to fix the difference later through change requests.
Look for a proposal that separates what is included from what is explicitly out of scope, lists the main user flows, and names the assumptions the price depends on. Vague phrases such as 'full-featured platform' or 'all necessary integrations' are not scope. A list of screens, roles, integrations and rules is.
A written scope and one price
Ask each vendor how price relates to scope. The healthiest pattern is one scope and one price agreed in writing before work starts, with a defined way to handle changes: what counts as a change, who approves it, and how it is priced. LATYNEX agrees one scope and one price in writing before work starts, and it is a fair thing to ask of anyone.
Hourly or open-ended arrangements can be legitimate for exploratory work, but then ask what you receive at each checkpoint, how progress is reported, and what stops the total from drifting. For a sense of what drives price in general, read web application development cost.
Ownership and access
Ask, before signing, who will own each of these at the end: the source code, the hosting and cloud accounts, the domain, the databases and the third-party service accounts. The right answer is that they are created in your name from the start or handed over in your name, with credentials you control. LATYNEX commits to handing over code, domain and accounts in the client's name.
Put whatever is agreed in the written scope or contract, and have a lawyer review the contract wording. This page does not give legal advice. The companion guide on who owns the code and accounts after a custom build lists what to confirm.
References and how to check them
A logo wall proves little. Ask instead for one or two contacts you can speak to whose project resembles yours in size and complexity, and ask them things a brochure cannot answer.
- Did the final price match the agreed scope? What changed and why?
- How did the vendor behave when something went wrong or slipped?
- Could you have taken the project to another team afterwards? Did you have the code and accounts?
- Who did you actually deal with day to day, and was it the same person who sold the project?
- Would you hire them again for something similar?
Team and communication
Find out who will do the work, not who will pitch it. Ask who your main contact is, how often you will see working software, where progress is tracked, and what happens if that person leaves. Time zone and language matter in practice: LATYNEX is a remote English-language vendor, so confirm that overlapping hours and a written-first way of working suit you, and expect the same clarity from any remote team.
Ask to see how the vendor documents decisions. Teams that write things down are much easier to hand work over from, and to hold to an agreement.
Red flags
None of these is proof of a bad vendor on its own, but two or three together should slow you down.
- A price with no written scope behind it, or a scope that changes shape between calls
- Reluctance to say who owns the code, hosting and domain, or answers that begin with 'we usually host that for you'
- Pressure to sign quickly based on a deadline the vendor created
- No questions about your users, data or existing systems
- Promises of results, rankings or revenue that a build cannot control
- References offered only as a list of names you are not allowed to contact
- No mention of testing, acceptance or handover in the plan
Comparing proposals side by side
Put every proposal into the same table. Score each row as clear, partly clear or missing, and do not let a low price hide a missing row.
- What is built, and what is explicitly excluded
- One price, what it covers, and how changes are priced
- Milestones and what you can see at each one
- How acceptance works and who signs off (see the [acceptance testing checklist](/user-acceptance-testing-checklist-custom-software/))
- What is handed over, in whose name, and when
- Who does the work and who you talk to
- What happens after launch: support, fixes, and how to end the relationship cleanly
Where LATYNEX fits
LATYNEX builds custom web applications for businesses. We agree one scope and one price in writing before work starts, and hand over code, domain and accounts in your name. If your project would be better served by a different kind of vendor or a simpler tool, we will say so plainly. If you want to see how we would handle your brief, start with web application development.
Questions
How many agencies should I get proposals from?+
Two or three comparable proposals against the same written brief is usually enough. More than that mostly adds noise. The value comes from comparing like with like, not from the number of quotes.
Is the cheapest proposal a red flag?+
Not automatically, but check what is missing. A low price often means a narrower scope, no testing or handover, or assumptions that will turn into change requests. Compare scope row by row before comparing totals.
Should I choose an agency or a freelancer?+
It depends on the size of the project, how much coordination you need and how you will cover absence or hand-over. See the agency vs freelancer comparison for the trade-offs. The same scorecard applies to both.
What should be in the first meeting?+
Your one-page brief, a discussion of what the first version should include, and the vendor's questions back. Leave the meeting knowing what the next written deliverable is and when you will receive it.
Does LATYNEX suit every project?+
No. If we are not the right fit, for example because the project is very small or needs something other than a custom build, we will tell you straight.