<h2>The Problem</h2>
<p>Buying a car means visiting dozens of websites. Manufacturer sites show specs differently. Regional pricing varies wildly. Comparing a Toyota to a Honda means opening multiple tabs and manually cross referencing data that doesn't quite match up.</p>
<p>I wanted to compare cars the same way I'd compare laptops on a spec comparison site. Side by side, with consistent data points, across different markets. That platform didn't exist.</p>
<h2>What I Built</h2>
<p><a href="https://vehiq.tech">Vehiq</a> (Vehicle + IQ) aggregates data from 49,000+ vehicles across 219 brands. Users can compare up to 4 cars side by side with 50+ specifications, filter by body type, and see pricing across multiple markets including Vietnam, Philippines, Japan, UK, India, Australia, Singapore, EU, and Canada.</p>
<h2>The Journey</h2>
<p>I thought the hard part would be building scrapers. I was wrong. Scraping was straightforward. The real challenge was making sense of data that was never meant to be compared.</p>
<h3>Tech Stack</h3>
<table>
<thead>
<tr>
<th>Layer</th>
<th>Technology</th>
<th>Why I Chose It</th>
</tr>
</thead>
<tbody>
<tr>
<td>Frontend</td>
<td><a href="https://nextjs.org/">Next.js 15</a></td>
<td>App Router, ISR for SEO</td>
</tr>
<tr>
<td>Language</td>
<td><a href="https://www.typescriptlang.org/">TypeScript</a></td>
<td>Type safety for complex data</td>
</tr>
<tr>
<td>Database</td>
<td><a href="https://supabase.com/">Supabase</a></td>
<td>PostgreSQL with full text search</td>
</tr>
<tr>
<td>Validation</td>
<td><a href="https://zod.dev/">Zod</a></td>
<td>Runtime schema validation</td>
</tr>
<tr>
<td>Styling</td>
<td><a href="https://tailwindcss.com/">Tailwind CSS 4</a></td>
<td>Utility first, fast iteration</td>
</tr>
<tr>
<td>Hosting</td>
<td><a href="https://vercel.com/">Vercel</a></td>
<td>Edge caching, easy deploys</td>
</tr>
</tbody>
</table>
<pre><code>flowchart LR
    subgraph Sources["Data Sources"]
        S1[AutoTrader]
        S2[CarGurus]
        S3[Manufacturer Sites]
    end

    subgraph Processing["Data Pipeline"]
        R[(Raw Data)]
        V[Zod Validation]
        N[Normalization]
    end

    subgraph Storage["Database"]
        PG[(PostgreSQL&#x3C;br/>49k+ vehicles)]
    end

    subgraph App["Application"]
        API[REST API]
        FE[Next.js Frontend]
    end

    S1 &#x26; S2 &#x26; S3 --> R
    R --> V --> N --> PG
    PG --> API --> FE
</code></pre>
<h2>What Building This Taught Me</h2>
<h3>1. Data quality is the product</h3>
<p>I spent 70% of my time on data cleaning and normalization, 30% on the UI. Users don't care about your beautiful interface if the specs are wrong.</p>
<p>One site lists horsepower as "300 hp," another as "300HP," another as "224 kW." Engine displacement might be "2.0L" or "1998cc" or "2000 cm³." Making these comparable required building a normalization pipeline more complex than the UI itself.</p>
<pre><code>// Real example of variations I had to handle
const horsepowerVariations = [
  '300 hp',
  '300HP',
  '300 bhp',
  '300ps',
  '224 kW',
  '223.71kW',
  '224kw',
]

// Normalized to:
interface NormalizedPower {
  value: number // 300
  unit: 'hp' // standardized
  kw: number // 224 (always include kW conversion)
}
</code></pre>
<p>Resources that helped:</p>
<ul>
<li><a href="https://zod.dev/">Zod Documentation</a> for schema validation</li>
<li><a href="https://www.postgresql.org/docs/current/datatype.html">PostgreSQL Data Types</a> for storage decisions</li>
</ul>
<h3>2. Scrapers are never done</h3>
<p>I thought: build scraper, run scraper, done. Reality: websites change constantly.</p>
<p>A site redesigns, your scraper breaks. A site adds anti bot measures, your scraper breaks. A site changes their data format, your scraper breaks.</p>
<p>I learned to treat scraper maintenance as ongoing work, not a one time setup. I built monitoring with <a href="https://sentry.io/">Sentry</a> so I know within hours when something breaks.</p>
<pre><code>Scraper Health Dashboard:
┌────────────────┬────────┬──────────┐
│ Source         │ Status │ Last Run │
├────────────────┼────────┼──────────┤
│ AutoTrader UK  │ ✓      │ 2h ago   │
│ CarGurus       │ ✓      │ 3h ago   │
│ AutoData PH    │ ⚠      │ 1d ago   │ ← needs attention
│ CarQuery API   │ ✓      │ 6h ago   │
└────────────────┴────────┴──────────┘
</code></pre>
<h3>3. PostgreSQL full text search is underrated</h3>
<p>I almost added <a href="https://www.elastic.co/">Elasticsearch</a> because that's what "real" search uses. Then I tried PostgreSQL's built in full text search with <a href="https://www.postgresql.org/docs/current/pgtrgm.html">trigram indexes</a>.</p>
<p>It handled 49,000+ records beautifully. The realization: sometimes the boring choice is the right choice. Not everything needs a specialized tool.</p>
<pre><code>-- PostgreSQL trigram search that replaced Elasticsearch
CREATE INDEX idx_cars_search ON cars
USING gin (name gin_trgm_ops, brand gin_trgm_ops);

-- Fast fuzzy search
SELECT * FROM cars
WHERE name % 'camery'  -- finds "Camry" despite typo
ORDER BY similarity(name, 'camery') DESC;
</code></pre>
<p>Resources:</p>
<ul>
<li><a href="https://www.postgresql.org/docs/current/textsearch.html">PostgreSQL Full Text Search</a></li>
<li><a href="https://supabase.com/docs/guides/database/full-text-search">Supabase Full Text Search Guide</a></li>
</ul>
<h3>4. Multi market complexity compounds</h3>
<p>A "base model" in one market might have features that are "premium" elsewhere. The same car might have different names in different regions. Prices in different currencies need conversion but also contextual understanding.</p>
<p>Is $30,000 expensive for this car? Depends on the market. This complexity kept revealing itself in layers.</p>
<h2>The Bigger Realization</h2>
<p>Building Vehiq taught me that aggregation products live and die by data quality. I could have built the world's best UI, but if users find one wrong spec, they lose trust in everything.</p>
<p>The unsexy work of validation, cleaning, and monitoring is what makes the product valuable. Features are easy. Trustworthy data is hard.</p>
<h2>What I'd Do Differently</h2>
<p>Build an admin dashboard from day one. I managed data through scripts and direct database queries for months. A proper admin interface for reviewing flagged data, fixing issues, and monitoring scraper health would have saved hours of terminal work every week.</p>
<h2>References</h2>
<ul>
<li><a href="https://nextjs.org/docs/app/building-your-application/data-fetching/incremental-static-regeneration">Next.js ISR Documentation</a></li>
<li><a href="https://supabase.com/docs">Supabase Documentation</a></li>
<li><a href="https://www.postgresql.org/docs/current/pgtrgm.html">PostgreSQL Trigram Extension</a></li>
<li><a href="https://zod.dev/">Zod Schema Validation</a></li>
<li><a href="https://docs.sentry.io/">Sentry Error Monitoring</a></li>
</ul>
<h2>Links</h2>
<ul>
<li><strong>Live Site:</strong> <a href="https://vehiq.tech">vehiq.tech</a></li>
</ul>


Projects.

Vehiq: Smart Car Comparison Platform