Our QA Checklist Before Every Launch: 34 Items We Check

Let me be honest with you. Most QA checklists on the internet are written by people who have never actually sat in a bug war room at 11 PM, trying to figure out why a payment flow breaks only on Samsung devices running Android 12. They give you generic advice like "check your buttons" and "test your forms." Useful? Barely.

We are a software development and testing company. We have delivered 700+ projects, across industries like healthcare, e-commerce, SaaS, marketplace platforms, and enterprise software. And every single time, before we hit the launch button, we run through 34 checks. Every. Single. Time.

This article is not theoretical. This is the actual process we use internally, from small WordPress sites to HIPAA-compliant platforms handling sensitive patient data. We're putting it all out here because we genuinely believe thorough QA services are the single biggest factor that separates a good software product from a broken one.

Let us walk you through it.

Why a Pre-Launch QA Checklist Actually Matters

Before we get into the list, let's address something real. A lot of teams think QA is the last thing. You code it, you style it, you test it once, and you ship it. That mindset is how bugs end up on production servers.

The cost of fixing a bug in production is anywhere from 6x to 100x more expensive than catching it during development. That is not a made-up number. It is widely reported across software engineering research and we have seen it personally. A broken checkout flow on an e-commerce site doesn't just cost you a developer's time, it costs you actual lost revenue, customer trust, and sometimes regulatory penalties.

Our software testing services exist precisely because we have seen what happens when teams skip this step. So here is the checklist we personally use.

The Full 34-Item QA Checklist We Run Before Every Launch

Section 1: Code Quality and Review (Items 1 to 6)

These first six checks happen at the code level, before anything even reaches a staging environment.

1. Line-by-Line Code Review

We literally go through the code. Every pull request gets reviewed by at least one other developer who did not write it. We look for logic errors, hardcoded values, missing error handling, and anything that looks like it was written at 2 AM and never revisited. This is not optional for us, even on small projects.

2. Static Code Analysis

We run automated tools like ESLint, SonarQube, or PHPStan (depending on the stack) to catch issues the human eye misses. Things like unused variables, null reference risks, and code complexity scores that indicate a function is doing too much. The tool does not replace the human review. Both happen.

3. Dependency and Package Audit

Every third-party package your application uses is a potential vulnerability. We run npm audit, Composer audit, or equivalent tools to identify outdated or compromised dependencies. We have caught critical security vulnerabilities this way on projects that looked totally fine from the outside.

4. Removal of Debug Code and Console Logs

This sounds basic but you would be surprised. Console.log statements, commented-out test code, hardcoded test API keys, and debug routes all need to go before launch. We have a specific pass just for this.

5. Environment Configuration Check

Dev, staging, and production should have separate configuration files. We verify that the production build is using production API keys, correct database connections, proper error logging (not user-facing errors), and that no debug flags are set to true.

6. Code Coverage Review

We do not demand 100% coverage on every project. That is impractical. But we do check that critical business logic, payment processing, authentication flows, and data handling have meaningful test coverage. If a function processes money and has zero tests, that is a blocker for us.

Section 2: Functional Testing (Items 7 to 13)

This is where we verify the software actually does what it is supposed to do.

7. Core User Flow Testing

We map out the most important thing a user can do in the application and test it end to end. For an e-commerce store, that is browse, add to cart, checkout, and receive order confirmation. For a SaaS app, that is register, onboard, use the primary feature, and log out. Every step, manually tested.

8. Form Validation Testing

Every input field needs testing with valid data, invalid data, empty data, and edge cases like extremely long strings or special characters. We check both client-side and server-side validation. Client-side validation can be bypassed, so server-side must also hold.

9. Authentication and Authorization Testing

Login, registration, password reset, session timeouts, role-based access, and token expiration all get tested. We specifically test what happens when a non-admin user tries to access an admin URL directly. This is a common and serious oversight.

10. Third-Party Integration Testing

If your application connects to a payment gateway, CRM, email service, analytics platform, or any external API, every integration gets tested against the production or sandbox version. We test both the happy path and what happens when the integration fails or returns an unexpected response.

11. Error State Testing

What happens when something goes wrong? Most teams test the success state thoroughly and forget the error states. We specifically test network failures, invalid inputs, service timeouts, and empty states. The user should always see a helpful message, never a raw error or a blank screen.

12. Regression Testing

Every time we fix a bug or add a feature, we re-test the areas that could be affected. We maintain a regression test suite that grows with the project. Yes, it takes time. No, you cannot skip it. We have seen a simple UI change break an unrelated API call too many times to count.

