5 Questions You Should Ask Before Hiring a Development Agency


Choosing the wrong agency costs you rework, unnecessary dependencies, and difficulty switching vendors later
Choosing a development agency isn't just about comparing portfolios and prices. The decision involves your team's autonomy, the ability to evolve the product, organic visibility, security, support, and control over the assets that keep the project running.
A well-defined hire reduces unnecessary dependencies and makes clear, from the start, who takes care of each part of the product. A poorly defined one can create rework, delays, unexpected costs, and difficulty switching vendors. The five questions below turn a sales conversation into an objective evaluation of capability, process, and risk.
1. How Will I Update the Content After Launch?
The question shouldn't simply be “do you use a CMS?”. What matters is understanding who will need to change the content and how often. An institutional site with a blog and marketing pages can benefit a lot from a CMS; an internal dashboard or a SaaS application may call for a different kind of admin panel.
Rule of thumb
If your team changes copy, images, case studies, products, services, or articles often, the agency should explain how those changes will happen without relying on development for routine editorial tasks.
Questions worth asking:
- Which content can I edit without coding?
- Does the panel have access profiles and permissions for different users?
- Is there a preview, version history, or a way to revert changes?
- Do you provide training, a manual, or usage videos?
- Does adding a new page, service, or product automatically preserve the visual pattern?
- Is there any license cost or CMS dependency I should know about?
| Weak answer | Mature answer |
|---|---|
| “There's a panel, but it's better to call us to change anything.” | “We mapped out which fields will be editable, set up permissions, and provide training/documentation.” |
| “You can just clone the page and adjust it.” | “Content is structured into components/templates to keep consistency without manually copying pages.” |
| “Any change counts as development.” | “Editorial content is self-service; layout changes, business rules, or integrations count as product evolution.” |
2. How Will the Project Be Prepared for SEO and AI Search Experiences?
In 2026, talking about organic visibility means considering both traditional search and generative experiences. The market uses terms like GEO (Generative Engine Optimization) and AEO (Answer Engine Optimization), but Google positions this work as a continuation of good SEO practices: useful content, clear technical structure, crawlability, indexability, and a good experience. There's no “magic schema” or special format that guarantees a spot in AI answers. [S02][S03]
For ChatGPT Search, OpenAI documents OAI-SearchBot as its search crawler. Sites that want to appear in ChatGPT search results should review their robots.txt and any WAF/CDN blocks that might prevent that access. [S07][S08]
What a mature delivery should include:
- Technical fundamentals: HTTP status, indexability, canonicals, sitemap, robots.txt, and proper rendering. [S01]
- Information architecture, headings, and internal links consistent with each page's intent.
- Useful metadata and content that answers real audience questions without keyword stuffing.
- Structured data only when it fits the visible content and supported types. [S04]
- Search Console and analytics configured for measurement.
- A review of relevant crawlers and infrastructure protection so legitimate bots aren't blocked by mistake.
- An editorial plan with authorship, hands-on experience, evidence, and periodic updates for strategic content.
| Warning sign | Strong answer |
|---|---|
| “We guarantee first page ranking.” | “We don't promise rankings. We define technical requirements, content, measurement, and improvement hypotheses.” |
| “We have our own schema for ChatGPT.” | “We use standardized markup where relevant and handle crawling/indexing. There's no special markup required for AI.” |
| “You'll see later if it worked.” | “We set up metrics, a baseline, and reports for Search and identifiable referrals from assistants/search engines.” |
FAQ JSON-LD: a word of caution
FAQPage is still a valid Schema.org type, but Google removed the FAQ rich result in May/June 2026. So use FAQPage only if the page genuinely contains FAQs and it makes semantic sense — don't sell it as a visual feature in Google Search. [S05][S06]
An example of correct markup, with questions that genuinely appear on the page — this is the exact structure we generate automatically for this article:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Can the agency get me into AI answers?",
"acceptedAnswer": {
"@type": "Answer",
"text": "No agency can guarantee a recommendation. The work should improve crawlability, indexing, structure, content, evidence, and measurement."
}
},
{
"@type": "Question",
"name": "Will the site be secure against attacks?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Security is never an absolute guarantee. The agency should explain controls, dependency updates, backups, access management, logs, and vulnerability handling."
}
}
]
}How to track results:
| Layer | Useful metrics | Tool / evidence |
|---|---|---|
| Organic search | Clicks, impressions, CTR, queries, pages, and average position | Google Search Console [S09] |
| Google's generative features | Visibility and performance in generative features available for the property | Search Console [S10] |
| ChatGPT Search | Sessions/referrals identified with utm_source=chatgpt.com when applicable | Analytics + OpenAI documentation [S08] |
| Business | Leads, meetings, revenue, assisted conversion, and traffic quality | CRM + analytics |
3. What Happens After Launch?
Launching the site doesn't end the operational work. Dependencies get updates, integrations change, certificates and services need to be watched, bugs can show up in real-world scenarios, and the business keeps asking for evolution.
That's why the contract should separate three things: fixing defects attributable to the original delivery, ongoing maintenance, and new features. Lumping it all under “support” tends to create mismatched expectations between client and vendor.
- Is there a bug-warranty period? What counts as a bug?
- Is support monthly, an hours package, or on demand?
- Which security and dependency updates are included?
- Is there uptime monitoring, logs, and alerts?
- How are critical, high, medium, and low incidents classified?
- What's the response time and target resolution time for each severity?
- Are backups, restoration, and recovery testing included?
- How are new features estimated and prioritized?
SLA isn't universal
A “2-hour response time” can be excellent for a critical system and unnecessary for a simple institutional site. The best SLA is the one that matches the business impact of downtime and is written into the contract.
| Illustrative profile | Coherent coverage | Example P1 response |
|---|---|---|
| Institutional site | Business hours + basic monitoring + scheduled updates | Same business day or as contracted |
| Lead gen / e-commerce | Continuous monitoring, alerts, and escalation | A contracted window of a few hours |
| Critical system | 24/7 on-call, observability, incident response, and redundancy | Severity-specific SLA |
4. Who Sets Up the Domain, Hosting, DNS, and Corporate Email?
This is one of the areas where simple projects turn into operational headaches. A client can receive a “finished” site and still not know where the domain is registered, who controls the DNS, where the application is hosted, or why emails aren't arriving.
The ideal is to map every asset, set proper ownership, and record who has access and who's responsible. For .br domains, Registro.br distinguishes between the registrant and administrative/technical contacts; the agency can operate technically without needing to be the registrant of the client's domain. [S22][S23]
| Asset | What should be clear |
|---|---|
| Domain | In the client's/company's name; access to the registrar; correct contacts; renewal defined. |
| DNS | Documented zone; who can make changes; TTL and critical records identified. |
| Hosting/cloud | Account, billing, region, backups, logs, owners, and deploy process. |
| HTTPS/TLS | Automated certificate when possible; renewal and HTTP→HTTPS redirect. |
| Email - MX | MX points to the correct provider. In Google Workspace, MX routes incoming mail to Google. [S17] |
| Email - SPF | Lists the servers authorized to send on behalf of the domain. [S18] |
| Email - DKIM | Cryptographic signature configured and validated with the provider. [S19] |
| Email - DMARC | Policy and reports; gradual rollout after SPF/DKIM are stable. [S20][S21] |
| Credentials | Individual accounts, MFA, a secrets vault, and an offboarding process. |
| Question | What a mature answer should clarify |
|---|---|
| Whose name is the domain in? | The client is the registrant; the agency only gets the access it needs to operate and configure it. |
| Who manages the DNS? | There's a defined owner, documented access, and a change log. |
| Where is the project hosted? | The architecture, account, costs, backups, logs, and deploy process are known. |
| Who sets up the email? | The proposal specifies whether it includes Workspace/Microsoft 365/another provider and the DNS records needed. |
| What if I switch vendors? | Continuity doesn't depend on a personal account or one exclusive to the agency. |
5. When Will We Get Access to the Code, Accounts, Documentation, and Other Assets?
The right question isn't just “is the code mine?”. Modern projects use open source libraries, SaaS services, licensed components, third-party infrastructure, and sometimes the vendor's own pre-existing assets. Ownership and usage rights need to be spelled out in the contract, not assumed.
The goal is to avoid unintentional lock-in: if the business relationship ends, another team should be able to understand the project, access what was contracted, and keep the operation running within the applicable licenses.
What to ask for before signing:
- Code repository and access policy during the project.
- Contractual definition of intellectual property and third-party licenses.
- Domain, cloud, analytics, email, CRM, and external service accounts set up in structures that suit the client.
- Documentation of architecture, setup, deploy, integrations, and environment variables (without exposing secrets in the document).
- An inventory of dependencies and services with recurring costs.
- A handoff procedure and access revocation when the partnership ends.
- Termination rules, notice period, penalties, and responsibilities spelled out explicitly in the contract.
| Risky answer | Professional answer |
|---|---|
| “The code stays with us for security reasons.” | “The contract defines what's delivered, the repository is accessible, and dependencies/licenses are documented.” |
| “The domain is on our account, we'll sort it out later.” | “The domain is held under proper client ownership from the start, with technical management delegated when needed.” |
| “If it ends, we'll hand over whatever we can.” | “There's a handoff checklist: code, documentation, accounts, backups, credentials/transfers, and access revocation.” |
Contractual note
There's no universal rule that says “30 days with no penalty” or that all third-party code automatically belongs to the client. Termination, assignment of rights, licenses, and intellectual property need to be defined contractually. For significant contracts, specialized legal review is worth it.
6. Extra Questions That Raise the Bar for a Good Hire
Beyond the five core questions, these topics tend to separate a well-made hire from one full of surprises:
| Topic | Questions worth asking |
|---|---|
| Timeline and governance | What are the milestones? What depends on the client? How do scope changes affect timeline and cost? |
| Communication | Who's the point of contact? Which channel? What's the status cadence? How are decisions recorded? |
| Quality | Is there code review, tests, separate environments, and acceptance criteria? |
| Security | What's the security baseline? How are dependencies, secrets, authentication, logs, and incidents handled? |
| Scalability | What are the architecture's current limits? What needs to change if traffic, team, or integrations grow? |
| Accessibility | Does the project account for keyboard navigation, semantics, contrast, and accessibility standards? |
| Measurement | Which events and conversions will be instrumented? Who will have access to the data? |
Security: trade promises for verifiable controls
No responsible team should promise that a site will be “secure against attacks”. Security is risk management. The conversation should be about controls: input validation, protection against injection, XSS, and CSRF where applicable, secure password storage, security headers, dependency management, authentication, authorization, logs, backups, and incident response. [S11][S12][S13][S14][S15][S16]
7. How to Evaluate the Agency's Answers
A mature agency doesn't need to say “yes” to everything. It needs to explain what makes sense for your project, what risks exist, what's included, what depends on third parties, and how operations continue after launch.
Be wary of absolute guarantees: Ranking, security, timeline, or cost with no defined scope are red flags. Prefer clarity, documentation, acceptance criteria, defined responsibilities, and access to essential assets.
Frequently Asked Questions
How long does it take for a project to be ready? There's no universal range. As a planning reference, landing pages tend to be quicker than institutional sites, and products like e-commerce/SaaS require more discovery, integrations, and validation. Ask for a timeline, assumptions, and delivery milestones.
Can I update the site myself afterward? It depends on the type of product and the architecture. If editorial autonomy is a requirement, it needs to be planned for with a CMS/panel, permissions, structured components, and training.
Is SEO included in the development? Confirm the scope. Technical fundamentals should be handled within the project; demand research, content, link earning, tracking, and ongoing optimization may be a separate service.
What about GEO/AEO? Can the agency get me into AI answers? No agency can guarantee a recommendation. The work should improve crawling, indexing, structure, content, evidence, and measurement. At Google, SEO practices remain the foundation for generative experiences. [S02][S03]
Do you integrate CRM, payments, email, and analytics? The agency should map out the integrations the business needs, authentication, webhooks/APIs, security, recurring costs, and support responsibility — without pushing specific vendors when they aren't necessary.
Will the site be secure against attacks? A mature answer describes practices and controls, not an absolute guarantee. Ask for a security baseline, dependency updates, backups, access, logs, and vulnerability handling. [S11]
Is an agency or a freelancer worth more? It depends on the risk and complexity. A freelancer can be excellent for well-defined scopes; an agency may make more sense when the project needs continuity, multiple disciplines, governance, and the ability to substitute people internally.
What happens if I want to switch vendors? The contract and handoff should cover access, code, documentation, accounts, licenses, and responsibilities. Avoid dependencies that would prevent the project from continuing.
Sources and References
The sources below were checked on August 12, 2026. Documentation, features, and policies can evolve — always double-check before implementing technical changes.
- [S01] Google Search Central — SEO Starter Guide
- [S02] Google Search Central — Optimizing for generative AI features
- [S03] Google Search Central — AI features and your website
- [S04] Google Search Central — Introduction to structured data
- [S05] Google Search Central — Changelog: removing the FAQ rich result in 2026
- [S06] Schema.org — FAQPage
- [S07] OpenAI — Overview of OpenAI Crawlers
- [S08] OpenAI — Publishers and developers: FAQ
- [S09] Google Search Console — Impressions, position, and clicks
- [S10] Google Search Console — Search generative AI control / performance
- [S11] OWASP — Top 10 Web Application Security Risks 2025
- [S12] OWASP — SQL Injection Prevention Cheat Sheet
- [S13] OWASP — Cross Site Scripting Prevention Cheat Sheet
- [S14] OWASP — CSRF Prevention Cheat Sheet
- [S15] OWASP — Password Storage Cheat Sheet
- [S16] OWASP — HTTP Security Response Headers Cheat Sheet
- [S17] Google Workspace — Set up MX records
- [S18] Google Workspace — Set up SPF
- [S19] Google Workspace — Set up DKIM
- [S20] Google Workspace — Set up DMARC
- [S21] Google Workspace — Recommended DMARC rollout
- [S22] Registro.br — Administrative tutorials
- [S23] Registro.br — Account management
- [S24] Google Search Central — Article / BlogPosting structured data
- [S25] Google Search Central — Organization structured data
At Zion Software House, the focus is turning scope, architecture, visibility, security, and operational continuity into explicit decisions from day one of the project. If it makes sense for your business, talk to our team and compare the proposal using the questions in this guide. Talk to us.





