Established pay-per-use + tiered revenue model (0–900 pulls/month)
BayLogic launched as a new initiative inside an established automotive company. The product vision was clear. The revenue model was not.
I designed the signup flow and core account dashboard while defining the pricing structure that governed how teams purchased and managed access.
There was no defined pricing structure, no volume thresholds, and no operational logic connecting pay-per-use access to subscription tiers. I established that framework.
Independent shops might download fewer than 80 specifications in a month. Multi-location operators could exceed 900.
A single pricing model would fail one end of that spectrum. The system needed to flex across usage levels without creating confusion or billing anxiety.
I established a dual-structure monetization system designed to scale from small independent shops to multi-location operators.
When usage is low or unpredictable shops can make as needed purchases at $12 / Pull, allowing for low-friction purchases and flexibility.
Volume-based tiers offered increasing monthly pull allowances with progressively discounted effective rates, providing natural upgrade incentive as usage grows
Discounted overage pricing and limited rollover reduced threshold friction while preserving predictable revenue behavior.
Overage pricing ($10.25 / pull) : Cheaper than $12 pay-as-you-go (so it feels fair). More expensive than most tier effective rates (so upgrading still makes sense).
Rollover cap (25%)
: Reduces “I’m wasting money” resentment and prevents unlimited liability.
Rollover expiration (60 days): Stops long-term accumulation and keeps usage tied to active subscription.
Subscription tier selection options
Dual-structure pricing model clarifying optimal ranges for pay-as-you-go vs. subscription tiers.
Mechanic shops operate with clear internal hierarchy: owners manage billing, technicians download specifications.
If pricing was self-serve but account control was not, the system would still rely on support intervention.
I designed a role-based architecture separating administrative control from usage access, embedding billing and permission logic directly into the platform.
Role-based account management moved billing and team changes from support to product.
Within four months more than 200 shop teams onboarded under the new model.
Revenue logic and account control lived inside the system itself. The platform scaled without proportional operational overhead.
While the architecture reduced friction, tier selection still required shops to estimate future demand. Today, I would integrate usage forecasting and adaptive upgrade guidance based on historical behavior.
The next iteration would move from static tiers toward responsive monetization logic, allowing the system to guide customers toward the most economically appropriate structure over time.
