When you shortlist a web build team, portfolio screenshots only prove they can shape a page. The better test is which systems they have already delivered. Use four checks: similar system cases, whether the figures come from the client, whether source code is transferred, and whether you can run the admin area yourself.
Teams comparing pitches often report the same feeling: every portfolio looks refined, yet none stands apart. That is normal. Large hero images, open space, and short taglines are within reach of most studios, so screenshots alone rarely show who fits.
The hard part is that the jobs a site must do rarely live on the homepage. Registrations must be captured, quote requests must arrive, members must sign in, and editors must update copy themselves. Those functions sit behind login and inside the admin tools, outside what a portfolio image can show.
Why Layouts Alone Hide the Gap
Layout is the part of a site that is easiest to imitate. In one design wave, homepages from separate studios can look nearly the same. A feature labeled registration, though, may be only a form, or it may cover seat limits, waitlists, payment, reminders, and exported name lists.
In practice, a firm often hires the studio with the most striking homepage, then learns halfway through that the team has never built member or quote flows. Requirements keep shifting, and the launch date keeps moving. Polished visuals and reliable systems are separate capabilities.
| Comparison | Layout samples only | System case review |
|---|---|---|
| What it proves | ! Able to design screens | ✓ Able to turn a workflow into a site |
| Is the gap clear | ✗ Homepages tend to look alike | ✓ Depth shows up in a few questions |
| Can results be checked | ✗ Figures are usually missing | ✓ Client comments can be compared |
| Can the admin be tested | ✗ Screenshots do not show it | ✓ A live demo can be requested |
| Relevance to your needs | ! Style reference only | ✓ Similar cases can be matched |
| Best fit | Brand sites updated a few times a year | Sites that need signup, quotes, members, or orders |
Criterion One: Matching System Work
The most direct step is to recast your needs as a system type, then look in the portfolio for cases of that type. The four records below are useful comparisons:
| Project | System type | Earlier problem | What the site fixed |
|---|---|---|---|
| 龍承古泉網 | Live bidding | Auctions ran on-site only, once each week | Buyers bid live by phone or computer, with no venue limit |
| 端泰股份有限公司 | Multi-brand site and online signup | Five brands relied on phone calls for signup and repair status | Brands share one site; classes and events accept online signup |
| 捷寶JYEBAO | English product catalog | Overseas inquiries stayed under ten a month | Five series are grouped, searchable by spec, with technical files to download |
| 中華寬頻股份有限公司 | Newsletter and results pages | The firm needed to show past work and keep reaching prospects | Results pages support sales decks; newsletters are managed in the admin |
Once you have a list like this, pick the case closest to your need and ask how the flow was designed, what went wrong, and why that fix was chosen. A team that has done the work can describe the details; a team that has not usually answers only that they could do it too.
Criterion Two: Who States the Results
Writing that conversion rose sharply is easy. What matters is who said it. Figures claimed only by the vendor lack a source. Comments from the client, with a named company and job title, are far more useful.
The outcomes in the four cases above are drawn from client comments:
- Mr. Wu, principal of 龍承代拍社: after the bidding platform went live, weekly auctions rose from one session to three, concurrent online bidders stayed above one hundred, and the close rate climbed by more than sixty percent.
- Ms. Zhou, marketing planner at 端泰: after five brands were brought onto one site, online signups reached three times the phone signups, and self-serve repair tracking cut service calls sharply.
- Ms. Li, sales manager at 捷寶: after the English catalog launched, overseas inquiries grew from fewer than ten a month to more than fifty, and engineers could locate products by specification, which improved efficiency.
- Mr. Chen, project manager at 中華寬頻: after the new site and newsletter launched together, online inquiries from business clients more than doubled, the results pages became the material sales decks cited most, and the brand looked more professional.
In a pitch, ask directly whether the client supplied the figure. A clear source means the team will stand behind the result. A vague reply means treat that number as background only.
Criterion Three: Code and Rights
Even a strong system will stall later expansion or a change of maintainer if the contract is vague. Confirm two points: whether source code is handed over, and how copyright and usage rights are set.
Market practice varies. What matters is a written deal. A sound arrangement transfers the full codebase and states who owns the copyright and what usage rights the client keeps, so later feature work or a handoff to another team is not blocked.
Criterion Four: Self-Managed Backend
After reviewing system cases, the last step is to have the team operate the admin area in front of you. Once a site is live, the usual work is content change: swapping campaigns, adding products, and sending newsletters. Calling the original vendor every time adds both delay and cost.
On an auction site, member records, saved and watch lists, payment links, and notice emails can all be run from one admin across every session. Newsletters can likewise be composed and sent on a schedule from the backend. That is what self-managed administration looks like in practice.
Six Questions to Ask in a Pitch
| Question | A solid answer | A warning answer |
|---|---|---|
| Have you built a system like mine? | Points to a case and explains the flow | We have not, but we can build anything |
| Where did this result come from? | From a client comment, with the original wording | Roughly that, with no source |
| Will the source code be delivered? | The contract lists scope and timing | We can discuss that later |
| How are copyright and usage set? | Ownership and scope are written down | The contract never mentions them |
| Can you demo the admin live? | Walks through a normal update on the spot | Offers only screenshots, or says it is simple |
| How are changes handled after launch? | Explains the warranty period and fix scope | We will quote when the time comes |
Use this table as a checklist in the pitch: the first half tests system skill, and the second half checks whether the working terms are written into the contract.
When Layout Review Is Enough
Not every site needs a system. If the site is mainly a brand showcase, is updated only a few times a year, and has no signup, quote, member, or order flow, reviewing visual style and communication is enough. There is no reason to pay extra for system work you will not use.
If the site must take something in — signups, quotes, orders, or member data — it is worth spending half an hour on the other side’s system cases. That time often prevents months lost when a build stalls because a required flow cannot be delivered.
Close: Check Systems Before Layouts
An attractive homepage has value, but it is only the front door. When you choose a web build team, keep three points in mind:
- Turn needs into a system type first: then find similar cases and ask for the flow details
- Ask where result figures come from: numbers taken from client comments are the ones worth using
- Confirm code and the admin yourself: put delivery terms in the contract, and watch a live admin walkthrough
If you are still listing which functions the site needs, separate brand display from process systems. Once members, signups, or quotes are involved, compare system records before you compare layouts.
