Vehicle Compatibility · Technical Tire Search · Laravel · Livewire · Sales · Digital Accounting
Tire Fitment Engine + E-Commerce + Back-Office Accounting Digitalization
Project positioning
PishroTire was developed as a specialized web application for tire sales, with the main technical challenge centered on finding the correct tire through two different compatibility paths:
- by tire dimensions and technical specification, and
- by vehicle characteristics.
The system was implemented with Laravel and Livewire and combined:
- tire catalog management,
- vehicle-to-tire compatibility logic,
- technical filtering,
- responsive e-commerce,
- cart/order processing,
- and online accounting.
At the same time, the company’s accounting workflow was moved from a paper-based process to an online digital system.
The strongest portfolio framing is therefore:
An automotive tire fitment and sales platform that translates vehicle or tire specifications into compatible products and connects the customer-facing catalog directly to digital sales and accounting workflows.
It should not be reduced to:
“an online tire shop.”
The core engineering value is the fitment logic and business-process digitalization behind the storefront.
Classification
- Project Name: PishroTire
- Project Type: Automotive Fitment + E-Commerce + Online Accounting
- Industry: Tire Retail / Automotive
- Backend: Laravel
- Reactive UI: Livewire
- Primary Domain: Tire Compatibility / Fitment
- Secondary Domains: Product Catalog, Sales, Shopping Cart, Orders, Accounting
- Search Modes: By Tire Size / By Vehicle
- Vehicle Dimensions: Brand, Model, Trim, Year, Tire Size
- Tire Dimensions: Width, Aspect Ratio, Rim Diameter
- Portfolio Relevance: Very High
- Suggested CV Relevance: Tier A — Domain Modeling, Laravel, Livewire, E-Commerce, Back-Office Digitalization
Website Card
Title:
PishroTire — Automotive Tire Fitment & Sales Platform
Subtitle:
Vehicle Compatibility · Tire Size Search · Laravel Livewire · Online Accounting
One-line Description:
Built a Laravel/Livewire tire-sales platform with a dual fitment engine that finds compatible products either by vehicle make/model/trim/year or by tire width/aspect-ratio/rim-size, while also digitizing the company’s accounting workflow.
Categories:
- Laravel
- Livewire
- Automotive
- Tire Fitment
- E-Commerce
- Product Filtering
- Vehicle Compatibility
- Online Accounting
- Sales Automation
Concept Tags:Laravel · Livewire · Vehicle Fitment · Tire Size · E-Commerce · Product Catalog · Accounting · Responsive Web
Executive Summary
PishroTire solved a common retail problem:
Customers do not always know the exact tire specification their vehicle requires.
Some customers know:
205 / 55 R16
while others only know:
Car Brand
Model
Trim
Year
The platform therefore supported two independent discovery paths:
Path A
Tire Width
→ Aspect Ratio
→ Rim Diameter
→ Matching Tires
and:
Path B
Vehicle Brand
→ Vehicle Model
→ Vehicle Trim
→ Production Year
→ Compatible Tire Size
→ Matching Tires
This made the application usable both by technically informed customers and by ordinary drivers who only knew their vehicle details.
Core Product Problem
A generic e-commerce system can filter products by category and price.
A tire store needs something more specialized:
Compatibility.
A tire is only useful if it is suitable for the target vehicle or its required technical dimensions.
Therefore the system needed to model not only products, but also the relationship between:
Vehicle
↔
Tire Size
↔
Tire Product
This relationship is the core domain of the project.
Main Search Mode 1 — By Tire Specification
The first search path used the three fundamental tire-size dimensions:
Width
Aspect Ratio
Rim Diameter
Example:
205 / 55 R16
Interpretation:
205 = Tire Width
55 = Aspect Ratio
16 = Rim Diameter
The user could select these values and receive matching products.
Technical Tire Filter
Conceptually:
Select Width
↓
Select Aspect Ratio
↓
Select Rim Diameter
↓
Query Tire Catalog
↓
Compatible Products
This is a straightforward path for users who already know the required tire size.
Main Search Mode 2 — By Vehicle
The second path was more domain-specific.
A customer could search using vehicle information:
Brand
Model
Trim
Year
and the system would resolve the correct tire fitment.
Conceptually:
Vehicle Brand
↓
Vehicle Model
↓
Vehicle Trim
↓
Production Year
↓
Supported Tire Size(s)
↓
Matching Tire Products
Why Vehicle-Based Search Is More Valuable
Many customers do not know whether their car uses:
205/55R16
or:
215/50R17
The vehicle-based search removes that technical burden.
The user can think in familiar terms:
"My car is Brand X, Model Y, Trim Z, Year N."
and the platform handles the conversion to compatible tire dimensions.
Vehicle-to-Tire Fitment Engine
The strongest technical concept of the application is:
Vehicle-to-Tire Fitment
A conceptual data relationship:
Vehicle
↓
Fitment
↓
Tire Size
↓
Tire Products
Vehicle Model
A vehicle record can be represented conceptually as:
Vehicle
├── Brand
├── Model
├── Trim
├── Production Year
└── Supported Tire Sizes
Tire Size Model
A tire size is a technical entity independent of a specific tire brand.
TireSize
├── Width
├── Aspect Ratio
└── Rim Diameter
Example:
205
55
16
Product Model
A product then references a tire size.
TireProduct
├── Brand
├── Model
├── Tire Size
├── Production Year
├── Price
├── Discount
├── Inventory
└── Product Image
Important Relational Design
A vehicle may support more than one valid tire size.
Therefore a scalable design should use:
Vehicle
↕
VehicleFitment
↕
TireSize
rather than storing only one tire-size field directly inside the vehicle table.
Many-to-Many Fitment
Conceptually:
Vehicle A
├── 205/55 R16
├── 215/50 R17
└── 225/45 R18
This allows the system to support:
- standard factory size,
- alternative compatible sizes,
- trim-specific differences,
- year-specific differences.
Only historically confirmed fitment data should be claimed as implemented; this structure is the robust architectural model.
Cascading Filtering
The vehicle search contains dependent dropdowns.
Conceptually:
Brand
↓
Model
↓
Trim
↓
Year
↓
Size
Each selection constrains the available values in the next step.
Why Livewire Fits This Project
This is an excellent use case for Livewire.
Without a reactive framework, the frontend would need repeated manual AJAX calls:
Brand Change
→ JavaScript
→ AJAX
→ Backend
→ JSON
→ Populate Model Select
With Livewire:
Brand Property Changes
→ Component Reacts
→ Models Reload
→ UI Updates
This greatly simplifies dependent filtering.
Historical Technology Evolution
Earlier projects in the portfolio relied heavily on manually written AJAX interactions.
PishroTire represents a later architectural stage:
Older PHP Projects
Manual AJAX
↓
Laravel
↓
Livewire
This is a useful technical evolution story.
Customer-Facing UX
The screenshots show two clear tabs:
Based on Vehicle Type
Based on Tire Size
This is an important UX decision because different users think about the product differently.
Search by Vehicle — UX
The interface asks the user to select:
Brand
Model
Trim
Year
Size
This guides a non-technical customer through the compatibility process.
Search by Tire Size — UX
The second mode asks for:
Tire Width
Aspect Ratio
Rim Diameter
This supports users who already know their technical tire specification.
Educational Visualization
The tire-size interface includes a visual representation of a tire size.
This helps explain a notation such as:
205/55R16
instead of assuming the user understands automotive tire terminology.
This makes the system partially an educational product-selection interface, not merely a filter.
Product Catalog
After filtering, matching products are displayed as product cards.
Visible card-level information includes:
- tire image,
- tire/model name,
- tire size,
- production year,
- price,
- discount,
- quantity,
- add-to-cart action.
Product Discovery Flow
Search
↓
Compatible Tire Results
↓
Compare
↓
Select Quantity
↓
Add to Cart
E-Commerce Flow
The customer-facing commercial flow can be represented as:
Compatibility Search
↓
Product Catalog
↓
Product Selection
↓
Cart
↓
Order
↓
Sale
Compatibility Before Commerce
The platform's most important design choice is that fitment comes before sale.
A generic shop says:
Choose Product
PishroTire says:
First Find What Fits
Then Buy
This reduces the chance of ordering an incompatible tire.
Product Categories
The interface also visibly distinguishes broader tire categories such as:
- Passenger Car
- Truck / Bus
- Agricultural
This indicates that the platform structure was designed with category expansion in mind.
Passenger Vehicle Focus
The described primary implementation focused on passenger-car tire sales.
The broader category layout allowed the system to support additional product domains.
Product Master Data
A clean product schema could include:
tires
├── id
├── brand_id
├── model
├── tire_size_id
├── production_year
├── price
├── discount
├── inventory_quantity
├── image
└── active
Tire Size Master
tire_sizes
├── id
├── width
├── aspect_ratio
└── rim_diameter
This prevents repeated tire-size strings and supports normalized filtering.
Vehicle Master
vehicles
├── id
├── brand_id
├── model_id
├── trim_id
└── production_year
Vehicle Fitment Table
vehicle_fitments
├── vehicle_id
└── tire_size_id
This is the core compatibility table.
Brand / Model / Trim Hierarchy
A normalized vehicle hierarchy:
VehicleBrand
↓
VehicleModel
↓
VehicleTrim
↓
ProductionYear / Variant
This avoids storing repeated text for every fitment row.
Search Query Strategy
For vehicle-based filtering:
Vehicle Input
↓
Resolve Vehicle Record
↓
Find TireSize IDs
↓
Find Tire Products
Tire-Based Search Strategy
For tire-size filtering:
Width + Aspect Ratio + Rim
↓
Resolve TireSize
↓
Find Tire Products
Shared Result Pipeline
Both search paths converge on the same product catalog:
Vehicle Search ─┐
├→ TireSize → Product Query → Results
Tire Search ────┘
This is a strong architectural pattern.
Single Source of Truth
The same TireSize entity should drive:
- technical search,
- vehicle fitment,
- product classification.
This prevents inconsistent data.
Inventory
Because products can be added to a shopping cart, the platform naturally needs inventory state.
Conceptually:
Product
├── Available Quantity
├── Reserved Quantity
└── Sold Quantity
Historical inventory behavior should only be described where source evidence exists.
Stock Validation
A modern implementation should validate stock when:
Add to Cart
Checkout
Order Confirmation
not only when displaying the product.
Product Reservation
A stronger checkout architecture can reserve stock temporarily:
Available
↓
Cart / Checkout Reservation
↓
Order Confirmed
This is a modernization recommendation.
Price and Discount
The product cards visibly include price and discount indicators.
The platform therefore supported commercial presentation beyond technical compatibility.
Shopping Cart
The user could select quantity and add compatible tires to the cart.
Conceptually:
CartItem
├── Product
├── Quantity
├── Unit Price
└── Discount
Order Model
Order
├── Customer
├── Items
├── Total
├── Payment State
├── Accounting Reference
└── Status
Customer Registration
The interface visibly includes:
Sign Up / Login
indicating authenticated customer functionality.
Front Office vs Back Office
PishroTire combined two major transformation areas.
Front Office
Vehicle Search
Tire Search
Product Catalog
Cart
Sales
Back Office
Accounting
Financial Records
Sales Accounting
Administrative Processing
Accounting Digitalization
At the same time as the customer-facing platform was developed, the company's accounting process was moved from paper-based workflows to an online system.
This is a major part of the project.
Before
Conceptually:
Paper Accounting
Manual Records
Disconnected Sales Information
After
Online Sales
↓
Digital Accounting
↓
Centralized Records
Accounting Platform
The user specifically confirmed that an online accounting system was implemented.
The exact historical accounting modules should not be invented where screenshots or documentation are unavailable.
Safe portfolio wording:
The project included the transition of the company’s accounting workflow from paper-based processing to an online accounting system integrated with the wider sales platform.
Why This Matters
A webshop alone digitizes the customer interface.
This project also digitized the company's internal financial workflow.
Therefore it represents:
Customer-Side Digital Transformation
+
Back-Office Digital Transformation
Sales-to-Accounting Integration
A strong architecture should connect:
Order
↓
Invoice / Sale
↓
Accounting Record
so that the same transaction does not need to be re-entered manually.
Avoid Duplicate Data Entry
One of the main benefits of integration is reducing:
Web Order
→ Manual Re-entry into Accounting
and replacing it with:
Web Order
→ Accounting Flow
Online Accounting — Modern Module Boundaries
A clean modern system could separate:
Sales
Invoices
Payments
Accounts
Transactions
Reports
Historical implementation details should be documented only where preserved.
Reporting
Natural reporting capabilities for the domain include:
Sales by Brand
Sales by Tire Size
Sales by Vehicle
Inventory by Product
Revenue by Period
These are logical V2 capabilities and should not be claimed as historical unless documented.
Vehicle Search Analytics
Because users search by car characteristics, the system can potentially reveal demand patterns such as:
Most searched vehicle brands
Most searched models
Most required tire sizes
This is a valuable future analytics direction.
Tire Search Analytics
Similarly:
Most searched widths
Most searched rim sizes
Most purchased tire sizes
can support procurement.
Procurement Opportunity
Once sales and fitment data are structured, the company can improve purchasing decisions.
Example:
Demand by Tire Size
↓
Inventory Planning
↓
Purchase Forecast
This is a modernization opportunity.
SEO Value
A fitment catalog naturally supports SEO-oriented pages such as:
Tires for Vehicle X
Tires 205/55R16
Brand Y Tires
This is a possible V2 direction, not a confirmed historical feature.
Performance Considerations
Vehicle compatibility queries may become large.
A scalable implementation should index:
vehicle_id
tire_size_id
width
aspect_ratio
rim_diameter
brand_id
N+1 Query Avoidance
Laravel relationships should use eager loading for result pages.
Example:
Tire
→ Brand
→ Size
→ Inventory
to avoid excessive database queries.
Caching
Stable reference data can be cached:
Vehicle Brands
Models
Trims
Tire Sizes
while inventory and pricing need fresher data.
Livewire Component Design
A clean UI architecture could use components such as:
VehicleSearch
TireSizeSearch
ProductGrid
Cart
VehicleSearch Component
State:
brand
model
trim
year
size
When one field changes, dependent fields reset/reload.
Dependency Reset
Example:
Brand Changed
↓
Reset Model
Reset Trim
Reset Year
Reset Size
This prevents inconsistent combinations.
TireSizeSearch Component
State:
width
aspect_ratio
rim_diameter
The available options can be constrained by existing catalog data.
ProductGrid Component
Receives the resolved tire-size selection and displays compatible products.
URL State
A modern implementation could store search filters in the URL.
Example:
?width=205&ratio=55&rim=16
or vehicle filters.
This improves:
- shareability,
- browser history,
- SEO.
Validation
Inputs should be validated server-side even when dropdowns are generated dynamically.
The backend should verify that:
Brand + Model + Trim + Year
is a valid combination.
Fitment Integrity
The system should never assume that a user-selected size belongs to the selected vehicle unless the fitment relation confirms it.
Security
E-commerce and accounting require:
- authentication,
- authorization,
- CSRF protection,
- secure password hashing,
- server-side price validation.
Price Tampering Protection
The browser must never be trusted for the final price.
Correct flow:
Product ID + Quantity
↓
Server Loads Current Price
↓
Server Calculates Total
Accounting Authorization
Back-office accounting pages should be accessible only to authorized staff.
Audit Trail
A modern version should track important actions such as:
Price Changed
Inventory Changed
Order Updated
Payment Registered
Accounting Record Updated
Historical Evidence Strategy
The available screenshots strongly document three parts of the system.
Screenshot 1 — Vehicle Search
The first screenshot shows:
- vehicle-based filtering,
- brand,
- model,
- trim,
- year,
- tire size,
- passenger / truck-bus / agricultural categories.
Recommended caption:
Vehicle-based tire fitment interface allowing customers to identify compatible tires through brand, model, trim, year, and size.
Screenshot 2 — Tire Size Search
The second screenshot shows:
- tire width,
- aspect ratio,
- rim diameter,
- tire-size visualization.
Recommended caption:
Technical tire-size search with a visual explanation of width, aspect ratio, and rim diameter.
Screenshot 3 — Product Catalog
The third screenshot shows:
- product cards,
- images,
- tire specification,
- price,
- discount,
- quantity,
- add-to-cart.
Recommended caption:
Compatible tire result catalog with pricing, discount, production information, quantity selection, and cart integration.
Historical vs Modern Boundary
Confirmed Historical Capabilities
- Laravel application.
- Livewire-based interaction.
- Tire sales.
- Passenger vehicle tire focus.
- Tire search by:
- width,
- aspect ratio,
- rim diameter.
- Vehicle search by:
- brand,
- model,
- trim,
- year,
- tire size.
- Product result catalog.
- Product cards.
- Pricing.
- Discounts.
- Quantity.
- Add to cart.
- Responsive customer-facing interface.
- Sign up / login.
- Online accounting implementation.
- Transition of accounting from paper-based process to digital/online workflow.
Architectural / V2 Recommendations
- normalized VehicleFitment model,
- many-to-many vehicle ↔ tire-size relationship,
- inventory reservation,
- procurement forecasting,
- URL-based filters,
- caching,
- detailed audit logs,
- integrated reporting.
What Not to Overclaim
Do not claim:
- official OEM fitment certification,
- national vehicle database integration,
- manufacturer API integration,
- automatic procurement,
- specific accounting modules,
unless supported by preserved project evidence.
My Role
A precise portfolio description:
I developed PishroTire as a Laravel/Livewire tire-sales platform with a dual fitment system: customers could find products either through tire dimensions or through vehicle brand, model, trim, and production year. The project also included product catalog and cart workflows and moved the company’s accounting process from paper-based operations to an online digital system.
Engineering Highlights
- Laravel backend.
- Livewire reactive UI.
- Cascading vehicle filters.
- Tire-size filtering.
- Vehicle-to-tire fitment model.
- Responsive e-commerce catalog.
- Product search by technical specification.
- Product search by vehicle compatibility.
- Product cards with pricing and discount.
- Cart integration.
- Customer authentication.
- Online accounting digitalization.
- Front-office + back-office integration.
Domain Modeling Highlights
The project required translating automotive tire knowledge into structured software relationships.
Core concept:
VEHICLE
↓
FITMENT
↓
TIRE SIZE
↓
PRODUCT
This is the defining technical characteristic of the platform.
Business Transformation Highlights
The system digitized both sides of the business:
Customer Product Discovery
+
Company Accounting
This makes the project more significant than a standard e-commerce implementation.
Career Evidence
This project demonstrates experience with:
- Laravel
- Livewire
- Relational Data Modeling
- Dependent Filtering
- Automotive Fitment
- E-Commerce
- Product Catalog
- Cart / Sales Workflow
- Responsive UX
- Digital Accounting
- Business Process Digitalization
CV Relevance
Tier A — Domain-Driven E-Commerce
The system solved a product-selection problem that generic e-commerce platforms do not solve automatically.
The strongest technical story is:
VEHICLE DATA
+
FITMENT RULES
+
PRODUCT DATA
+
LIVEWIRE UX
+
SALES
+
ACCOUNTING
Interview Story
Situation
A tire retailer needed an online platform where customers could reliably find compatible tires without always knowing technical tire specifications.
At the same time, the company’s accounting process was still paper-based.
Task
The project needed to solve two different problems:
- provide a technically correct tire-selection flow,
- digitize the commercial/accounting workflow.
Action
I developed the system with Laravel and Livewire.
I created two search paths:
- technical search by tire width, aspect ratio, and rim diameter,
- compatibility search by vehicle brand, model, trim, year, and tire size.
Both paths converged on the same tire catalog.
The application then presented compatible products with price, discount, quantity, and cart actions.
In parallel, the company’s accounting workflow was moved from paper-based processing into an online accounting system.
Result
The platform gave customers a much simpler way to identify the correct tire while also moving internal business processes toward a centralized digital workflow.
Suggested Website Full Description
Overview
PishroTire is an automotive tire fitment, e-commerce, and accounting platform developed with Laravel and Livewire.
The application was designed around a central question:
Which tire is compatible with this vehicle?
Dual Search Model
Customers could search either by:
Tire Specification
- width,
- aspect ratio,
- rim diameter.
or by:
Vehicle
- brand,
- model,
- trim,
- production year,
- tire size.
Fitment Engine
Vehicle information was translated into compatible tire sizes, which were then used to retrieve available products.
E-Commerce
Compatible products were displayed as product cards with:
- image,
- technical specification,
- price,
- discount,
- quantity,
- add-to-cart.
Laravel + Livewire
Livewire was used to implement dynamic dependent filters without requiring a large amount of manual AJAX code.
Accounting
The project also included digitization of the company’s accounting process, moving it from paper-based workflows to an online system.
Short Website Card Copy
PishroTire — Automotive Tire Fitment & Sales Platform
Built a Laravel/Livewire tire-sales platform with vehicle-based and technical tire-size filtering, compatible product discovery, e-commerce workflows, and an online accounting system replacing paper-based processes.
Alternative One-Liners
Fitment-oriented
Built a vehicle-to-tire fitment engine that maps car brand, model, trim, and year to compatible tire sizes and products.
Laravel-oriented
Developed a Laravel/Livewire automotive e-commerce platform with cascading vehicle filters, tire-size matching, cart flows, and online accounting.
Business-oriented
Digitized both customer tire selection and the company’s paper-based accounting workflow in one integrated platform.
UX-oriented
Designed dual tire discovery paths for both technical users and customers who only know their vehicle details.
Suggested Website Slug
/projects/pishrotire-fitment-ecommerce
Alternative:
/projects/automotive-tire-fitment-platform
Cover Direction
Title
PishroTire
Main Subtitle
Automotive Tire Fitment & Sales Platform
Supporting Line
Vehicle Compatibility · Tire Size Search · Laravel Livewire · Accounting
Visual Direction
A premium square technical cover should show:
- passenger vehicle silhouette,
- tire,
205 / 55 R16,- vehicle compatibility arrows,
- product catalog card,
- shopping cart,
- accounting/dashboard symbol.
Primary visual story:
VEHICLE
→ FITMENT
→ TIRE
→ BUY
→ ACCOUNT
Avoid making the cover look like only:
- a tire advertisement,
- a generic online store,
- an automotive landing page.
The core message should be:
technical tire compatibility connected to digital sales and accounting.
Modern V2 Architecture
A modernized architecture could use:
Laravel
├── Vehicle Catalog
├── Vehicle Fitment
├── Tire Catalog
├── Inventory
├── Cart
├── Orders
├── Accounting
└── Reporting
with:
Livewire
for interactive filtering and operational screens.
Suggested Modern Database Structure
vehicle_brands
vehicle_models
vehicle_trims
vehicles
tire_sizes
vehicle_fitments
tire_brands
tires
inventory
customers
carts
cart_items
orders
order_items
accounting_transactions
payments
Indexing Strategy
Important indexes:
vehicle_fitments(vehicle_id, tire_size_id)
tire_sizes(width, aspect_ratio, rim_diameter)
tires(tire_size_id)
tires(brand_id)
Testing Strategy
Fitment Tests
- valid vehicle returns expected tire size,
- invalid vehicle combination returns no result,
- multiple sizes can belong to one vehicle.
Tire Filter Tests
- exact width/ratio/rim match,
- unavailable size returns no products.
Livewire Tests
- changing brand resets downstream fields,
- selecting model loads only related trims,
- changing trim resets year/size.
Cart Tests
- compatible product can be added,
- quantity validation,
- current server price used.
Accounting Tests
- order generates expected accounting flow,
- payment updates financial state.
Only historical accounting behaviors that are recovered should be asserted in archival tests.
Example Fitment Test
Given:
Vehicle = Brand X / Model Y / Trim Z / 2022
When:
Search compatible tires
Then:
Return tire sizes linked through vehicle_fitments
Example Tire Search Test
Given:
Width = 205
Aspect Ratio = 55
Rim = 16
Then:
Return only products with 205/55R16
Example Cascading Filter Test
Given:
Brand A selected
When:
Model changes
Then:
Trim, Year and Size are reset
Product Integrity Principle
Vehicle search and technical tire search must always converge on the same canonical tire-size records.
This prevents:
Vehicle Search says 205/55R16
but
Product Search uses another representation
Final Portfolio Statement
The project should not be introduced simply as:
“a tire e-commerce website.”
Its real engineering value is the fitment layer and the integration of front-office and back-office processes.
The strongest description is:
I developed PishroTire as a Laravel/Livewire automotive tire fitment and sales platform, allowing customers to find compatible products either by tire dimensions or by vehicle brand, model, trim, and year, while also digitizing the company’s paper-based accounting workflow into an online system.
Conceptually:
VEHICLE
↓
FITMENT
↓
TIRE SIZE
↓
PRODUCT
↓
CART / SALE
↓
ONLINE ACCOUNTING