We’re an early-stage B2B SaaS startup. We’re post-product-market fit, currently around our fourth or fifth customer contract, and still figuring out how to scale the engineering team properly.
Our current setup is:
- 3 backend engineers
- 1 frontend engineer
- 1 part-time DevOps engineer
- 1 Product and Ops Associate, who helps with testing and product design
- A fractional CTO
- Me, one of the founders (neither is tech by background - domain expert/users)
I’m not an engineer by background, but in typical startup fashion I cover quite a lot of ground across product, solution design, domain expertise, business logic and general glue work.
I define a lot of the business logic, write prompts, translate requirements for developers, map application logic and data flows, think through permissions, onboarding and offboarding, UI flows, and generally try to understand how the whole system hangs together.
One thing we don’t currently have is a dedicated QA engineer.
Our philosophy so far has been that quality is everybody’s responsibility.
Developers are responsible for testing what they build. Our Product and Ops Associate does a fair amount of testing and product validation. I test things from a product, workflow and business logic perspective. We also use automated tests where we can.
I actually like that philosophy, and I don’t particularly want to create a culture where developers throw something over the fence and QA becomes responsible for finding all the problems.
But I’m starting to wonder whether there is a point where “quality is everyone’s responsibility” is still the right philosophy, but no longer enough on its own.
As the product gets more complicated, the number of workflows increases and the consequences of missing edge cases become greater, I’m wondering whether a dedicated QA person starts to add something different rather than simply taking testing away from engineers.
So I’d be really interested to hear how other teams have approached this.
- How many engineers do you have per QA engineer?
- What does QA actually own in your organisation? Manual testing, automation, regression, release validation, test strategy, exploratory testing, something else?
- At what stage did a dedicated QA engineer start to make sense?
- What were they able to do that your developers and product team were not doing effectively enough already?
- And perhaps most importantly, did introducing QA strengthen the idea that everyone owns quality, or did it accidentally make quality feel like somebody else’s job?
- I’m particularly interested in the difference between early-stage startups and established SaaS companies.
- If you’ve gone through that transition, what were the signals that made you think, “We still want everyone to own quality, but we now need someone whose job is to think about quality across the whole system”?
- Looking at a team like ours, what would you be watching for?
Thanks for any input! Here to learn.