The staging URL still had lorem in the footer, the contact form posted to a 404, and the only metadata in the rendered HTML was a default title left over from the theme.
That is the usual failure when a founder hires on a Figma file and a weekly Slack screenshot. Philippines web design work can be excellent. It can also ship a pretty shell with no owner for the live head, the form action, or the repo. The checks below are the ones we run before anyone writes a line of production code.
Who actually ships the rendered HTML
Ask for three live URLs they shipped in the last year, not three case-study PDFs. Open view-source on each. You are looking for real markup: semantic landmarks, one h1, titles that match the tab, and components that look like they came from a system rather than a page-builder export.
If the HTML is a soup of utility classes with no structure, the next person who has to change a heading will hate the job. If the HTML is clean but the content is still dummy text six weeks after “launch”, they never finished the handover.
Ask, by name, who writes the templates. Designer, front-end, or a PM pasting into a theme. A web design company in the Philippines that cannot name the person who last touched the layout file is already a risk. We still start every review in the source, because that is what Googlebot and your next developer both have to live with.
Forms, endpoints and what happens on submit
A form that looks finished in the browser is not a form. Check the action, the method, the spam layer, the error states, and the thank-you path. Submit it. Use a throwaway address. See whether the payload hits a real endpoint or a mailto that dies on mobile.
Ask where the lead goes on day two: inbox, CRM, sheet, or nowhere. Ask who owns the failure email when the SMTP credentials expire. Ask whether file uploads are validated server-side or only in the browser.
We have walked founders through staging sites where the “Get a quote” button was a dead `<a href="#">`. That is not a polish issue. That is a missing piece of the build. Put form behaviour in the statement of work as a testable item, with a named environment, not as “contact section included”.
Metadata that exists in the head, not only in the CMS
Open the live head. Title, meta description, canonical, Open Graph, robots, and any JSON-LD should be in the rendered HTML you can read without running a special crawler. If the CMS has a field for a title and the live document still shows the theme default, the mapping was never built.
Ask how a new landing page gets its metadata. If the answer is “the SEO person will add it later”, later usually means never. Metadata is part of the template, not a ticket after launch.
For JavaScript-heavy stacks, ask whether the important tags are present in the first HTML response or only after a client render. You do not need a lecture on crawlers. You need a yes or no on what view-source shows today.
The stack you will maintain after launch
Stack choice is not a mood board. It is who can edit a page in six months, how fast the HTML arrives, and whether a content change needs a developer.
Content-led marketing sites often belong in Astro. App-like UI, dashboards, and authenticated flows often belong in React. The wrong default is whatever the vendor already has a theme for.
If the brief is a marketing site with light interactivity, walk through our Astro development work and ask the candidate to explain, in their own files, how a new route, a new layout, and a new metadata field get added. If the brief is a product UI with state, routing, and client data, do the same against our React development work and ask how they handle server rendering, hydration, and what the first HTML actually contains.
A philippines web design pitch that cannot defend the stack in those terms is selling hours, not a site you can run.
Page experience against Google’s own bar
A Lighthouse PDF from a quiet staging server is not evidence. Ask for field data or a plan to collect it. Ask which template is the risk: the blog index with twelve hero videos, the product grid, or the contact page with a map embed.
Google’s current signals for how a page feels to a real user sit in the Google page experience documentation. A competent shop should map LCP, INP, and CLS to specific files and third-party tags, not to a screenshot from last Tuesday.
Ask what they will refuse to put above the fold. Ask how fonts are loaded. Ask whether the cookie banner, the chat widget, and the tag manager container are in the critical path. If they shrug, the Core Web Vitals conversation will start after you have already paid for the widgets.
Handover, repo access and the keys to the domain
Handover is the job, not a zip. Before you sign, write down what you will hold on the last day: git repo with history, production and staging env vars, CMS users at the right role, DNS and registrar access, hosting billing in your name, a component list, and a one-page note on how to add a route.
If they want to keep the repo, you do not own the site. If they want to keep the registrar, you do not own the name. If the only “documentation” is a Loom of someone clicking around the CMS, the next change request will cost more than the original build.
We treat handover as a checklist with owners, not a courtesy email. Ask to see a redacted example from a previous client. If they have never done one, you will be the first, and you will feel it.
Scope, revisions and the silent extras
The statement of work should name templates, not “up to ten pages”. Ten pages of what: unique layouts, or ten copies of the same inner page with a different h1? Name the forms. Name the languages. Name the redirects from the old URLs. Name who enters the real copy, who supplies the images, and who compresses them.
Revisions need a number and a definition. “Unlimited tweaks” is how a six-week build becomes a four-month argument about button colour. Content that arrives late is not a design defect. Put a freeze date in writing.
Ask what happens when legal wants a new disclaimer on every template. Ask who writes the 404, the 500, and the offline state. Those pages are part of philippines web design whether they were in the mood board or not.
Local team, timezone and who is on the call
A web design company in the Philippines can be a senior pair you speak to every week, or a sales layer in one city and a rotating bench in another. You need to know which.
Ask who will be on the kickoff, who writes the HTML, and who you ping when staging is down on a Friday. Ask for overlap hours in your timezone. Ask whether copy is reviewed by someone who writes English for your market, not only someone who can close a ticket.
British-led delivery with a Philippine build team is a real model. Unnamed “the team” is not. If the only person who can explain the stack is unavailable after signature, you hired a brochure.
The first call that should feel uncomfortable
A useful first call is slightly awkward. You will ask to see source, not slides. You will ask who owns the repo. You will ask what they will not build. You will ask for a staging URL from a finished job and you will submit the form while they watch.
Bring the current site’s worst template. Ask how they would rebuild that one page, including metadata, heading order, and the form. If they jump to “we would do a full redesign”, they are selling a project, not solving the failure in front of them.
Write down the answers. The shop that gets impatient with those questions is the shop that will skip them in the build.
When a scoped audit is the next useful step
If the candidate cannot show live HTML, working forms, metadata in the head, a defended stack, a page-experience plan, and a real handover, stop. Do not “give them a small page to try”. Small pages still need the same plumbing, and you will pay twice when you replace them.
If the fit looks real, the next useful step is not a full redesign quote. It is a scoped audit of the current site and of their proposed approach: templates, rendered HTML, forms, metadata, stack, and handover. We do that work when the founder is ready to decide, not when someone needs a deck for a board meeting.
Send the live URL, the three competitor URLs you actually care about, and the one user action that must work on week one. If that package is honest, we can tell you whether to hire, what to put in the statement of work, and which parts of the current site should survive.
That is the decision. Check the source, check the form, check the head, check the keys. Then hire, or do not.
