Hardening a repair marketplace's security before it scales
A property repair marketplace was getting ready to grow, but the founder couldn't tell how safe the code was. I audited all three codebases and wrote 40 ranked plans to fix what I found. The team has since closed a sign-in hole in the backend and put a review step in front of every code change, and more security fixes are in progress.
Property repair marketplace · · 3 min read
Context
A two-sided marketplace that connects property owners and managers with local contractors for repair jobs. Owners post jobs, contractors bid on them, and payments run through the platform. It also connects to the property management software owners already use.
The founder was preparing for a funding round and wanted the technical foundation checked before more users arrived. The team was shipping features, but nobody had stepped back to rank the risks. I came in as a part-time technical advisor to do that and to guide the team through the fixes.
What I did
- Audit and ranked plans. I reviewed all three codebases for security, data safety, scale and infrastructure. That turned into 40 written plans ranked by risk and effort, each tied to a task the team can track.
- A review step for every change. Every change to the backend and the web app now needs a second person's review before it goes in. Automatic checks also flag outside code whose license the company can't safely use.
- Closing a sign-in hole. Some backend data could be reached without signing in. The team blocked it, and every request now goes through a sign-in check by default, with extra browser security settings on top.
- Payment and data safety. The code now has a guard so a retried payment request can't charge a customer twice. Encrypted storage for property management logins and stricter rules on payment data are in progress, along with stronger passwords and the groundwork for a second sign-in step.
- A contractor hiring trial. When the founder wanted to add an engineer, I ran the technical interview and reviewed the code from a one-week paid trial on a real feature. My review gave the founder a clear recommendation based on the code itself.
- Checking a new spec against the code. Before a new product spec went to a designer, I checked it against the code. It assumed some features already existed when they didn't, and it missed fraud and text message consent risks. The founder had that list before any design began.
Results
Before
After
Before
No ranked view of the technical risks.
After
40 written plans, ranked and tracked as tasks.
Before
Changes could go into the main code without a review.
After
Every change to the backend and web app is reviewed first.
Before
Some backend data could be reached without signing in.
After
Every request goes through a sign-in check by default.
Before
A retried payment request could charge a customer twice.
After
A guard in the code stops the same payment going through twice.
Before
No check on the licenses of outside code in the web app.
After
Automatic checks flag outside code the company can't safely use.
What comes next
This engagement is ongoing. Next, the team finishes the security fixes still in progress, starting with encrypted storage for property management logins and stronger sign-in rules. Then we keep working down the ranked plans so the platform is ready for more users.
Your developers are busy and the product is stuck?
Book a free 25-minute call to see whether working together makes sense.
Prefer writing? Email me at hello@nicolascava.com. I'll reply within one business day.