DEV Community: Beatriz Albernaz

We Built a Pentesting Company Because We Were Tired of Watching Startups Get Burned

Beatriz Albernaz — Wed, 13 May 2026 13:47:03 +0000

There was a pattern we kept seeing that genuinely bothered us.

A startup would get to Series A, or land their first enterprise customer, and suddenly need a pentest report right now. They'd scramble to find a vendor, get hit with a 4-week scoping call process, a €30k quote, and a PDF that mostly described low-severity findings their scanner already caught.

They didn't need a €30k PDF. They needed someone to actually look at their auth layer, their API, their trust boundaries and tell them what was actually broken.

That frustration is what became Faultline Security.

The problem we were trying to solve

When we started talking to early-stage founders about security, the same themes kept coming up:

"We know we need a pentest but have no idea where to start"
"The quotes we got were either too expensive or too vague"
"We have a SOC 2 audit in 8 weeks — is that enough time?"
"Our enterprise prospect is asking for a pentest report and we've never done one"

None of these are hard problems, conceptually.

We get it! Security is almost always the thing that gets pushed to the next sprint, the next quarter, the next funding round. When you're a small team trying to ship and grow, it's genuinely hard to prioritize. But here's what we keep telling founders: starting early isn't harder, it's actually easier.

When your codebase is smaller, your attack surface is narrower, and your team is close to every decision, building a solid security foundation takes a fraction of the effort it will cost you later. The expensive, painful pentests we kept seeing weren't just a vendor problem, they were the result of years of deferred security work landing all at once. We wanted to help teams get ahead of that.

We wanted to build something different: fixed pricing, a scoping process that takes 24 hours not 2 weeks, and findings that are actually written for engineers who need to fix them — not auditors who need to check a box.

What building this taught us

Founders don't know what they need until you ask the right questions.

The first version of our intake process asked things like "what environments are in scope?" and got blank stares. We rewrote it to ask "what would hurt the most if a competitor got in?" That changed everything. Suddenly people could actually answer.

The report is the product.

We spent more time rethinking how findings are written than anything else. A finding that says "Cross-Site Scripting detected on /search" is useless. A finding that shows the exact payload, the session token that was exfiltrated in the proof of concept, and the two-line code fix — that is a product.

Timelines are the most anxiety-producing part of the whole process.

The question we get asked more than any other is: how long is this actually going to take? People have compliance deadlines, fundraise timelines, sales deals on the line. They need a real answer, not "it depends."

We wrote a detailed breakdown of this recently: How Long Does a Startup Pentest Take? — the short answer is 3 to 10 days of active testing plus 2 days for the report, so most teams have something in hand in under two weeks. But the full picture is more nuanced, and worth reading if you're scoping something with a hard deadline.

The parts nobody tells you about starting a security company

Building in security is weird. You're asking people to trust you with access to their most sensitive systems, before they know you well. Trust-building is the entire job before any actual testing happens.

We also learned that pricing transparency is itself a differentiator. Most pentesting firms won't put a number on their website. Scope varies, complexity varies. But the endless "contact us for pricing" dance adds friction that small teams don't have time for. Showing a real range upfront, even approximate, changes the quality of conversations you have.

And the writing matters more than we expected. Content like the timeline post above has brought in more qualified leads than any cold outreach we've done. People who are googling "how long does a pentest take" are in the buying process. Meeting them where they are with an honest, detailed answer builds more trust than any sales email.

Where we stand now

Faultline is purpose-built for SaaS companies and startups that are hitting real security milestones — first enterprise customer, SOC 2 audit, Series A. We're not trying to compete with the big firms doing 6-month red team engagements for banks. We're trying to be the best option for a 20-person company that ships fast and needs a pentest that matches their pace.

If you're building something and wondering whether you need a pentest, when to do it, or how to think about scope we're happy to talk. No sales process. Just people who care about shipping secure software.

You can also scope an engagement directly and get a fixed-price proposal within 24 hours.

