Skynetrix
Multi-Tenant Automotive SaaS Backend
Backend-first platform architecture for automotive repair and sales shops, combining tenant management, shop workflows, customer data, usage-based billing, and payments.
Implementation Focus
What I implemented
Designed and built the backend foundation for a multi-tenant automotive SaaS platform, including service boundaries, tenant-aware data modeling, role-based access, workflow logic, usage-based billing, and payment processing.
Problem
Independent automotive repair and sales shops often rely on disconnected tools for shop workflows, CRM, customer communication, vehicle data, payments, and reporting. This creates fragmented data, duplicated effort, weak customer retention, and limited visibility into the full relationship between customers, vehicles, jobs, and revenue.
Approach
Built Skynetrix as a backend-first, API-driven platform using modular services connected through a custom API gateway. The system models real shop workflows from customer and vehicle intake through quotes, repair orders, advisor review, and payment, while also supporting multi-tenant account structures, role-based access, usage tracking, and Stripe-powered billing.
Outcome
Established the backend foundation for a platform that can support tenant registration, multi-location shop setup, user roles, customer and vehicle relationships, repair workflows, payments, and usage-based billing.
Constraints
- Built as a solo developer while learning system architecture, microservices, billing, and workflow modeling.
- Automotive shop workflows vary heavily, requiring flexible logic instead of rigid one-size-fits-all flows.
- Usage-based billing had to work across multiple services, not just one isolated feature.
- Frontend dashboards and AI features were intentionally deferred so the backend foundation could be mapped first.
Tradeoffs
- Prioritized flexibility and long-term architecture over speed of MVP delivery.
- Deferred full CRM, AI, telematics, and customer dashboard features until core shop workflows and billing were established.
- Chose a modular service structure to keep domains separated, even though it increased cross-service complexity.
Ownership
What I owned
Execution Breakdown
How the work was implemented
System Architecture
Skynetrix was designed as a modular backend system where major business domains are separated into services but connected through a custom API gateway.
API Gateway
Acts as the central routing layer for communication between frontend clients and backend services.
Tenant Management
Supports account ownership, tenant-aware data separation, and multi-location shop structures.
User Management
Handles account creation, customer registration, shop-side registration, and role-aware access patterns.
Vehicle Management
Models vehicles as first-class records tied to customers, families/groups, shops, and future service history.
Shop Workflow Services
Includes job catalog, quote, estimate, repair order, and shop profile logic to model real repair operations.
Billing & Payments
Uses Stripe for payments and Redis/BullMQ for background usage tracking and billing aggregation.
Customer-Centric Data Model
A major design decision was treating customers and vehicles as connected long-term relationships instead of isolated transactions.
Family / Group Profiles
Customers can group vehicles together so shops can understand household-level vehicle relationships instead of creating disconnected records.
Preferred Shops
Customers can select preferred shops, supporting a future customer-facing dashboard and multi-shop ecosystem.
Customer-Owned Data Direction
The system is designed so customers can eventually access their vehicle history directly instead of relying on printed invoices, text messages, or third-party vehicle history tools.
Billing & Usage Logic
Skynetrix uses usage-based billing because automotive shops experience seasonality, and a flat monthly fee can become misaligned with revenue during slow months.
Tracked Usage Events
Planned billable events include customer creation, appointments, customer messaging, ticket creation, and a percentage of Stripe-paid tickets.
Background Processing
Redis and BullMQ support recurring usage tracking and monthly billing calculations across services.
Stripe Integration
Stripe handles payment processing for customer payments and platform billing workflows.
Future AI & Automation Layer
AI was intentionally deferred from the MVP, but the backend is being designed to support future intelligence across customer retention, technician performance, and communication workflows.
Customer Engagement
Future AI could identify when customers should be contacted, which communication windows perform best, and when follow-ups or reminders should be triggered.
Technician Performance
Future analytics could help shops understand which technicians perform best on specific job types and where comebacks or inefficiencies occur.
Phone & Communication Intelligence
A future Twilio-style phone integration could capture calls, extract customer intent, and reduce manual advisor data entry.
Workflow
System flows
Tenant & Shop Registration Flow
- 1A shop owner creates a tenant account.
- 2The system associates the tenant with one or more shop locations.
- 3The first admin user is registered and tied to the tenant.
- 4Future users can be added under role-based access rules.
Customer & Vehicle Flow
- 1A customer creates an account.
- 2Customer data is linked to a tenant-aware context.
- 3Vehicles are added to the customer profile.
- 4Vehicles can be associated with families/groups and preferred shops.
- 5Future repair history can be surfaced back to the customer.
Job to Payment Flow
- 1A job is created for a vehicle.
- 2The job is converted into a quote.
- 3The customer approves all or part of the quote.
- 4Approved work becomes a repair order.
- 5Repair order work can be assigned to one or more technicians.
- 6Technicians mark work complete.
- 7Advisor reviews and approves the completed work.
- 8The customer receives the final amount due.
- 9Payment is processed through Stripe or recorded through another payment method.
Usage-Based Billing Flow
- 1Billable events occur across services.
- 2Usage events are recorded with tenant context.
- 3Redis/BullMQ support background aggregation.
- 4Monthly usage is calculated.
- 5Tenant billing is processed through Stripe.
Results
Impact and outcomes
Backend Foundation Built
Core backend services were mapped and partially implemented across tenant management, user management, vehicles, shop profiles, job catalogs, quotes, estimates, repair orders, payments, vehicle sales, usage tracking, and early CRM concepts.
Real Automotive Workflows Modeled
The platform models actual repair shop workflows instead of generic CRUD data, including customer approval, technician assignment, advisor review, and payment handling.
Usage-Based Billing Established
Billing logic was designed around real platform usage so shop costs can scale more closely with actual activity and revenue seasonality.
Customer Experience Direction Defined
The system creates a foundation for customer-facing vehicle history, family vehicle management, preferred shops, and proactive service communication.
Reflection
What I learned
What worked
- The project exposed the real complexity behind automotive operations and clarified why customer, vehicle, shop, and payment data need to be connected.
- Microservices helped separate major business domains and made the platform easier to reason about conceptually.
- Usage-based billing created a business model that better matches the seasonality of independent automotive shops.
What I’d improve
- Start with a narrower vertical slice before expanding into many services.
- Define frontend interaction patterns earlier so backend workflows are easier to validate against real user behavior.
- Create cleaner service boundaries to reduce cross-service complexity.
- Validate workflow assumptions with more shop owners before expanding feature depth.
Key takeaway
Skynetrix taught me how quickly real business workflows create technical complexity, and why implementation requires more than building features — it requires modeling how people, data, permissions, payments, and decisions actually move through a business.