Skip to content
Pablo.
Selected work

Side project

Connect Auto

Building a SaaS platform for vehicle dealerships.

Role
Co-founder & Full Stack Software Engineer
Period
2026 — Present
Type
Side project
Status
In development
  • Next.js
  • React
  • TypeScript
  • NestJS
  • Prisma
  • PostgreSQL
  • React Query
  • Zustand
  • TanStack Table
  • Tailwind CSS
  • Docker

01 / Overview

Connect Auto is a SaaS platform for garage operators and vehicle dealerships. The product brings CRM, inventory, customer service, proposals, reservations, sales, tasks, a calendar and a public dealership website into a single system.

It is a side project I am building as co-founder and engineer. My work covers product flows, frontend architecture, UI, API integration, domain understanding, some backend work with NestJS, and product decisions. The platform is still in development.

02 / Context

The context.

Dealership operations are often spread across spreadsheets, WhatsApp conversations and disconnected systems.

The product is being designed around those real workflows: how a lead arrives, how a vehicle is reserved, how a proposal is created and how a negotiation moves through the sales funnel.

03 / Challenge

What made it hard.

The hard part is not drawing screens. It is translating dealership workflows into rules that remain consistent across CRM, inventory, reservations, proposals and sales.

The interface also needs to deal with permissions, conversation assignment, complex forms and a Kanban whose movements depend on business rules instead of being completely free.

Flow

Conceptual sales path
  1. 01New lead
  2. 02First contact
  3. 03In progress
  4. 04Interest confirmed
  5. 05Visit / Test drive
  6. 06Proposal
  7. 07Negotiation
  8. 08Sale / Lost

A simplified view of the funnel — not the full CRM.

04 / Role

My role.

As co-founder and engineer, I participate in product decisions before implementing the interface.

My main work is on the frontend architecture and UI, while also integrating APIs and contributing to parts of the NestJS backend when a feature crosses that boundary.

05 / Work

What I actually built.

  • CRM funnel

    Modeling stages, ownership and the rules that move a lead through the funnel, including a Kanban with drag-and-drop that has to respect those rules.

  • Inventory and reservations

    Keeping vehicle availability, reservations and proposals aligned so the interface does not promise a unit the domain cannot sell.

  • Service distribution

    Routing conversations and tasks across the team, with permissions that change what each person can see and do.

  • Complex forms

    Proposals, vehicle data and customer records — reusable fields and validation instead of one-off screens.

  • Frontend architecture

    Component model, table primitives and a clear split between server state and client state as the product grows.

  • Public dealership site

    A public storefront for the inventory, fed by the same domain as the internal product.

State

Frontend state responsibilities

Server state

React Query

Remote data and cache

  • Leads
  • Vehicles
  • Tasks
  • Pipeline
  • Reservations
↓Interface↑

Client state

Zustand

Shared UI state

  • Filters
  • Draft state
  • Open panels
  • Kanban UI
  • Local workflow state

A conceptual split used in the frontend — not a full system architecture.

06 / Engineering

Decisions I would still make.

  • Server state and client state solve different problems

    React Query handles remote data and cache while Zustand handles shared UI state such as filters, drafts and interface behavior. Keeping those responsibilities separate makes synchronization and invalidation easier to reason about.

  • The funnel is a domain, not just a list of columns

    The Kanban represents business rules. A lead cannot always move freely if inventory, permissions or reservation state say otherwise. The columns are the interface. The rules behind them are the domain.

  • Reuse patterns, not entire pages

    Tables, forms, validation and permissions appear across several modules. I prefer reusable primitives for those recurring patterns instead of forcing unrelated pages into the same abstraction.

07 / Stack

  • Next.js
  • React
  • TypeScript
  • NestJS
  • Prisma
  • PostgreSQL
  • React Query
  • Zustand
  • TanStack Table
  • Tailwind CSS
  • Docker

08 / Impact

What I can stand behind.

The product is still in development. There are no production metrics to share yet.

The work so far has been about getting the domain, the architecture and the core flows right before talking about scale.

09 / Learned

What this work taught me.

  • If the funnel is unclear, the Kanban will be unclear. The domain has to be defined before the interface.

  • Most bugs in this kind of product are state bugs. Keeping server state and client state separate makes the UI easier to change.