TL;DR: Building a QA function from zero follows a predictable pattern. We've done it for 30+ companies. Days 1-30: audit, prioritize, and ship quick wins. Days 31-60: build automation foundations and define process. Days 61-90: integrate into CI/CD and establish coverage metrics. The first decision — hire or outsource — depends on your timeline, budget, and how quickly you need results.
The first decision: hire or outsource?
Every CTO building QA from zero faces this same fork. Both paths work. They work at different speeds and different price points.
Hire first if: - You have 2-3 months before quality becomes critical (recruiting plus onboarding takes 6-12 weeks) - Your product domain requires deep institutional knowledge that takes months to develop - You're committed to QA as a permanent function - You have budget for ₪25,000-40,000/month per engineer (senior QA salaries in Israel including employment costs)
Outsource first if: - You need QA capabilities within 2-4 weeks - You're not sure what kind of QA you need yet (automation? manual? both? what ratio?) - You want to learn from experienced QA processes before building your own - You're pre-product-market-fit and your product changes rapidly
Most of our clients at Globalbit start by outsourcing for 3-6 months, then build an internal team using the process we established. The outsourced engagement creates the playbook. The internal team inherits it.
Days 1-30: Audit, prioritize, get quick wins
Week 1: Understand the current state
You can't fix what you can't see. The first week is dedicated to understanding where bugs come from, where they hit users, and what the team currently does about quality (even if the answer is "nothing formal").
Actions: - Pull the last 90 days of production incidents. Categorize by severity, component, and root cause. - Interview 3-5 developers about where they feel least confident in the codebase. - Map the current deployment pipeline. How does code get from a developer's laptop to production? Where are the gates? (Usually nowhere.) - Identify the 3 user flows that generate the most revenue or the most complaints.
Deliverable: A one-page quality risk assessment. Not a 50-page audit report. One page listing your top 10 risks, ranked by business impact.
Week 2: Ship 5 critical smoke tests
Don't wait for perfect tooling or comprehensive coverage. Write 5 automated tests for your most critical user flows and run them on every deploy. This takes one engineer about a week.
What to cover: 1. Login/authentication works 2. Main page loads without errors 3. Primary user action completes (add to cart, submit form, send message) 4. Payment/billing flow works (if applicable) 5. Data submission saves and is retrievable
Tool choice: Playwright for web. It handles multiple browsers, is faster than Selenium, and has better debugging. Don't spend more than a day deciding on the tool.
Impact: These 5 tests will catch the most embarrassing bugs — the ones where logged-in users can't log in or the checkout page crashes. Every production incident you prevent in this category saves 4-8 hours of emergency response.
Weeks 3-4: Establish bug triage process
Most teams without QA have bugs scattered across Slack messages, Jira tickets with no severity, and mental notes that developers lose when they switch context.
Set up: - A single bug backlog (separate from feature backlog) - Severity classification: Critical (blocks revenue/users), High (significant UX impact), Medium (workaround exists), Low (cosmetic) - Triage schedule: 15 minutes, 3× per week for the first month - Rule: Critical bugs get fixed before new features ship
This sounds basic. It is. But teams without formal QA typically have zero process here, and bugs accumulate until a crisis forces action.
Days 31-60: Build automation foundations
Week 5-6: Choose and implement your testing architecture
The testing pyramid still works, but the ratios have shifted. Here's what we recommend for teams starting from zero:
| Layer | What it tests | Percentage of total tests | Tools |
|---|---|---|---|
| Unit | Individual functions and modules | 60% | Jest/Vitest |
| Integration | API contracts, database queries, service interactions | 25% | Supertest, Pact |
| E2E | Critical user journeys end-to-end | 15% | Playwright |
Don't reverse this pyramid. Teams without QA experience often write E2E tests first because they're intuitive. E2E tests are slow, brittle, and expensive to maintain. Write unit and integration tests first. They're faster, more stable, and catch bugs earlier.
Week 7: CI/CD integration
Tests that run manually get skipped. Tests integrated into CI/CD run every time.
Pipeline stages: 1. Pre-commit: Linting and type checking (fast, blocks commit) 2. PR check: Unit and integration tests (under 5 minutes, blocks merge) 3. Post-merge: Full E2E suite (under 15 minutes, blocks deploy) 4. Post-deploy: Smoke tests in production (under 2 minutes, triggers rollback)
Set up these gates even if you only have the 5 smoke tests from week 2. The infrastructure exists so that every new test you write automatically runs in the right stage.
Week 8: Define what "done" includes testing
Modify your definition of done for development tasks. Every feature ticket should include: - Unit tests for new functions - Integration test for new API endpoints - Update to existing E2E tests if user flow changed - Tested on at least 2 browsers (Chrome + one other) - Accessibility check on new UI components
This is where QA transitions from a separate activity to part of how the team works.
Days 61-90: Scale and measure
Week 9-10: Expand coverage strategically
Don't chase 100% coverage. Chase coverage of your risk areas. Use your week 1 assessment to identify which parts of the codebase cause the most production incidents, and prioritize test coverage there.
Coverage targets for the 90-day mark: - Critical user flows: 90%+ covered by E2E tests - Core business logic: 80%+ unit test coverage - API contracts: 100% of public endpoints have contract tests - Overall code coverage: 60% (as a floor, not a target)
These numbers come from what we see at Globalbit in successful QA buildouts. Teams that aim for 60% overall coverage by day 90 and focus depth on business-critical paths catch more bugs than teams that aim for 80% overall but spread evenly.
Week 11: Establish QA metrics
Track these. Report them every sprint.
| Metric | Target by day 90 | Why it matters |
|---|---|---|
| Defect escape rate | Below 15% | What percentage of bugs reach production vs caught in testing |
| Time to detect | Under 1 hour | How quickly bugs are detected after deploy |
| Test suite runtime | Under 15 minutes | Tests that take longer get skipped or parallelized |
| Flaky test rate | Under 5% | Flaky tests erode trust in the entire suite |
| Deployment frequency | No decrease | QA should never slow down shipping |
Week 12: Knowledge transfer and process documentation
Whether you started with outsourced QA or built internally, week 12 is for documenting what you've built: - Test strategy document (1-2 pages) - Runbook for common failure scenarios - On-call QA process for production incidents - Onboarding guide for new team members
This documentation ensures that your QA function survives personnel changes. The process lives in documents, not in someone's head.
Common mistakes in the first 90 days
Starting with the wrong tool: Teams spend 2 weeks evaluating testing frameworks when they should be writing their first test. Pick Playwright for web, Jest/Vitest for unit tests, and move on.
Trying to test everything at once: The goal at 90 days isn't comprehensive coverage. It's a working process that catches the most damaging bugs automatically. Depth over breadth.
Making QA a gate instead of a partner: If developers see QA as the team that blocks their PRs, you've failed. QA should make developers' lives easier by catching bugs before the on-call rotation catches them at 2 AM.
Ignoring mobile: If you have a mobile app, include mobile testing from day 1. Real devices, not simulators. Browser testing and mobile testing are different disciplines. Budget for both.
Not measuring: Without metrics, you can't prove that QA investment is working. Track defect escape rate from day 1. It's the single most important metric.
FAQ
Should my first QA hire be a manual tester or an automation engineer?
Automation engineer with manual testing experience. You need someone who can write code, set up CI/CD integration, and also manually explore the product when needed. The hybrid role is more valuable than either specialty alone in the early days.
How much does a QA function cost in the first year?
For an Israeli startup: ₪400,000-600,000 for one senior QA engineer (including employment costs) plus ₪50,000-100,000 for tools and infrastructure. For outsourced QA: ₪15,000-30,000/month for a dedicated engineer with access to a broader team. Globalbit offers both models — talk to us about which fits your situation.
Can developers write their own tests instead of hiring QA?
They can and should write unit tests. But developers testing their own code is like a writer proofreading their own article — they're too close to see the errors. QA engineers bring an adversarial perspective that developers typically lack. The best setup is developers writing unit tests plus QA owning integration, E2E, and exploratory testing.
What if we're pre-PMF and the product changes every sprint?
Focus on the smoke test layer (5-10 tests on the most stable flows) and exploratory testing. Heavy automation investment doesn't make sense if the product will pivot. When you find PMF and flows stabilize, invest in the full 90-day buildout. We've helped pre-PMF startups balance speed and quality — let's talk.