13. Data Integrity Testing

For any application that stores data, we verify that data is being saved correctly, retrieved accurately, and displayed consistently. We check for data truncation issues, encoding problems, and race conditions in concurrent operations.

Section 3: Cross-Device and Cross-Browser Testing (Items 14 to 18)

This section is where a lot of teams underinvest. "It looks fine on my laptop" is not a QA process.

14. Desktop Browser Testing

We test on Chrome, Firefox, Safari, and Edge. Each browser renders CSS differently, handles JavaScript quirks differently, and has its own font rendering. A layout that looks perfect on Chrome can completely collapse on Safari. We test all four, every time.

15. Mobile Browser Testing

Chrome on Android, Safari on iOS. These are not the same as their desktop counterparts. Touch events, viewport handling, keyboard behavior, and scroll interactions all behave differently. We test on actual devices, not just browser emulators, because emulators lie.

16. Responsive Design Testing

We check every major breakpoint: 320px (small phones), 375px (iPhone), 768px (tablets), 1024px (small laptops), 1280px and 1440px (desktops). We use both resize tools and real devices. Navigation menus, modals, tables, and image grids are the most common culprits for breakage at smaller breakpoints.

17. Different Operating System Testing

Fonts render differently on Windows vs macOS vs Linux. System fonts, color profiles, and scroll behavior differ. We specifically test on both Windows and Mac for any web application. For mobile apps built with our mobile app development team, we test on both iOS and Android physical devices.

18. Different Screen Resolution and Density Testing

High-DPI (Retina) displays reveal blurry images and icon rendering issues that standard screens hide. We check that images are properly optimized and that SVGs are used where needed. A pixelated logo on a Retina display is not a small thing; it says a lot about the quality of the product.

Section 4: Performance Testing (Items 19 to 22)

A product that works but loads in 8 seconds is a broken product in 2025.

19. Page Load Speed Testing

We use Google Lighthouse and GTmetrix to measure load times. Our internal benchmark is a Largest Contentful Paint (LCP) under 2.5 seconds and a Time to Interactive under 3.5 seconds. If either metric fails, we investigate the cause before launch, not after.

20. Database Query Optimisation

Slow queries are the most common cause of poor application performance. We check for N+1 query problems, missing indexes, and unoptimized joins. On one of our recent SaaS projects, a single unindexed query was causing dashboard loads of 12 seconds. After adding the right index, it dropped to under 400ms.

21. Load and Stress Testing

For applications expected to handle significant traffic, we simulate concurrent users using tools like Apache JMeter or k6. We want to know the breaking point before real users find it. For our IHLAQ barber booking platform project, which processes 5,000+ peak daily bookings, load testing was not optional. It was critical infrastructure work.

22. Asset Optimization Check

Images should be compressed and served in modern formats like WebP where supported. CSS and JavaScript should be minified and bundled. Unused CSS should be purged. These are not nice-to-haves. Every 100ms of load time affects conversion rates and SEO ranking.

Section 5: Security Testing (Items 23 to 27)

Security testing is not something you can skim. These five checks are the baseline minimum.

23. SQL Injection and XSS Testing

We test input fields, URL parameters, and API endpoints for SQL injection vulnerabilities. We also test for Cross-Site Scripting (XSS) by attempting to inject script tags through user inputs. Both are in the OWASP Top 10 and both are still shockingly common.

24. Authentication Security Check

Password hashing must use bcrypt or Argon2, never MD5 or SHA1. Sessions must expire correctly. HTTPS must be enforced everywhere. Multi-factor authentication flows, where present, get specific testing. For our S Cubed ABA therapy platform, a HIPAA-compliant system, authentication security was tested with an additional level of rigor because patient data was involved.

25. API Security Testing

Every API endpoint should require authentication where appropriate. We test for broken object-level authorization (BOLA), which means verifying that a user cannot access another user's records by changing an ID in the request. This is the most commonly exploited API vulnerability in real-world breaches.

26. File Upload Security

If your application accepts file uploads, we test for unrestricted file uploads that could allow execution of malicious scripts. Accepted file types, file size limits, and storage location (always outside the web root) are verified.

27. SSL/TLS and HTTPS Verification

The SSL certificate must be valid and properly configured. We use tools like SSL Labs to check for weak cipher support, mixed content warnings, and certificate chain issues. A padlock icon in the browser is not sufficient verification.

Section 6: UX and Accessibility Testing (Items 28 to 31)