What questions do you have about security at the early stage? Drop them in the comments. we read everything.

What pentest does your startup actually need?

Beatriz Albernaz — Thu, 30 Apr 2026 15:02:54 +0000

Most startup founders know they should get a pentest. Fewer know what kind, what scope, or what a reasonable price looks like and the industry hasn't made this easy to figure out.

Pricing is rarely published. Scope conversations happen after you've already given your email to a sales rep. And the word "pentest" gets used to describe everything from a lightweight automated scan to a two-week manual engagement by a team of three.

This guide gives you a framework to self-assess what you actually need, based on where your company is and what you're building.

The variables that actually determine what you need

There are four factors that map pretty cleanly to pentest scope and cost:

1. Company stage
Pre-seed and seed companies usually need a lighter engagement — enough to surface critical vulnerabilities and satisfy early security questionnaires, but not a full-blown compliance audit. Series A and beyond typically have more surface area, more integrations, and investors or enterprise customers who want to see a proper report.

2. What you're building
A web app with an authenticated user section is a different scope than an API serving third-party developers, which is different again from infrastructure with cloud components and CI/CD pipelines. Each surface has different attack vectors and different testing methodologies.

3. Compliance requirements
SOC 2 Type II, ISO 27001, and PCI DSS all have specific pentest requirements. If you're pursuing any of these, the pentest needs to meet certain criteria — scope, methodology, report format — that go beyond a general security assessment. This is often the trigger that moves a startup from "we should probably do this at some point" to "we need this done in the next 90 days."

4. Scope
This is the one founders underestimate most. Scope drives cost more than anything else. A focused test on your main web application is a very different engagement from one that covers the application, your API, your admin panel, your cloud configuration, and your internal tooling.

The main pentest types and when you need them

1. Web application pentest
The most common for early-stage SaaS. Tests your application from the perspective of an authenticated user, an unauthenticated attacker, and sometimes a privileged user. Covers OWASP Top 10 and beyond — auth flows, access controls, injection points, business logic flaws.
→ When you need it: You have a product with user accounts. A customer asked for a pentest report. You're starting a SOC 2 process.

2. API pentest
Similar to a web application test but focused on your API endpoints. Critical if your API is externally facing or consumed by third-party developers. Auth, rate limiting, data exposure, BOLA/IDOR vulnerabilities.
→ When you need it: Your API is your product or a significant part of it. You have developer customers. You're building in a regulated space.

3. Cloud / infrastructure pentest
Tests your cloud environment — misconfigurations, overly permissive IAM roles, exposed storage buckets, network segmentation issues. Usually AWS, GCP, or Azure.
→ When you need it: You've scaled beyond a simple Heroku deploy. You have infrastructure engineers managing cloud resources. ISO 27001 or SOC 2 is on the roadmap.

4. Combined / full-scope engagement
All of the above, sometimes with internal network or social engineering components. More common at Series B+ or when enterprise contracts require it.
→ When you need it: You're selling to enterprise. Your compliance framework requires broad scope. You've had a security incident and want comprehensive coverage.

A quick self-assessment
Answer these honestly and you'll have a good starting point:

-Stage: Are you pre-product-market-fit, or do you have paying customers and scaling infrastructure?

Surface area: What are the components you're worried about? Web app only? API too? Cloud infra?
Driver: Is this proactive, or is a customer / investor / compliance requirement pushing you to do it now?
Timeline: Do you have a deadline (audit, enterprise deal, fundraise)?
Budget range: Are you looking for something under €5k, €5–15k, or are you budgeting for a larger engagement?

The combination of these five answers will tell you whether you need a focused lightweight test, a standard web + API engagement, or a more comprehensive scope.

Skip the guesswork
We built a 5-question quiz that maps your answers to a recommended tier and a starting price.
→ Takes under a minute.

faultlinesec.com/quiz

It asks for your work email before showing the result [full transparency on that] and you'll hear from us. But the recommendation is genuine and accurate enough to use as a starting point for any vendor you end up going with, not just us.