Choosing who builds your website is mostly a taste decision. Choosing who builds your booking engine, your customer portal or your internal ordering system is not. One is judged by how it looks. The other is judged by whether it still works at 11pm on a Saturday when forty people are trying to pay you at once.
That is why the usual shortlisting habits fail here. A portfolio proves someone can make a page look good, and checking a web designer's portfolio before you pay is the right test for design work. It says nothing about whether the code behind a system is testable, deployable, documented or safe. If you are still deciding which role you need, settle the split between a web developer and a web designer first.
This guide is the technical half of the decision. It gives you twelve checks you can run yourself, with no coding ability, before you sign anything. Each one asks a team to produce evidence rather than an answer, which is what separates a working engineering habit from a good salesperson. ZenWeb uses the same twelve checks to vet a web development team, our own included.
The video below covers the questions side of this — a useful warm-up before the evidence checks start.
1. Why a Portfolio Review Cannot Vet a Development Team
Quick Answer: A portfolio shows finished surfaces. It cannot show whether the code underneath is tested, documented, or safe to hand to anyone else. To vet a web development team you need evidence about how they work, not screenshots of what they shipped, which is why the checks below all ask for something on a screen.
Every screenshot in a proposal was chosen because it looked good. Nobody screenshots the deployment that failed or the file where the payment keys sat in plain text, and those are what decide your second-year costs. Our web development agency team sees three failure patterns again and again in systems inherited from other vendors, and no portfolio would have shown any of them.
- The system only one person can run. It works, but the setup lives in one developer's head and one laptop. When they leave, the system freezes.
- The system nobody dares change. No tests, no staging, so every fix is a gamble made directly on live data. Teams stop touching it, and it slowly rots.
- The system you do not own. Code in the vendor's private account, servers in the vendor's name, and a licence you never read. Source code ownership for a custom web app is a separate conversation that has to happen before, not after.
None of those three are design problems. They are engineering-habit problems, and habits leave evidence. To vet a web development team you do not need to read a line of code; you only need to watch whether the evidence appears, and how long it takes.
Key takeaway: Portfolios test taste; technical checks test habits. Only habits predict what the system costs you after launch.
Not sure what to ask your shortlist?
We run the same twelve checks on every system we take over, and we will tell you what we would ask in your situation.
See how our web development team works →2. What Are the 12 Technical Checks, and What Does Each Prove?
Quick Answer: The twelve checks cover code and repository, architecture, testing and release, security, documentation, and team composition. Each one names a specific artefact the team must show live on a call. Together they take about two hours, which is nothing against a build that will run your business for five years. Nine of the twelve are pass or fail.
Weighting matters because the risks are not equal. A team with no error monitoring is annoying. A team that cannot restore a backup is a business risk. Below is the table we hand Malaysian SME owners before their shortlist calls. If you are still building the shortlist itself, choosing a web development company in Malaysia covers the commercial half.
| Check | What they must show live | Minutes | Weight |
|---|---|---|---|
| 1. Backup restore | Last night's backup restored into a test environment | 20 | Critical |
| 2. Deploy and rollback | One release pushed, then reversed, on a demo project | 15 | Critical |
| 3. Secrets handling | Where API keys and passwords live, and who can read them | 10 | Critical |
| 4. Repository access | A real repo, its commit history, and who owns the account | 10 | High |
| 5. Code review trail | Merge requests with a second named person commenting | 10 | High |
| 6. Automated tests | A test suite running, with failures shown, not just described | 10 | High |
| 7. Staging environment | A staging URL that mirrors a live client system | 5 | High |
| 8. Setup documentation | A README a new developer could follow on a clean laptop | 10 | High |
| 9. Architecture walk-through | One diagram, drawn live, of a system they built | 15 | Medium |
| 10. Error monitoring | The dashboard where production errors actually land | 5 | Medium |
| 11. Named team | The actual people on your project, on camera | 15 | High |
| 12. Reference call | A client on a system built 18+ months ago, not a new one | 20 | High |
Highlighted rows are the three critical checks — a fail on any one should remove the team from the shortlist. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, custom system engagements. Licence.
Run the three critical checks first. If a team cannot restore a backup, reverse a release or tell you where the payment keys are stored, the other nine are academic. Everything else is a matter of degree; those three are the difference between a bad week and a closed business.
Key takeaway: Two hours of evidence checks costs less than one month of a bad build. Start with backup restore, deploy and rollback, and secrets handling — the three that can end a business rather than annoy one.
3. What Can a Non-Coder Learn From Their Repository?
Quick Answer: Plenty, without reading code. You are reading the shape of the history, not the content. How often commits land, whether a second person reviews them, who owns the account, and whether the README is real. All four are visible in ten minutes.
Most advice here assumes you can read code. You cannot, and you do not need to — a repository is also a record of behaviour, and behaviour is legible to anyone. Ask the team to screen-share a repo from a project like yours, then walk through these five steps in order.
- Look at the commit dates. Steady activity across months is healthy. One enormous burst the week before launch means nothing was reviewed as it went.
- Open the last five merge requests. A second named human should be commenting on each. If every change was approved by its own author, there is no code review, whatever the proposal claimed.
- Check whose account owns the repository. The client organisation, ideally. A vendor's personal account is the pattern behind most disputes in who owns your website, domain and files.
- Open the README and read the setup steps. Ask how long a new developer takes to run the project from that file alone. A confident team answers in hours; a hesitant one answers with a name.
- Search the repo for "password" or "secret". They can do it on screen. Hard-coded credentials in the history is a critical fail, not untidiness.
Step five feels rude. It is not. You are confirming that the keys to your payment gateway are not sitting in a file every past contractor still has a copy of, and a professional team expects the question.
Key takeaway: You are reading the shape of the history, not the code. Burst commits, self-approved changes, a vendor-owned account and a thin README are four visible signals that need no technical skill to spot.
4. Which Architecture Questions Actually Separate Teams?
Quick Answer: The useful architecture questions are about constraints, not technology. Ask what they would remove from your scope, what breaks first under load, and what they would do differently on their last build. Teams with real experience answer with specifics and trade-offs. Weak teams answer with product names.
Asking "what stack do you use?" tells you nothing, because every serious team can name a stack. What separates them is whether they can explain the cost of the choice. If the platform decision is still open, the trade-offs in WordPress versus Shopify versus a custom build are worth reading before the call. Four questions do most of the work when you vet a web development team:
- "What would you cut from this scope for version one?" A team that cuts nothing has not thought about your budget. A team that cuts the right thing has built this before.
- "What breaks first if we get ten times the traffic?" You want a specific component named — the database, the reports, the file uploads — not a reassurance.
- "What would you do differently on your last similar project?" Silence or "nothing" is the answer to worry about. Every real project has a regret.
- "How does this connect to the systems we already run?" Accounting, inventory, payment, delivery. Integration is where SME projects overrun, so settle it before pricing.
Write the answers down. A week later, the specific answers stay useful and the impressive ones evaporate. A decent web app requirements document then turns those answers into something you can hold a vendor to.
A team that cannot name what breaks first has never watched one of their systems break.
Key takeaway: Ask about constraints and regrets, not tools. Specific trade-offs signal real delivery experience; product names signal a sales script.
5. How Do You Check Testing, CI and Release Discipline?
Quick Answer: Ask them to demonstrate it inside 24 hours rather than describe it. A team with a real pipeline can screen-share a test run, a deploy and a rollback the same week. A team without one asks for a fortnight to prepare, which is the answer in itself.
Release discipline is the best single predictor of what your maintenance year feels like. When a team can ship a fix in an hour and undo it in five minutes, small problems stay small. When every release is a manual event, small problems wait, pile up and arrive together. The discovery-to-UAT development process we run exists mostly to make releases boring.
The chart below shows how often shortlisted Malaysian teams actually produced each artefact within 24 hours. The gap between claiming a practice and demonstrating it is the most useful number on this page.
| Practice | Demonstrated within 24 hours | Shown | Claimed |
|---|---|---|---|
| Version control with review | 74% | 96% | |
| Working staging environment | 66% | 91% | |
| Written setup documentation | 54% | 88% | |
| Automated test suite running | 43% | 79% | |
| One-command deploy | 38% | 72% | |
| Tested rollback | 29% | 64% | |
| Production error monitoring | 26% | 58% | |
| Restored backup on request | 22% | 83% |
Bars are scaled to the highest demonstrated share. "Claimed" is the share whose proposal or pitch asserted the practice. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, shortlist evaluations. Licence.
Backups produce the widest gap, and it is the one that matters most. Almost everyone says they back up; far fewer have ever restored one. An untested restore is a hope, not a safeguard, which is the whole argument behind having a backup and restore plan you have actually run. Staging is the second signal: with no staging, every fix you request is made on live data, and keeping staging and live in sync stops being maintenance and becomes a gamble.
Key takeaway: Ask for a demonstration inside 24 hours, not a description. The gap between what teams claim and what they can show is widest exactly where the risk is highest — backups, rollback and monitoring.
Want a second opinion on your shortlist?
We will sit in on one shortlist call and tell you which answers were real.
Compare our web development pricing →6. What Security Practice Should You Insist On Before Signing?
Quick Answer: Six practices are the floor: secrets kept out of the code, a patching cadence, encrypted backups stored away from the server, multi-factor authentication on production, a written map of the personal data you hold, and access that is removed when people leave. All six belong in the contract, not the conversation.
Security is where Malaysian SME expectations have moved fastest. Customers now submit identity documents, payment details and health information through SME systems, and the obligation to look after that data sits with your business, not your vendor. So when you vet a web development team, start where our PDPA compliance checklist starts: know what personal data you hold and where it lives.
| Baseline practice | 2024 | 2025 | 2026 | Change |
|---|---|---|---|---|
| Secrets kept out of the codebase | 51% | 60% | 69% | +18 |
| Multi-factor authentication on production | 44% | 57% | 68% | +24 |
| Encrypted backups stored off the server | 38% | 46% | 55% | +17 |
| Documented dependency patching cadence | 27% | 34% | 45% | +18 |
| Written personal-data map for the system | 19% | 28% | 41% | +22 |
| Access removed when staff leave | 23% | 30% | 37% | +14 |
Percentage-point change from 2024 to 2026. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, vendor security reviews at shortlist stage. Licence.
Everything is improving, and the two weakest rows cost you most later. Without a personal-data map, nobody can answer a customer request or a regulator's question without a fortnight of archaeology. Access that is never removed means every developer who has ever touched your system still holds a key. Both are cheap to fix at contract stage. If your system runs on WordPress, our guide to WordPress website security covers the same ground platform by platform.
Key takeaway: Put the six baseline practices in the contract with dates attached. Security promises made verbally at pitch stage have no enforcement path once the build starts.
7. Who Is Actually Building It, and What Do References Reveal?
Quick Answer: Insist on meeting the named people who will write your code, and take a reference from a client whose system has been running 18 months or more. New-project references only prove a team can start. Old-project references prove they can be lived with, which is the harder test.
Team shape decides what happens on the bad days. One person is fast and cheap until they are ill, which is the whole subject of a freelance web developer versus a software house. The table below groups our client engagements by the shape of the team that built the system, against what the first year looked like.
| Team shape | People who can work on it | Hours to first response | Defects carried past year one | Rebuilt from docs |
|---|---|---|---|---|
| Solo freelancer | 1 | 26 | 14 | 18% |
| Two-person studio | 2 | 14 | 9 | 34% |
| Named pod of four with a lead | 4 | 5 | 4 | 71% |
| Larger house, unnamed rotating staff | 3 | 11 | 8 | 47% |
| Offshore team via an intermediary | 2 | 19 | 12 | 29% |
Highlighted row is the shape with the best first-year outcomes across every column. Median values. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, custom system engagements. Licence.
Size alone is not the answer: a larger house with rotating unnamed staff performed worse than a named pod of four. What predicts the outcome is whether specific people are attached to your project and stay attached. Ask for their names in the contract, and ask what happens if one leaves.
Then get the reference call right with questions a happy-launch story cannot answer:
- "What broke first, and how did they handle it?" Every system breaks. You are testing the response, not the absence of failure.
- "How long does a small change take now, two years in?" This exposes whether the codebase is still workable or has quietly seized up.
- "Did anyone else ever have to work on it?" If a second team has touched it successfully, the documentation is real.
- "Would you hire them again for a bigger system?" The pause before the answer is the answer.
Bring your own staff onto these calls. The operations person who will use the system daily hears different things than you do, which is one reason collaborating properly with designers and developers starts before the contract, not after.
Key takeaway: Named people beat headcount. A pod of four with names in the contract outperformed both solo developers and larger houses with rotating staff on every first-year measure.
8. Vet the Team, Not the Pitch
Quick Answer: Run the three critical checks first, then the other nine across two calls. Ask for evidence on a screen every time. A team that shows you a restore, a rollback and a clean secrets setup in one afternoon is telling you more than any proposal document can.
The reason to vet a web development team this way is simple: proposals are written by the people who want the job, artefacts are produced by the people who do the work. Asking for the artefact costs an afternoon and removes most of the guesswork. Teams that resist are not hiding genius, they are hiding the absence of a habit.
Do it before you sign, because the leverage disappears the moment money moves. If an existing build has already gone wrong, the order changes. A project in trouble needs a rescue plan for a stalled web development project first, then a handover plan for switching web developers without breaking your system. Vetting the replacement comes after both. Our web development team in Malaysia is happy to be vetted on these same twelve checks.
Ready to vet your shortlist properly?
Book a free 30-minute session — we will walk through your requirements, tell you which of the twelve checks matter most for your system, and give you the exact questions to put to every team you are considering.
Get my free vetting session →
9. Frequently Asked Questions
1. How do I vet a web development team if I cannot read code?
You watch for artefacts, not code quality. Ask them to restore a backup, deploy and reverse a release, show a test suite running, and open a repository so you can see commit dates and review comments. All of that is visible to a non-technical owner: you are judging whether the thing exists and how long it takes to produce. If you want a technical second opinion, borrow one for two hours rather than skipping the checks. Rates and shortlisting sit in our guide to developer rates and vetting.
2. How long should vetting a development team take?
About two hours per shortlisted team, over two calls. The first covers the three critical checks — backup restore, deploy and rollback, secrets handling — plus the repository walk-through. The second covers architecture, testing, security and team composition, then arranges the reference call. Teams that need more than a week to schedule the demonstrations are usually building the artefacts first.
3. What is the single biggest red flag when vetting a development team?
A backup that has never been restored. On our client sample, 83% of shortlisted teams claimed reliable backups and 22% could produce a restore within 24 hours. That gap is where most catastrophic SME data losses live. A close second is source code held in the vendor's personal account rather than yours, because it turns every future disagreement into a hostage negotiation. Both are cheap to fix before signing and very expensive afterwards.
4. Should I pay for a paid trial before the full project?
Often, yes. A small paid piece of work — one screen, one integration, one report — costs a fraction of the build and shows their real working rhythm: how they estimate, communicate and handle a change request. It also produces a code sample from your own project rather than someone else's. Keep it small enough that walking away is easy.
5. Do these checks apply to a normal website project too?
Partly. A brochure site still needs backups, ownership, staging and documentation, so checks 1, 3, 4, 7 and 8 apply. Testing, architecture and team composition matter far less with no live data to protect. For a marketing site, the checklist for approving a new business website fits better, and the red flags of a bad web design company covers the commercial warning signs.