Good software that is frustrating to use is still bad software.

28. User Flow Walkthrough with Fresh Eyes

Someone who did not build the product walks through the core user flows. This reveals assumptions the development team made that are not obvious to new users. Navigation labels that make sense to the developer, confusing confirmation messages, and steps that feel unnecessary all surface during this check.

29. Accessibility (WCAG 2.1) Compliance

We check color contrast ratios, keyboard navigability, screen reader compatibility, and proper use of ARIA labels. Beyond being the ethical and often legally required thing to do, accessibility improvements also tend to improve SEO and overall usability. Our UI/UX design team follows WCAG 2.1 AA standards as a baseline.

30. 404 and Broken Link Check

Every internal link must resolve to a valid page. We use crawlers to identify broken links and missing assets. A 404 on a product page or a broken image on a checkout screen damages both user trust and search engine rankings.

31. Copy and Content Review

Spelling mistakes, incorrect pricing information, placeholder text that was never replaced (lorem ipsum on a production page is a real thing that happens), and outdated legal copy all get reviewed. On projects with multilingual content, we also verify translations for accuracy and cultural appropriateness.

Section 7: Deployment and Go-Live Checks (Items 32 to 34)

The final three checks happen right before and right after deployment.

32. Staging to Production Verification

The staging environment should mirror production exactly. After deployment, we run a smoke test on the live environment immediately. We test the most critical user flows on production itself, within the first 30 minutes of going live. Not on staging, on the actual live server.

33. Rollback Plan Verification

Before we go live, we verify that a rollback plan exists and actually works. Database backups should be taken immediately before deployment. The ability to revert a deployment in under 10 minutes should be confirmed, not assumed. We have used rollback plans. More teams should have them.

34. Monitoring and Alerting Setup

Error monitoring (we typically use tools like Sentry), uptime monitoring, and server resource alerts must be configured before launch, not after. You need to know within minutes if something breaks on production. Not when a customer emails you.

How Much Does QA Testing Actually Cost? A Realistic Breakdown

A lot of articles will tell you QA costs "a few hundred dollars" or throw out numbers without any context. Let us actually break this down properly.

The cost depends on the size and complexity of the project, the type of testing required, and whether you are using an in-house QA team, hiring dedicated testers, or outsourcing to a QA partner.

Here is a realistic cost table based on current market rates:

Is this cost actually worth it? Yes. Here is the math. If a critical bug on a live e-commerce platform costs you $500/hour in lost revenue and your site has an incident that lasts 4 hours before it is caught and fixed, that is $2,000 in direct lost revenue, not counting customer churn, SEO penalties from server errors, or the developer cost to fix it under pressure.

A thorough QA cycle that costs $3,000 and prevents that incident paid for itself and then some.

If you are hiring an external QA team, rates in India from a quality firm typically range from $15 to $40 per hour, while US-based QA engineers average $60 to $120 per hour. You can hire a dedicated QA analyst through our team at Digisoft Solution at rates significantly below what you would pay for a full-time US employee, without compromising on quality.

Case Studies: Where This Checklist Made a Real Difference

IHLAQ: Barber Booking Platform, Qatar

When we built the IHLAQ platform, a real-time barber booking marketplace handling 5,000+ peak daily bookings, load testing was a defining part of our QA process. Without it, the platform would have collapsed under real traffic. We ran stress tests simulating peak booking scenarios, identified a race condition in the slot reservation logic that would have caused double-bookings, and resolved it before a single real customer used the system. The platform launched successfully with conflict-free scheduling and bilingual Arabic RTL support across web and mobile. You can read the full case study

S Cubed: HIPAA-Compliant ABA Therapy Platform

The S Cubed ABA practice management platform handles real-time care tracking and sensitive patient data for multiple clinics. Our QA process for this project included specific security testing phases: API authorization testing, session management verification, HIPAA data handling review, and encryption checks at rest and in transit. The result was a platform that passed compliance review without rework. When you are building in regulated industries, QA is not a checkbox, it is part of product delivery. Full case study

Miller Tanner: Global Life Sciences Event Platform

For Miller Tanner's hybrid event platform, which needed to synchronize attendees and content in real time across global teams, we ran extensive performance testing and API integration testing. The platform needed to scale to large concurrent users without degradation. Our QA process identified synchronization edge cases that only appeared under specific network latency conditions. Fixed before launch. Running successfully since. Full case study

Launch 360: SEO and Performance-Led Transformation

