The launch party had already been booked when Meera’s phone buzzed at 9:40 on a Tuesday night. It was the outside security reviewer the company had hired for one final look at its new travel-booking app, and the message was short: “We need to talk before Friday.” What followed is a story many small product teams will recognise, and it is a useful way to understand why building security checks into each step of the work beats saving them for the end. The team and company below are fictional, but every problem in the story is a common one.
The team, the app and the plan
Meera led engineering at a twelve-person startup we will call Wayfarer. The product let families plan multi-city trips, hold hotel rooms and split payments among relatives. After nine months of building, the plan was simple: finish features, freeze the code, bring in a specialist for a week-long security review, fix whatever turned up, launch.
It looked responsible on paper. A professional would examine the finished product with fresh eyes. Nobody on the team was a security specialist, so outsourcing the inspection to the end felt like the sensible division of labour.
Tuesday night: what the reviewer found
The reviewer’s call lasted forty minutes. Three findings mattered.
- A payment-provider key had been pasted into a configuration file months earlier during a late-night debugging session. It had been removed later, but it was still sitting in the repository’s history, readable by anyone with access to old commits.
- A popular open-source library the app relied on for image uploads was two major versions behind and carried a publicly documented flaw.
- The trip-sharing feature let any logged-in user view another family’s itinerary simply by changing a number in the web address.
None of these was exotic. Each had been introduced at a specific moment, by a specific person doing ordinary work, and each had then sat quietly for weeks or months while more code was layered on top.
Wednesday: the cost of finding things late
Fixing the leaked key meant rotating credentials with the payment provider, scrubbing history and confirming nothing had been misused. Upgrading the image library broke two other features that had been written around its old behaviour. The itinerary flaw required rethinking how the app checked permissions across a dozen screens.
“Any one of these would have been a ten-minute fix the day it happened,” Meera told her co-founder, Arjun, as they moved the launch back by three weeks. “We didn’t skip security. We just put all of it at the end, where everything is tangled together.”
That sentence became the turning point. The team had treated the review as a safety net, but a net at the bottom of a long fall only tells you that you fell.
The rebuild: one small safeguard at each step
During the three-week delay, the team redesigned how it worked rather than only patching the findings. Their rule was that every step of building software would carry its own lightweight check, so a mistake would be noticed at the point it was made. They started with three places.
When planning a feature
Before any new screen was built, the developer and product owner spent fifteen minutes asking how it could be abused. For the trip-sharing feature, the question “what happens if someone guesses another family’s link?” would have surfaced the itinerary flaw before a line of code existed. They kept these notes in the same ticket as the feature itself so the thinking travelled with the work.
When committing code
Arjun set up automatic secret detection on every commit. If a developer accidentally included a key or password, the commit was blocked on the spot, with a message explaining how to store the value properly. The team moved sensitive settings into a dedicated vault, using HashiCorp Vault, so nobody needed to paste keys into files in the first place.
When assembling a release
Every build now ran a dependency scan with Trivy, flagging libraries with known weaknesses. Instead of discovering an outdated component during a once-a-year review, the team saw a warning the week a flaw was published and could upgrade while the change was still small.
They added a simple release rule too: nothing went to customers if any of those checks had failed and not been explicitly reviewed. It applied to small updates as much as big launches.
What changed in the weeks after launch
The first month after the delayed launch was quieter than anyone expected. The commit check stopped two accidental secrets from reaching the repository. The dependency scan flagged a weakness in a date-handling library within days of it becoming public, and the upgrade took an afternoon. A planning session for a new group-chat feature surfaced a privacy question early enough that the design simply avoided it.
The outside reviewer came back six months later for a routine check. This time the call took ten minutes, and most of it was about minor hardening ideas. “The review didn’t get easier because they hired better people,” the reviewer later said. “It got easier because there was less left for me to find.”
For founders reading this at the stage Wayfarer was in, the broader view in this guide to validating and growing an early digital product is worth pairing with the lesson here: the habits you set before launch are the ones that stick.
How the team learned the discipline
Meera was candid that the team could not have designed these checks well without some outside learning. A few engineers worked through structured material on embedding security into delivery pipelines, and she pointed them towards DevSecOpsSchool’s courses on securing software pipelines, which organise training by role. The engineering-focused certification covered pipeline work such as static and dynamic testing, container hardening and infrastructure-as-code security, while she found the management-oriented track more relevant to her own job of setting governance and keeping the team’s security habits from fading. The platform also offers consulting and hands-on implementation help for teams that want guidance building secure CI/CD from scratch.
What mattered most, she said, was not any single tool. It was the team accepting that security belonged to every person at every step, not to one visitor at the end.
Lessons from Wayfarer’s near miss
Stripped of the story, the lessons are plain:
- A final review measures damage; it does not prevent it. By the time a specialist looks at a finished product, every flaw is already woven into other work.
- Mistakes are cheapest at the moment they are made. The person who just wrote the code still has the context to fix it in minutes.
- Small, automatic checks survive deadlines. A fifteen-minute planning question or a commit that blocks itself does not depend on anyone remembering to be careful on a busy night.
- Keep the outside review, but change its job. It should confirm a sound process, not rescue a fragile one.
Larger organisations face the same dynamics at greater scale, which is why the ideas in our discussion of governing software delivery across an enterprise echo many of Wayfarer’s lessons, only with more teams and more hand-offs.
What Wayfarer deliberately left alone
Just as telling were the things the team chose not to do. They did not create a separate security department, because twelve people could not afford one and because it would have pulled responsibility away from the developers writing the code. They did not add a long approval form for every change, since Arjun suspected people would start rushing through it within a fortnight. And they did not stop hiring the outside reviewer. Instead, they agreed that each new safeguard had to pass one test before it was adopted: could it run in under a minute, every single time, without someone needing to remember it? Anything slower went on a list to be simplified first. That restraint is a big part of why the habits lasted after the adrenaline of the near miss wore off.
The quiet ending
There was no dramatic finale to Wayfarer’s story, and that is the point. The launch party happened three weeks late. Families planned trips. Payments went through. Nobody outside the company ever heard about the Tuesday-night phone call, because the problems it uncovered were fixed before they could reach a single customer, and the habits built afterwards kept the next ones from growing in the first place.
If your team is still saving its checks for the finish line, the cheapest moment to change is before your own version of that phone call.
