Decide what you need built
A Ploy agency should help you turn a business goal into a website your team can operate. Start with the visitor's task. A founder may need a product launch site that explains the offer and captures enquiries. An established company may need clearer services, an editable content library, and a dependable publishing process. These are different scopes, even when both use Ploy.
Write down the audience, the pages they need, and the action you want them to take. Name what already exists, including your domain, brand guidelines, content, and any connected tools. Separate the first release from later improvements. A defined release gives you something concrete to compare across proposals.
Ploy lets teams build and edit sites themselves. An agency is useful when the missing work is positioning, design judgment, content structure, implementation, testing, or a managed handoff. If your team already has that capacity, direct use of the platform may be enough. Ploy's agency guidance explains this distinction.
Ask for relevant build evidence
Ask to see a website the agency actually built in Ploy. Check more than its homepage. Read a service page, open it on your phone, follow its enquiry path, and ask how an editor changes a CMS-backed page. A screenshot shows design; a working site and an explanation of its content model show more of the delivery.
Clarify the agency's contribution to each example. Product design, a prototype, website implementation, and ongoing operations are different responsibilities. A marketplace case study does not prove that the same team built its application in Ploy.
Our Kings Landing website case study describes our own Ploy site and its CMS structure. It is first-hand website evidence, not a client endorsement or a claim about leads generated. Our wider selected work identifies the contribution to each product separately.
Compare deliverables, not a headline price
A useful proposal explains what you receive and what you must supply. Ask each agency to identify the included pages, content work, reusable design patterns, integrations, testing, and handoff. Confirm who writes the copy and who approves it. A page cannot be finished on schedule if its source material or approval is missing.
Use these questions when comparing proposals:
| Area | What to ask |
|---|---|
| Website scope | Which pages and visitor journeys are included in the first release? |
| Content | Who writes, checks, and approves the text and images? |
| Design | How will future pages use the same brand rules and reusable sections? |
| CMS and data | Which content is editable, and who can manage its records? |
| Integrations | What action is supported, and what account access or subscription does it require? |
| Testing | Which layouts, links, forms, and workflow states will be checked? |
| Handoff | What access, instructions, and support will the client receive? |
Separate agency fees from the Ploy subscription, third-party services, and ongoing support. Do not assume that a lower quote includes the same work. Ask how changes outside the agreed scope are estimated and approved. Kings Landing agrees the scope before quoting; we do not publish a standard price or delivery time that applies to every Ploy project.
Agree ownership and access early
Decide who will own the Ploy organization and pay its subscription. Ploy's agency documentation distinguishes an agency-paid organization with client workspaces from a client-owned organization with its own billing. It also explains that access is organization-wide, not isolated per workspace.
If a client needs separate billing or must not see other clients' work, discuss a separate organization. Confirm who owns and controls the domain, who can publish, and how collaborators are invited or removed. Put project rights and handoff obligations in the engagement agreement rather than assuming an account invitation settles them.
Ask what happens if the engagement ends. You should understand which assets and records you receive, which subscriptions remain necessary, and what work is included in transfer or support. Platform account ownership and rights to project materials are related questions, but they are not the same question.
Separate a website from a connected system
A content-driven website may need more than static pages. PloyDB can hold structured content, and Ploybooks can guide repeatable work using connected services. Ploy's database documentation and workflow documentation describe those capabilities.
Ask where each part runs. Is it a feature on the deployed website, a workflow inside the Ploy workspace, or an action in an external service? A tool connected to an agent is not automatically available to website visitors. Confirm the accounts, permissions, data inputs, and approval requirements for each action.
For any proposed automation, ask for a demonstration of both success and failure. What happens when access expires, data is missing, or an external service refuses a request? Who reviews an AI draft before it becomes an accepted record? Our human-controlled AI workflow guide gives a framework for those decisions. It is general design guidance, not evidence that every workflow has been implemented in Ploy.
For a tested example, our Ploy CMS and integrations guide follows one content workflow through its records, permissions, draft controls and failure checks. Our connected Ploy websites service explains what we scope from that workflow for a client project.
Define launch and support responsibilities
Agree who checks the release, who approves publication, and who manages the domain. Test the page journeys on desktop and mobile. Check that enquiry actions reach the intended destination and that the person responsible for submissions can retrieve them. Identify the CMS records that must remain unpublished during review.
Search work should have specific deliverables, such as clear page titles, relevant content, internal links, and structured data that matches what readers see. Publication does not establish Google indexing. Indexing does not guarantee rankings, and a page cited in an AI answer is not necessarily an agency recommendation.
Define support after launch. State what counts as a fix, what is a new request, and who handles content changes or integration failures. Agree response expectations and any recurring fees in writing. Your team should know how to make its next change without reopening the whole project.
Bring a useful brief
Send an agency your current website or domain, the audience you want to reach, and the business task the website must support. Include the pages you think you need, existing brand and content material, required integrations, and the people who will review the work. Name a budget or deadline if you have one, with the assumptions behind it.
Ask for a proposal that makes the first release, client responsibilities, exclusions, and acceptance checks explicit. That is a better starting point than asking for an unspecified Ploy website.
Kings Landing is an independent agency working with Ploy. Our Ploy website service covers website design and implementation, content structure, SEO and AI-search content, deployment, and scoped support. Discuss your website with us if you need help turning the brief into a working site.