Everything breaks.We build it and break it first.

A young studio that builds software, then does its worst to it: load it, probe it, break it, fix it, prove it. Your customers and your attackers get what survives.

Book a scoping call See a sample report

A machined aluminium bracket under a press. A stress map runs from blue to red across it and a clean break has opened one third of the way along. Small chips from the break lie on the lower platen.

What we build

Before anything can break

Web apps, mobile apps and the backends behind them, from a one-page scope to launch. Built by people who spend the rest of the week breaking software, so testing is designed in, not bolted on at the end.

What we build: the bracket at this stage of the test

What we load

Before the release

We push traffic past your best day and run every release candidate through exploratory and regression passes. The limits show up here, on our clock, not on launch day.

What we load: the bracket at this stage of the test

What we probe

Before the breach

Penetration testing of web, API, mobile and cloud, the way an attacker would do it, then a hard look at the code and architecture behind them. The next hole is usually a design decision.

What we probe: the bracket at this stage of the test

What we report

Before the incident

One finding per page: what we did, what we saw, what it means, how to fix it. Severity on the five-stop scale you see on this object. Nothing inflated, nothing buried.

What we report: the bracket at this stage of the test

How we fix and retest

Before it ships

We stay for the fix, review the change, load it again past the original and show you it holds.

How we fix and retest: the bracket at this stage of the test

Services

We build it, then we break it. Either way you end with proof: a launch with a test report behind it, or a report you can act on and a retest that shows the fix held.

The deliverables

A new studio has no client logos. It has reports. Here are four pages from four kinds of engagement, redacted: a security finding, a QA defect, a load test and a launch handover.

Download the sample reports (PDF)All four, the same content as on this page, as one file you can forward.

Templates, free to use

Report templateThe shape every finding follows: title, severity, steps, evidence, impact, fix, retest.
Rules of engagementThe working agreement we sign before any test: people, scope, windows, what is allowed, data handling.

Confidential

Sample report, redacted

Application security assessment
Client: withheld
Scope: customer web app and public API
Testing window: 1 to 12 September 2026
Issued 15 September 2026

Version 1.1, after retest

Severity scale

Info
Low
Medium
High
Critical

The same five stops as the stress map on the object.

BF-0914-03

Insecure direct object reference on the orders endpoint

Severity: HighCVSS 3.1 base score 7.1, vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
Status: Fixed and retested

Summary

Any signed-in customer can read any other customer’s order, including name, phone number and delivery address, by changing the numeric id in the URL. Order ids are sequential, so the whole order history can be enumerated.

Steps to reproduce

Sign in as a test customer and place an order. Note the order id in the confirmation URL.
Request the order via the API with the test customer’s token. The response is correct.
Change the id to the previous number and repeat the request with the same token.
The response returns another customer’s order with personal data.

Evidence

GET /api/v1/orders/48212 HTTP/1.1
Host: api.redacted.in
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.redacted
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 48212,
  "customer": {
    "id": 10477,
    "name": "redacted",
    "phone": "+91 redacted"
  },
  "deliveryAddress": "redacted, Pune 411001",
  "items": [{ "sku": "BRK-212", "qty": 1, "price": 2499 }],
  "status": "delivered"
}

Request made with the test customer’s token. Order 48212 belongs to a different account.

Impact

Personal data of every customer is readable by any other customer. Under the DPDP Act this is a reportable personal data breach. The sequential ids make bulk extraction a one-line script.

Fix

Scope the lookup to the signed-in customer and return 404 when the order is not theirs, so the endpoint does not confirm that an id exists. Add an authorisation test to the API suite so the check cannot regress.

// before
const order = await orders.findById(req.params.id);
if (!order) return res.status(404).end();
return res.json(order);

// after
const order = await orders.findOne({
  id: req.params.id,
  customerId: req.user.id,
});
if (!order) return res.status(404).end();
return res.json(order);

Retest

Retested on 18 September 2026. Requests for other customers’ orders now return 404 with an empty body. The authorisation test runs in CI on every pull request. Status: fixed.

How an engagement runs

Two ways to work with us, each in order. No phases named after planets; the durations are what they usually take.

A testing engagement. Scope to signed-off retest is usually four to eight weeks.

1
Scope and rules of engagement
Two days
We agree targets, test windows, test accounts, data handling and who to call if something breaks in production.
2
Threat model
Two to three days
We map what you have, who would attack it and where the value sits. It decides where the testing time goes.
3
Test
One to three weeks
Manual testing with evidence captured as we go. You hear about critical findings the same day, not in the report.
4
Report and walkthrough call
Three days after testing ends
Written findings with fixes, then a sixty-minute call with your engineers to go through each one.
5
Retest
Within thirty days, included
We verify each fix, update the status in the report and sign it off.

A development project. A first release is usually eight to sixteen weeks, and every release goes through the testing track before it ships.

1
Discovery and scope
One to two weeks
We write down what the product does, who attacks it, what it must survive and what done looks like. You get a scope, an estimate and a threat model before any code.
2
Design and build, in sprints
Two-week sprints
Working software every two weeks, with automated tests and a security review in each sprint. You see it, use it and redirect it as it grows.
3
Test every release
Inside each sprint
Each release candidate goes through the testing track: load, penetration test, retest. Nothing ships with a known high or critical finding open.
4
Launch and handover
One week
Production setup, runbooks, documentation and the final test report. The code and the infrastructure are yours. We can stay on by the sprint.

Who it is for

Startups and founders: You have a product to build and nobody to build it yet. We build it, test it as we go and hand it over with the code, the infrastructure and the proof that it holds.
Product companies: You ship every week, and the bug that costs you is the one a customer finds. We find it first, in the release candidate.
Fintechs: Payments, lending, wallets: the attack surface is the product. We test it before the audit does, and before anyone else does.
Dev agencies, white-label: Sell QA and security under your own name. We do the work, you keep the client, and the report can carry your brand.

Book a scoping call

Tell us what you are building, or what keeps you up at night. One working day later you have questions, a scope and a price.

What the call covers

What you are building, or what needs testing, and why now.
What is in scope and what is not: systems, environments, data.
Test windows, accounts, access and who to call if something breaks.
What you get back, in what form, and when.

Or write to hello@breakfirst.dev

Everything breaks.We build it and break it first.

What we build

What we load

What we probe

What we report

How we fix and retest

Services

The deliverables

Templates, free to use

Sample report, redacted

Severity scale

Insecure direct object reference on the orders endpoint

Summary

Steps to reproduce

Evidence

Impact

Fix

Retest

How an engagement runs

Scope and rules of engagement

Threat model

Test

Report and walkthrough call

Retest

Discovery and scope

Design and build, in sprints

Test every release

Launch and handover

Who it is for

Book a scoping call

What the call covers