
In a Pickle – From Startup Idea to Breakdown Marketplace
In a Pickle Breakdown set out to offer pay-as-you-need breakdown help: no membership, the price shown up front, and a vetted local operator you can watch arrive. I turned the founder's idea into an operating model and built the platform behind it: a three-sided marketplace with location-based matching, live GPS tracking, payments held until the job is settled, automatic supplier payouts, and document-based vetting that keeps every operator compliant.
Jump to a section
- The idea
- A marketplace runs on trust
- From an idea to an operating model
- Two journeys, one platform
- What the platform does
- Requesting help when you're stranded
- Clear prices, including when nobody's sure
- Matching the nearest suitable driver
- Live tracking, and arrival you can trust
- Payments held, not taken
- Getting suppliers paid
- Vetting suppliers, and keeping them compliant
- Companies with several drivers
- When things don't go to plan
- Keeping contact on the platform
- Running the business without a developer
- A record of what was agreed
- What was delivered
- Not just breakdowns
- Technical stack
- Have an idea for a platform?

Built with
- Next.js
- React
- TypeScript
- Tailwind CSS
- Node.js
- Express.js
- Socket.IO
- MongoDB
- Mongoose
- Stripe
- AWS S3
- MapLibre
- Nodemailer
- Zod
- reCAPTCHA
At a glance
Client
In a Pickle Breakdown Ltd, a UK startup
The idea
breakdown help you pay for only when you need it, with no membership and the price shown up front
What I built
a three-sided marketplace connecting stranded motorists with vetted local recovery operators, with live tracking, held payments and supplier payouts
My role
consultancy, product design, development, hosting and ongoing support
The idea
Breakdown cover is usually sold as an annual membership. Plenty of drivers don't have one, and when their car stops they are left searching for a local operator, ringing round and agreeing a price over the phone, often at the side of a road.
The founder of In a Pickle wanted to offer something simpler: pay-as-you-need breakdown help. Request help when you need it, see the price before you commit, and get matched with a vetted local operator you can watch arrive.
The client came with the idea and a clear sense of the customer experience. There was no existing system to adapt; everything had to be built from scratch.
A marketplace runs on trust
A booking app moves a request from A to B. A marketplace has to make strangers trust each other at a stressful moment, and protect each of them from the other.
Motorists
need to know who is coming, when they will arrive, what it will cost, and that they won't pay for help that never turned up.
Suppliers
need to know a job is real, that the customer will be there, and that they will be paid for work they have done.
The business
needs to know every supplier is properly insured and qualified, and needs a clear record of what was agreed when something goes wrong.
From an idea to an operating model
An idea becomes a business when every awkward situation has an answer. Much of this project was working through those situations with the founder, then turning each answer into a rule the software applies every time:
When exactly is the customer's card charged, and for how much?
What happens if the driver isn't sure whether the car can be fixed at the roadside or needs recovering?
Can a customer cancel once the operator is on the way? What if they are cancelling because they feel unsafe?
What if the operator arrives and nobody is there, or the job turns out to be something they can't do?
How does anyone know the operator really arrived?
What happens when a supplier's insurance runs out?
The founder could describe the service customers should experience. My job was to design the rules, safeguards and money flows that make that service work for everyone involved.
Almost every one of those rules is a setting the business controls, from prices and cancellation fees to dispatch radius and how long a payment hold lasts. As the business learns, it can change them without a developer.
Two journeys, one platform
The motorist
The motorist shares their location, enters their registration and picks what's wrong from a list written in plain English. They see the price before they commit, and their card is held, not charged. The nearest suitable operator accepts. The motorist watches them approach on a live map, chats with them if needed, and confirms when the job is done.
The supplier
A recovery operator signs up, uploads the documents their kind of work requires, and is approved by the In a Pickle team. Once approved they go online. Nearby jobs appear with enough detail to decide, they accept, attend and complete the job, and their share is paid to their own bank account through Stripe.
Three sides, one system
Motorists
request help, see the price, track the operator, chat, and confirm or dispute the outcome.
Suppliers
apply, manage documents and drivers, take jobs, and follow their earnings and payouts.
The In a Pickle team
approve suppliers, watch live jobs, resolve problems, and run the business from settings.
What the platform does
Requesting help when you're stranded
For the business: asking for help has to be quick for someone stressed at the roadside, but the request still has to tell the operator what they're walking into.
Under the hood:
Location comes from the phone's GPS, a typed address with autocomplete, or a rough position from the connection as a last resort. The customer can drag the pin to correct it after booking.
Typing a registration looks the vehicle up in the DVSA's MOT History service: make, model, colour, fuel, MOT status and any outstanding safety recall. If the lookup can't help, the vehicle can be entered by hand.
Around 50 common faults, from flat batteries and lockouts to EV problems and accident damage, are grouped into categories. Each fault knows what equipment it needs and suggests the right level of service.
Before booking, the customer confirms they are somewhere safe and not in a live lane.
Clear prices, including when nobody's sure
For the business: customers see a fixed price before they commit, and an honest answer to "I don't know if it can be fixed here".
Under the hood: there are three tiers: roadside assistance, recovery, and "unsure", for when it might be either. An unsure job goes only to operators who can do both. If it turns out a roadside fix is enough, the customer is charged the roadside price, not the higher one. The customer chooses the tier. Picking a lower tier than the fault suggests needs an explicit confirmation, and both the suggestion and the choice are recorded on the job. Anything beyond the service price, such as parts or extra mileage, is agreed directly with the operator.
Matching the nearest suitable driver
For the business: the job goes to whoever can actually do it and is closest, not to whoever happens to be listed first.
Under the hood:
Matching works on individual drivers, not companies, using a geographic search of who is online and how far away each of them is. Each driver can have their own working radius.
Every match is filtered on the company's approval, the driver's approval, and the specific equipment that fault needs. A company approved for jump starts isn't sent a heavy recovery.
The nearest suitable drivers are notified, and the first to accept gets the job. Acceptance is settled in a single database step, so two operators can never both win the same job.
Before accepting, operators see the type of job, the fault, the vehicle and the area, but not the customer's exact location. That is shared only once they have accepted.
Live tracking, and arrival you can trust
For the business: the customer can watch help arrive. Because the platform knows when the operator really got there, it can settle arguments about who was where.
Under the hood:
The operator's phone sends its position every few seconds and keeps the screen awake while they drive. The customer sees it move on a live map, with the route and an arrival estimate.
Updates travel over a real-time connection that only the people on that job can join.
Within half a mile, the customer can no longer cancel. Close to the vehicle, the operator is asked to confirm they've arrived.
Arrival only counts as verified when the phone reports an accurate position and stays within 100 metres for a full minute. A tapped "I've arrived" without that evidence is recorded as unverified. The position that proved the arrival is stored with the job.
The customer can confirm or deny that the operator arrived, and a denial stops any automatic payment.
Payments held, not taken
For the business: customers aren't charged for help they haven't received, and operators know the money is there before they set off.
Under the hood:
When the customer requests help, their card is authorised for the price, which ring-fences the money without charging it. An operator can't accept a job until that hold is in place.
Accepting doesn't take payment. The card is charged when the job is settled: completed, cancelled or resolved. Settling can charge less than the hold, which is how the "unsure" job charges the roadside price when that's all it needed. Settling can never charge more than the hold.
If nobody accepts in time, the hold is released automatically.
Every payment instruction to Stripe can safely be repeated without charging twice. Stripe's own notifications are signature-checked, and each one is processed only once.
Getting suppliers paid
For the business: operators are paid properly without anyone at In a Pickle handling their money.
Under the hood: each supplier connects their own Stripe account. When a job settles, their share is transferred from that job's payment, and the platform keeps a fixed amount per job. A transfer that fails is retried automatically. Suppliers see their earnings as pending, available and paid out, with the available figure read live from Stripe.
Vetting suppliers, and keeping them compliant
For the business: every operator who can take a job has the right insurance and documents for the work they do, and stays that way.
Under the hood:
A supplier's answers to a few questions decide which documents they must provide. Does the operator drive customers' vehicles? Do they transport them? Do they use lifting equipment? Public liability insurance is always required. Motor trade insurance, recovery insurance or a lifting-equipment report are required only when the work calls for them.
The In a Pickle team approves or rejects each document individually, with a reason. Each kind of work, such as jump starts or heavy recovery, is approved separately from the business itself.
Documents are stored privately in Amazon S3, never at a public address, and only the supplier and the In a Pickle team can open them.
A monitor checks expiry dates around the clock and warns the supplier 30, 14, 7 and 1 days ahead. When a document expires, the supplier is taken offline automatically and told why. Nobody can go online, appear in searches or accept a job with a document that is expired, pending or rejected.
Companies with several drivers
For the business: the platform works for a one-person operator and a recovery firm with a fleet.
Under the hood: a company can add drivers, each with their own login, approved driving licence and working radius. A sole trader is simply a company with one driver. The company chooses whether drivers accept jobs themselves, or the office accepts and assigns them. A driver who leaves is deactivated rather than deleted, so their job history stays intact.
When things don't go to plan
For the business: the awkward cases have fair, predictable answers, instead of a phone call and an argument.
Under the hood:
Cancelling: free before an operator accepts, a set fee afterwards, and locked once the operator is close. A customer who cancels because they feel unsafe pays nothing, gives a reason, and the job is flagged for review.
Nobody there: an operator who waits 10 minutes at an empty vehicle, or finds the booking was materially wrong, can close the job as a wasted callout.
Unable to complete: if the operator can't do the job, nothing is charged automatically. The job is parked for the In a Pickle team, with the operator's photos, while the card hold remains in place, and staff are warned before the hold expires.
Disputes: customers can report problems such as a no-show, wrong location or damage, with photos. Staff resolve each one with a recorded decision.
Reliability: a supplier who abandons jobs collects strikes, and three strikes means suspension.
Finishing a job is a handshake: the operator marks it done and the customer confirms. Jobs left waiting for the customer's confirmation are closed or escalated automatically.
Keeping contact on the platform
For the business: a marketplace only works if deals happen through it.
Under the hood: customers and operators can message each other from acceptance until after the job. Phone numbers and email addresses are removed from messages automatically, and those messages are flagged for review. The rule is written to catch contact details without mangling registrations and postcodes.
Running the business without a developer
For the business: the founder can change how the business runs today, not after the next deployment.
Under the hood:
More than 60 business settings, covering prices, fees, dispatch radius, tracking distances, hold times, document rules, data retention, email and maps, are edited in the admin and take effect the moment they are saved.
A launch switch puts a "coming soon" banner on every page and pauses new requests, while supplier sign-up and vetting carry on. That is what lets In a Pickle recruit operators before opening to the public.
A live dispatch board follows every active job in real time.
Passwords and keys for connected services are encrypted, and the admin only ever shows their last four characters.
Every significant admin action is written to an audit log: supplier approvals, document decisions, job resolutions, suspensions and settings changes.
A record of what was agreed
For the business: when a question comes up later, the platform can show exactly what each person agreed to and when.
Under the hood: every acceptance of the customer terms, cancellation policy, supplier terms or privacy policy is stored with the version accepted, the time and the IP address. When terms change, suppliers are asked to accept the new version. Records are anonymised automatically once their retention period ends, unless a dispute or a legal hold keeps them.
What was delivered
A complete three-sided marketplace, built from an idea.
Fixed, upfront prices, including a fair answer for "not sure".
Nearest-suitable-driver matching based on location, approvals and equipment.
Live tracking, with GPS-verified arrival.
Payments held until the job is settled, with partial charges where appropriate.
Automatic supplier payouts through Stripe.
Document-based supplier vetting, with automatic expiry enforcement.
Support for single operators and multi-driver firms.
Defined outcomes for cancellations, no-shows, unfinished jobs and disputes.
A back office where the founder controls the business rules directly.
Not just breakdowns
Take away the tow trucks and In a Pickle is a pattern many service businesses share: a customer needs help, a vetted professional nearby provides it, and the platform makes sure both sides are protected.
The same approach works for:
emergency trades, such as locksmiths, plumbers and electricians
mobile mechanics, tyre fitters and windscreen repair
cleaning, maintenance and property services
couriers and same-day delivery
care, tutoring and other visiting professionals
any business connecting customers with approved, independent providers
The building blocks are the same: supplier onboarding and vetting, document compliance, location-based matching, live tracking, held payments and payouts, dispute handling, and a back office the business controls.
If you have an idea for a platform like this, I can help turn it into an operating model and build it.
Technical stack
For readers interested in the technology:
Next.js 14 (App Router) and React 18 with Tailwind CSS; a Node.js API on Express with Socket.IO for real-time tracking and chat; MongoDB with Mongoose and geospatial indexes; Stripe Payment Element with manual capture and Stripe Connect payouts; Amazon S3 for private documents; MapLibre GL with OpenFreeMap tiles and OpenRouteService routing; the DVSA MOT History API; Nodemailer; Zod validation; and Google reCAPTCHA v3, all in TypeScript.
Have an idea for a platform?
Most marketplace ideas are simple to describe and hard to run. The value is in the rules: who pays when, who is trusted to do what, and what happens when things go wrong.
I start by working through how your business should operate, then build the software around it.