QA is not just about bugs. For Launch 360, a digital agency whose site had zero organic traffic, we ran a full technical audit as part of our quality process, discovered critical performance and crawling issues, and rebuilt the foundation with proper QA around speed, accessibility, and indexability. The result was first-page Google rankings and qualified inbound leads. Full case study

Common QA Mistakes We See Teams Make (and How to Avoid Them)

After 12+ years and 700+ projects, we have seen the same mistakes show up repeatedly.

Mistake 1: Testing Only on Your Own Device and Browser Your personal MacBook with Chrome is not representative of your user base. Most of your users are on Windows. A significant portion are on mobile. Always test across devices and browsers.

Mistake 2: Leaving QA to the End QA is not a phase at the end of development. Bugs caught in development cost far less than bugs caught in production. Involve your QA team early, during design review and during development, not just at the end.

Mistake 3: Skipping Performance Testing for "Simple" Sites A simple site on a poorly configured server with unoptimized images can still load slowly. Slow load time hurts SEO rankings. Google's Core Web Vitals are a direct ranking factor. Performance testing applies to every project.

Mistake 4: No Rollback Plan We have seen teams deploy and realize something is broken with no way to quickly revert. The rollback plan should be tested before launch, not written on a sticky note.

Mistake 5: Treating Security Testing as Optional SQL injection, XSS, and broken access control are not theoretical threats. They are real, common, and your application will be tested by automated bots within hours of going live. Security testing is not optional.

Mistake 6: Forgetting Mobile-Specific Behaviors Touch events, virtual keyboards pushing content up, overscroll behavior, and Safari's quirks on iOS are all things that do not exist on desktop. If you have not tested on an actual iPhone and an actual Android device, you have not finished testing.

QA Best Practices by Software Type

Not every product needs the same QA process. Here is how the focus shifts depending on what you are building.

For E-Commerce Platforms

Payment flow integrity is the top priority. Every payment method, every discount code combination, every edge case in the cart (out-of-stock items, shipping restrictions, tax calculations) needs to be verified. Our e-commerce development team runs dedicated checkout-focused QA sprints before any launch.

For Mobile Applications

Device fragmentation is the biggest challenge. Android has thousands of device configurations. iOS has far fewer, but Safari's WebKit engine has its own unique behaviors. We test on a minimum of 6 physical devices across both platforms before any mobile app launch. Emulators supplement but do not replace physical device testing.

For Enterprise Software

Integration testing dominates. Enterprise software connects to ERP systems, CRMs, HR platforms, and data warehouses. Each integration point is a potential failure point. We map every integration and test every flow, including failure and retry behavior.

For SaaS Products

Multi-tenancy and data isolation are critical. You must verify that User A cannot see User B's data. You must verify that actions in one account do not affect another. This sounds obvious but the test scenarios can get complex, especially in role-based systems.

For Healthcare and Regulated Platforms

Compliance testing is a dedicated team. Audit logging must be verified. Data encryption must be tested. Access controls must be verified against the specific regulatory requirements of the jurisdiction. This is not QA-lite. It requires experienced testers who understand the regulatory context.

How Digisoft Solution Approaches QA: Our Process and Values

We Test What We Build, Every Time

At Digisoft Solution, QA is embedded in our development process, not bolted on at the end. Our software testing services are not a separate offering that you add when you remember to. It is part of how we deliver every project. From small websites to enterprise platforms, we run this same 34-point checklist.

Our QA Team Works Alongside Developers

We do not have QA happening after development in a separate silo. Our QA analysts review requirements, participate in sprint planning, flag testable edge cases during development, and write test cases in parallel with feature development. This is how bugs are caught early, and early is always cheaper.

We Use Both Manual and Automated Testing

Automated testing is great for regression coverage, API testing, and repetitive functional tests. Manual testing is essential for UX evaluation, exploratory testing, and anything that requires human judgment. We use both. Teams that rely only on automation miss things. Teams that rely only on manual testing cannot scale.

Transparent Reporting and Communication

We do not present a clean green report to make everyone feel good. If there are open issues, you know about them. We document every bug with clear reproduction steps, severity classification, and recommended resolution. Our clients are never surprised by what goes to production.

We Scale with Your Project

Whether you need a single hire QA analyst to augment your existing team, or a full QA squad to own testing for a complex enterprise product, we can structure the engagement to fit. You can hire a dedicated quality analyst through Digisoft Solution to work as an extension of your team, or let us own the entire QA process. 

How Digisoft Solution Helps Businesses Adopt AI in QA and Development

