2026 Custom Website Development: What Exactly Should You Test Before Launch? What Happens If You Miss One Item?

Why is pre-launch testing the most likely part to be cut in a project?

At the project delivery site, testing is usually the first item to be cut from the budget list. The client pushes for launch, the development team thinks 'as long as it runs,' and once both sides compromise on time, testing shifts from a 'mandatory delivery action' to an 'extra task done if time permits, skipped if not.' The result: functionality is tested once, while all other layers are left to luck.

What's more, many custom development projects have no dedicated testers. Often, developers click through the site themselves, or ask the client's business staff to manually walk through core flows. In such cases, the issues found are usually limited to 'it opens without errors' and 'buttons are clickable.' As for what might happen on different devices, networks, or operating habits, there is basically no awareness.

• Common ways testing gets compressed: only test the latest version of mainstream browsers, not older versions or embedded mobile browsers;
• Only test core functional flows, not abnormal input, disconnection, or weak network conditions;
• Only test content display, not the backend publishing flow or permission controls;
• Only test data on launch day, not traffic pressure or data backup and recovery.

For example, a corporate website was only tested on desktop browsers before delivery, ignoring compatibility with the built-in browser in WeChat on mobile. On the second day after launch, a large number of feedback reports about form submission failures came in. It took several days to fix the adaptation issues, far exceeding the half-day of testing time that was originally saved.

For custom website development before launch, what five layers should testing cover?

Based on common delivery practices in 2026, we break pre-launch testing into five layers: functionality, compatibility, performance, security, and content flow. These five layers are not selected based on project size, but on whether users can use it normally, dare to use it, and are willing to use it.

1. Functional testing: Every core flow must be walked through, including normal input, erroneous input, and boundary values. The acceptance criterion: run the core flow in a real environment; don't just click buttons to see if they redirect.
2. Compatibility testing: Cover mainstream browsers, system versions, mobile and desktop. Key areas to test: WeChat's built-in browser, domestic browsers, and older system versions. The acceptance criterion: on the minimum configured device agreed upon in the project, the layout does not break and interactions can be completed.
3. Performance testing: Focus on first-screen loading time, API response time, and behavior under concurrency. The acceptance criterion: under common network conditions, a first-screen loading time within 3 seconds passes, but specifics depend on the project type.
4. Security testing: Check common risk points such as login, permissions, input validation, data encryption, and sensitive information leakage. The acceptance criterion: at minimum, go through the relevant items in the OWASP Top 10 for this project.
5. Content and flow testing: Verify that content published from the backend displays correctly, and that the complete flow of forms, payments, and third-party APIs works. The acceptance criterion: publish a real piece of content and verify it completely from backend to frontend display.

The core reason for this division is that each layer has different rework costs and impact scope. Functional issues are point-based, compatibility issues are systemic, performance issues affect experience, security issues affect reputation, and content flow issues directly determine whether the business can close the loop. Only when all five layers pass can you say 'testing has been done properly.'

How do you know testing has been done properly? An actionable acceptance checklist

Many clients don't know what to ask for during acceptance and just say 'test it well.' Instead, ask for a test report and check it item by item against the following list. This is also a common method we use with clients in projects, which can be called the 'Five-Layer Acceptance Check' approach.

• Functionality layer: Have all core flows been tested? Are there prompts for abnormal input? Is there a limit on repeated submissions?
• Compatibility layer: Has testing been done according to the agreed device list? Was WeChat's built-in browser tested? Are older system versions still supported?
• Performance layer: Is the first-screen loading time within a reasonable range? Do APIs have timeout prompts under weak network conditions? Are images lazy-loaded?
• Security layer: Does the backend enforce strong password policies? Is there permission isolation? Is HTTPS used? Is there basic protection against SQL injection and XSS?
• Content flow: Can articles published from the backend display correctly on the frontend? Where does form data go after submission? Is the payment callback handled?

What counts as acceptable? Each item should have a clear 'yes/no' record, with test screenshots or logs as evidence. If the developer only says 'we tested everything' without specific records, we recommend not accepting it. In projects, we suggest clients include 'test report' as a deliverable in the contract stage; otherwise, there is no basis at acceptance.

If testing is not complete before launch, how serious can the consequences be?

The consequences are not just rework and code fixes; they also include operational costs, user trust, and even compliance risks. Based on an experience range, let's do the math: if you test carefully before launch, it might take an extra 3 to 7 working days. If you wait until after launch to fix issues, the same compatibility or security problem could take twice as long, plus additional hidden costs like server log analysis, user complaint handling, and emergency releases.

Here's a common counterexample: a brochure website only tested functionality, not image loading or caching strategy. On launch day, because images were not compressed, the homepage took 8 seconds to load, and the user bounce rate rose immediately. It took two weeks of image processing and CDN configuration to get the speed back under 3 seconds. The key issue is not that 'the website couldn't go live,' but that 'users closed it on the first screen.'

• Testing seriously before launch: Spend a few extra days, but basically no rework needed after launch, lower maintenance costs.
• Rushing to launch: Might go live a few days earlier, but problems occur frequently after launch, with higher fix time and communication costs.

This comparison repeats itself in almost every project. We suggest using the experience rule that 'around 85% or more of issues can be caught during the testing phase,' but this specific number is an experience range, not a commitment.

Applicable scenarios and boundaries

Not all websites need the full five-layer testing. If you are building a purely static display page, a temporary campaign page, or an internal tool without payment and login features, you can appropriately trim the scope. For example, for a pure display page, you can do functionality, compatibility, and content flow testing, and simplify performance and security.

However, for corporate websites, e-commerce sites, SaaS products, or any site involving user data, payments, or membership systems, do not skip any of the five layers. In 2026, users' requirements for websites are no longer just 'it opens'; they also include response speed, privacy protection, and mobile experience.

If the budget is tight, at least do functionality, compatibility, and content flow testing; deeper performance and security testing can be done in iterations after launch.

Frequently Asked Questions

How long does testing take for custom website development?

For a small brochure site, it generally takes 2 to 3 working days; for a medium-sized functional site, 5 to 7 working days. The specific time varies based on the number of functional points and device coverage. This is an experience range.

Is security testing mandatory? How much higher will the cost be?

It is mandatory for websites involving login, payments, or user data. The cost, depending on project complexity, generally accounts for about 5% to 10% of the total development cost, which is usually less than the cost of handling a data breach after an incident.

Can I test only functionality without compatibility?

Not recommended. In 2026, mobile access accounts for a very high proportion. Testing only on desktop can easily lead to layout issues on mobile browsers, especially in WeChat's built-in browser.

What should be included in the test report?

At minimum, it should include the test environment, test scope, number of test cases, pass/fail items, list of remaining issues, and fix status, so the client can verify during acceptance.

Is there a big difference between self-testing and third-party testing?

The main difference is perspective. Your own team tends to test based on development thinking, while a third party tests based on user habits. If the budget allows, it is more cost-effective to have a third party do security and compatibility testing.

Before launch, first ask the developer for a test report and check it item by item using the 'Five-Layer Acceptance Check' method. For a low-cost display page, at least do functionality, compatibility, and content flow testing. Put testing in the contract and delivery checklist so you have a clear basis for acceptance. This is much more cost-effective than trying to fix problems after launch.