ARCHITECTING A
0-TO-1 REVENUE ENGINE

Users were there. Transactions weren't. Here's what was in the way.

THE
PROBLEM

Traffic without transactions


Tinker is an on-demand video consultation app connecting car owners with mechanics. When I joined, the app had real user traffic and genuine demand. It also had a 100% bounce rate at the paywall.

This was a known issue. What wasn't known was why.

I audited support tickets and ran user interviews. The answer wasn't price. Users were willing to pay. The blockers were trust and transparency: billing felt like a black box, and there was no way to evaluate a mechanic's credentials before committing to a session. In a category where bad advice costs real money, users needed to feel safe before they would pay.

THE
REFRAME

Fix the floor before building the ceiling


Leadership wanted to launch a referral program to accelerate growth.

I proposed deferring it.

A referral engine multiplies your conversion rate. If that rate is zero, there is nothing to multiply. There was pushback at first, but the logic held: fixing the transaction before scaling acquisition is the only sequence that works. The team aligned and we shelved the referral program to focus entirely on removing the barriers between a willing user and a completed payment.

THE
APPROACH

PHASE 1

PHASE 2

PHASE 3

The user journey was redesigned to focus on reducing friction and gaining customer trust. The number of screens between onboarding and the paywall were reduced to minimize friction, while marketing copy about the call mechanism and payment process was added to the paywall.

Mechanic credentials and vetting standards were embedded directly into the matching flow so users could evaluate the expert before getting on the call. Seeing the person first changed the nature of the decision.

We also worked with engineering to build fail-safe billing triggers after support tickets flagged that users were being charged for dropped calls. A quick fix with an outsized impact on trust.

De-risk the Transaction

One-off transactions don't build a business. User feedback showed people wanted to return to mechanics they had worked with before.

I scoped and pushed for a Reconnect feature that let users book the same mechanic directly. It turned a transactional product into a service relationship. Adoption hit 30% within the first month.

Build for Repeat Use

An intake form to capture Year/Make/Model metadata was added to the session start flow.

Asking for vehicle details upfront served three purposes: matching, giving mechanics better context, and it signaling to users that this was a professional service tailored to their specific situation, not a generic Q&A.

The addition of the intake form increased match rate by 20% and user satisfaction improved in qualitative feedback.

Increase Perceived Value

THE
RESULTS

30%

Reconnect Feature Adoption

40%

MoM Revenue Growth

$15K

MRR at Pilot Close

Note on scale: Tinker was an early-stage pilot within a major automotive OEM innovation lab. $15k MRR was the first meaningful revenue milestone the product had hit. The 40% month-over-month conversion growth is the more telling signal.

First revenue.
Reduced support load.
Real retention signal.

75%

Fewer Support Tickets

THE
TAKEAWAY

You cannot multiply zero


Not implementing the referral program was the right decision. Growth tactics only work when the core transaction works. Fixing conversion before scaling acquisition is not a conservative choice; it's the only logical sequence. Every growth lever downstream depends on it.

Previous
Previous

SKU Deduplication Initiative