Describe the system before you compare companies
A development quote is mostly a price for decisions: how content is structured, which systems connect, what happens when something fails and who keeps the site running. Two companies can quote the same ten pages and be pricing different jobs. Before you contact anyone, write down the routes and templates you need, the content each one holds and the person who will edit it. List every integration, such as forms, CRM, booking, payments, search and analytics, with the account owner and what must happen when it is unavailable.
Add the constraints that change effort more than page count: languages, sign-in, migrated content and URLs, and the devices and browsers that must work. Send the same document to every bidder. Proposals written against one brief can be compared; proposals written from a sales call usually cannot.
| Brief input | Why it changes the proposal |
|---|---|
| Templates and content model | Reusable templates and editable fields cost differently from one-off pages |
| Integrations and accounts | Each connection needs error states, credentials and a named owner |
| Languages and migration | Translated routes, redirects and moved content are separate work |
| Devices and browsers | The support list sets how much testing acceptance requires |
The factors to compare between development companies
Most companies will say they build fast, secure and accessible sites. Ask each one to show how, on work you can inspect. Accessibility has a public reference: WCAG 2.2 from the W3C. Ask which conformance level they test against, how they test it (keyboard, screen reader, automated checks) and what happens to defects found after launch. Performance has one too: Google documents the Core Web Vitals and the thresholds it uses. Ask for field data or a test of a comparable live page, not a lab score from a staging site.
Security and maintenance are where proposals differ most quietly. Ask how dependencies are updated, who receives security alerts, how forms are protected against spam and abuse, and how a backup is restored. The OWASP Top 10 is a widely used list of web application risks; a company building sign-ins, payments or custom APIs should be able to explain how its process handles the ones that apply. Finally, ask who will write the code. Subcontracting is not a problem in itself, but you should know who is accountable when something breaks.
| Factor | What to ask | Evidence to request |
|---|---|---|
| Accessibility | Which WCAG 2.2 level, and how is it tested? | A tested page and its defect list |
| Performance | How is speed checked on real devices? | Field data or a test of a comparable live page |
| Security | Who updates dependencies and receives alerts? | The update and backup routine in writing |
| Content workflow | Who edits what, and how is it published? | A demo of an editor changing real content |
| Ownership | Who holds the repository, hosting, domain and accounts? | A handover list with named owners |
Development company or design studio?
The evaluation changes with the kind of risk in the project. If the hard part is the system, such as a customer portal, complex integrations or data that must stay consistent across tools, weigh engineering process, testing and support capacity most heavily, and ask for production history with similar systems. If the hard part is the message, such as a new brand, an unusual offer to explain or art direction that has to survive implementation, a design-led studio that also builds may fit better, because the people making visual decisions will also have to make them work.
Many projects need both, and the risk sits in the gap between them: a design delivered as pictures that developers interpret, or a build team that fills undecided states with defaults. Ask who designs empty, loading and error states, who approves the implemented page against the design, and how changes requested after acceptance are handled. The scorecard for choosing a bespoke web-design studio covers the design side of the same decision.
Red flags in a development proposal
A proposal previews how the project will be run. Treat these as reasons to ask more questions, not automatic disqualifications.
- A fixed price before anyone has seen the content model or the integration list.
- No named owner for the domain, hosting, repository or third-party accounts after launch.
- Accessibility or performance described only with adjectives, with no test method.
- A platform chosen before anyone discusses the editing workflow.
- Support that starts only when something breaks, with no update routine.
- Portfolio projects where the company cannot say which part it built.
Where Dardo fits
Dardo is a web design and development studio in Bogotá. It is one option when the same team should carry visual direction, content structure and a working implementation through launch, in English or Spanish. The A medio tono music school site is a delivered example, with course and teacher pages and a contact route that reaches the school. It shows that combined scope; it is not a measured enrollment result. If your project is mainly a large platform integration or custom software, compare companies with production history in that kind of system, and ask them the same questions.
Sources & editorial notes
Sources
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2w3.org
- Google Search Central: Core Web Vitalsdevelopers.google.com
- OWASP Top 10owasp.org
- A medio tono delivered websiteamediotonomusic.com
How we built this guide
EvidenceThis guide combines 4 linked sources, Dardo’s analysis and clearly labeled project examples.
LimitsVisible design and content decisions are not presented as measured ranking, traffic or conversion gains.
Read our editorial policy