Summary
- A first project is a practical test of how a partner works, not only what they produce.
- Watch how questions, changes and problems are handled, especially early.
- Ask for evidence of QA, and confirm ownership and access before the project ends.
Why a first project is the real evaluation
Proposals and calls show how a partner presents itself. A first project shows how it behaves when there is a deadline, an unclear requirement or a change of mind. Choose a project that matters but isn’t your highest-risk client, and decide in advance what you want to learn.
Communication
- Are questions raised early, with enough context for you to answer quickly?
- Do you know the project’s status without having to ask?
- Is there one clear contact responsible for the project, and do they answer the question you asked?
- When something goes wrong, do you hear about it from the partner before you discover it yourself?
Scope handling
Scope will change on almost every project. What matters is how the change is handled. A good partner recognises when a request falls outside the agreed scope, says so plainly, and explains the effect on time or cost before doing the work. Watch for both extremes: silently absorbing changes, which isn’t sustainable, and refusing reasonable clarifications that were implied by the scope.
Review quality
When you first see the build, notice how much feedback concerns basics such as spacing that doesn’t match the design, broken links, or layouts failing on mobile. A partner that reviews its own work before showing it lets your team spend review time on judgement rather than defects. Also notice how feedback is handled: is every point addressed, and are any disagreements explained?
QA evidence
“Tested” can mean a great deal or very little. Ask what was checked and how. Useful evidence includes:
- Which browsers and screen sizes were tested.
- Form and checkout test results, including error states.
- Accessibility checks against agreed criteria. The W3C’s WCAG 2.2, a Recommendation since October 2023, is a common reference point for success criteria such as focus visibility and target size.
- Performance results, with the method stated. Google’s web.dev guidance describes “good” thresholds for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, assessed at the 75th percentile of real page views. Lab tests on staging are useful, but they are not the same as field data from real visitors.
Ownership and access
Before the project closes, confirm that your agency or your client holds what it should: administrator access, hosting and domain access, theme and plugin licences in the right account, design files and source code where agreed. Ownership, confidentiality and whether the partner may reference the work should be written into the engagement, not assumed.
Working fit
Some things don’t fit on a checklist. Did the partner understand your agency’s standards? Did their working hours and response patterns suit your clients’ expectations? Would you feel comfortable putting a more important project in their hands? A short retrospective with the partner after the first project is often more revealing than the project itself.
Checklist
- Questions raised early with clear context
- Status visible without chasing
- Out-of-scope requests identified and priced before work
- Few basic defects at first review
- Every feedback point addressed or explained
- QA evidence: devices, forms, accessibility, performance method
- Admin, hosting, licences and files held by the right account
- Confidentiality and portfolio rights agreed in writing
- Retrospective held after handoff
Sources
Co-Founder & CEO of Softvole. He began as a WordPress developer, later led a delivery team, and now works with agency owners on production partnerships.