A Free Website Scorecard, Built in One Morning
A shop owner I talked to last month runs Facebook ads every day. Her website takes about seven seconds to open on a phone. Most of the people who tap her ad leave before the first product appears, and she has no idea, because on her office Wi-Fi the page feels fine. She is not unusual. She is the median.
That conversation is why goecomaz.com, my web-services side business, now has a page called Chấm điểm: paste your website address, wait about half a minute, get a score from 0 to 100 and the three things to fix first. No sign-up, no phone number to see the result. This post is about how that page was designed and built, told from the project manager's chair, because the interesting parts were not the code.
The rubric is the product
The technical core is boring on purpose. Google's PageSpeed Insights API measures the site on a simulated phone for free. The rest is my server fetching the homepage and reading it. The whole difficulty was deciding what to read, and how to say it back to a person who sells rice cookers, not software.
I wrote the rubric before a line of code, and it went through my own approval gate like any client deliverable. Six checks, weighted by what actually costs a small shop sales:
| Check | Weight | What it really asks |
|---|---|---|
| Speed on a phone | 30% | Does the first product show before the customer gives up? |
| Visible on Google | 20% | Title, description, canonical, sitemap. Can Google name this shop? |
| Secure and trustworthy | 15% | HTTPS, no mixed content, browser not flagging anything. |
| Easy to buy | 15% | Price on the page, a buy button, a cart, product schema. |
| Easy to reach | 10% | A tappable phone number, Zalo, Messenger, a short form. |
| Legally in order | 10% | Business name, tax number, return and privacy policies in the footer. |
Two decisions in that table matter more than the rest. Speed gets the biggest weight because it is the leak nobody sees from their own desk. And "legally in order" exists at all because Vietnam's 2026 tax and e-invoice changes mean a footer with a tax number is now something customers and marketplaces both look for. A developer would never put that in a technical audit. A customer notices it before they pay.
The verdicts are written in plain Vietnamese and they are never mocking. "Opens fine but a bit slow; people scrolling past on Facebook rarely wait more than three seconds" tells the owner the same thing as a red Lighthouse number, without making them feel stupid for not knowing what Lighthouse is.
Three product calls I would defend
Website only, for now. Shopee and TikTok Shop links are rendered by JavaScript and block crawlers, so half the rubric would come back empty. Shipping a half-blank scorecard for the channels most Vietnamese sellers care about would have been worse than saying, honestly, "paste your own website; marketplace scoring comes later."
Show the score before asking for anything. The obvious lead-generation move is to hide the result behind a phone number. I have seen that page. It reads as a trap, nobody shares it, and it teaches the visitor that the business starts by withholding. So the score and the three fixes are free, and the phone field only appears if you want the full report over Zalo.
Reuse the boring plumbing. The plan called for a new form to collect leads. Halfway through I dropped that and pointed it at the existing contact form on the site. Zero new setup, every enquiry in one place. Deviations from the plan are fine when they remove work; they just have to be written down.
What broke between 9:08 and 10:30
The estimate said two or three days. The whole thing, from approved rubric to live page with a Facebook post out, took one morning. Almost none of that morning went into features. It went into four small things that only show up when a real key, a real server, and a real person are involved.
The API key that refused its own site. The PageSpeed key worked locally and returned "permission denied" in production. The useful clue was buried in Google's error text: "requests from referer [empty] are blocked". The key had been created with an HTTP-referrer restriction, and a server-side call has no referrer. Fix: application restriction set to none, API restriction narrowed to PageSpeed only. Fifteen minutes of my own attention, which no amount of AI could have skipped, because the key lives in my Google account.
A regex that could not see a price. Prices in Vietnamese end in "đ". The check used a word boundary after it, and in JavaScript a word boundary after a non-ASCII letter never matches unless the regex has the unicode flag. Every price on every page was invisible. A unit test on five fixture pages caught it before any customer did. Tests at the boundary, again.
The rate limiter that locked out the founder. To protect the free API quota, each IP got ten scores an hour. I was polling production from home to verify the fix above. My wife's phone and my laptop share that IP. The first person to hit the limit was the person who paid for the tool. The rework was simple and better: check the cache before counting a hit, so re-scoring a page costs nothing, raise the ceiling, and tell the visitor how many minutes to wait instead of a bare error.
The build that only failed on the server. The test runner wanted a newer Node types package than the project had. Locally the install had been run with a flag that quietly ignores that conflict. Vercel's clean install did not. One dependency bump, one regenerated lockfile, one lesson written into the deployment checklist: never push what only installs with a flag.
The part that stings
The first real shop we scored came back at 67. Fast enough, decent on Google, but "easy to buy" scored 25: no price on the page, no buy button, customers had to message to ask. That is exactly the kind of leak the tool was built to find.
Then I scored my own site. goecomaz.com got 76. No cart, no product schema, no tax number in the footer, no policy pages. The scorecard is honest even when the answer is inconvenient, which is the only way a free diagnostic earns any trust. The policy pages are now on my own backlog, ranked by the same tool that ranks everyone else's.
What a PM takes from a morning like this
The rubric took longer than the code, and it should have. A scoring tool is a point of view about what matters, dressed up as a number. Get the point of view wrong and the fastest build in the world just delivers a wrong answer quickly.
Almost all the delay was at the seams: a key, a server, an install flag, a shared IP. None of it was hard. All of it needed a person who owns the accounts and checks production with their own phone. That is the same finding as last time: the work gets cheap, the definition of done does not.
If you run a shop with its own website, the page is at goecomaz.com/cham-diem. If the score looks wrong, send me the domain and I will look at it by hand. The tool is a first opinion, not a verdict.
Nguyễn Hải Nam
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.