AI is changing how software testing works. Automated test generation, AI-assisted code review, predictive defect analysis, and intelligent test case prioritization are all becoming real, practical tools for development teams. At Digisoft Solution, we have been integrating AI-assisted tooling into our development and QA workflows. This includes using AI-powered code analysis tools to flag potential issues during development, leveraging machine learning-assisted test coverage recommendations, and building AI-powered products for our clients like the Veridian Urban Systems platform, where AI processes and surfaces urban intelligence data in real time. We are not using AI as a buzzword. We are using it where it genuinely makes the work faster and the output better. If your business is exploring how to incorporate AI into your development or quality assurance processes, we can help you build a practical adoption roadmap. Our team has hands-on experience delivering AI-integrated products across industries. 

Quick Reference: The 34-Item QA Checklist at a Glance

CODE QUALITY AND REVIEW

1. Line-by-line code review by a second developer
2. Static code analysis with automated tools
3. Dependency and package vulnerability audit
4. Removal of debug code, console logs, and test credentials
5. Environment configuration verified for production
6. Test coverage review for critical business logic

FUNCTIONAL TESTING 7. End-to-end core user flow testing 8. Form validation with valid, invalid, empty, and edge case inputs 9. Authentication and authorization testing including role-based access 10. Third-party integration testing including failure scenarios 11. Error state testing for all failure conditions 12. Regression testing after any change 13. Data integrity and storage verification

CROSS-DEVICE AND CROSS-BROWSER TESTING 14. Desktop browser testing (Chrome, Firefox, Safari, Edge) 15. Mobile browser testing on real iOS and Android devices 16. Responsive design at all major breakpoints 17. Testing on both Windows and macOS operating systems 18. High-DPI and Retina display testing

PERFORMANCE TESTING 19. Page load speed with LCP under 2.5 seconds target 20. Database query optimization review 21. Load and stress testing for expected traffic volumes 22. Asset optimization including image compression and code minification

SECURITY TESTING 23. SQL injection and XSS vulnerability testing 24. Authentication security including password hashing and session handling 25. API endpoint authorization and BOLA testing 26. File upload security verification 27. SSL/TLS configuration and HTTPS enforcement

UX AND ACCESSIBILITY TESTING 28. User flow walkthrough with someone unfamiliar with the product 29. WCAG 2.1 accessibility compliance 30. Broken link and 404 check 31. Copy, content, and placeholder text review

DEPLOYMENT AND GO-LIVE 32. Post-deployment smoke test on production 33. Rollback plan verification 34. Monitoring and alerting configured and active

Frequently Asked Questions About Pre-Launch QA

How long does a full QA cycle take before launch?

For a standard web application, expect 1 to 3 weeks for a thorough QA cycle. For enterprise software or regulated platforms, 6 to 12 weeks is not unusual. The time saved by catching issues during QA versus post-launch is always worth it.

Can we skip some of these checks for a small website?

Some checks scale to the size of the project. A 5-page brochure site probably does not need load testing for 10,000 concurrent users. But code review, cross-browser testing, responsive design, broken links, and basic security checks apply to every project, regardless of size. The risk is proportional to what you skip.

What is the difference between QA testing and software testing?

They are often used interchangeably but technically differ. Software testing is the act of finding defects. Quality assurance is the broader process of ensuring quality standards are met throughout the development lifecycle, including processes, documentation, and delivery practices.

Should QA testing happen before or after development?

Ideally, it starts during development. QA analysts should be involved in requirement review, test case writing during sprints, and progressive testing as features are built. Final regression and launch testing happen at the end, but the process starts at the beginning.

Do I need automated testing or is manual testing enough?

For most web and mobile products, a combination of both is the right answer. Automated testing is efficient for regression suites and repetitive functional tests. Manual testing is essential for usability, exploratory testing, and new feature verification. Neither alone is sufficient at scale. Our backend development services include automated test suite setup as part of delivery where appropriate.

Final Thoughts

QA is not a formality. It is the difference between software that works and software that fails in front of your customers.

We have run this 34-item checklist across projects ranging from small business websites to AI-powered enterprise platforms and HIPAA-compliant healthcare systems. The checklist evolves as we encounter new failure patterns, new browser behaviors, and new security threats. But the discipline behind it stays constant: you do not launch until you are confident.

If you are building a product and want a QA partner who actually understands what they are testing and why, or if you want to hire a dedicated QA analyst to work directly with your team, we would be glad to have that conversation.