Skip to content

Case study

The second dealership, and what I reused rather than rebuilt

Building the same shape of product twice is the cheapest education available. The second one tells you which of your decisions were real and which were habits you had not noticed.

Role
Designer and developer
Period
2024
Stack
Remix, Node.js, PostgreSQL

The situation

A second dealership, same market, superficially the same problem. Public inventory, real search traffic, an owner who needed to run it alone.

The obvious move was to copy the first build and change the branding. I did not, and the reasoning is the more useful part of this story.

Two clients is not a product

The temptation with a second similar project is to generalise: extract the shared parts, make the differences configurable, and now you have a platform.

That is usually the wrong call at two, for a reason that only becomes obvious at three. With two examples you cannot tell which differences are meaningful and which are accidental. Generalising produces configuration options that exist because one client once wanted something, and a codebase serving a hypothetical third customer who may not arrive.

The cost is real and permanent. Every subsequent change is now made in an abstraction that has to keep two clients working, so nothing can be done simply again.

Two clients is a coincidence. Three is a pattern. I copied the thinking, not the code.

What actually transferred

The patterns, which is where the value was:

Every listing gets a real URL serving real HTML with the price and specification in the markup, because being found is the entire purpose.

Updating stock takes under two minutes on a phone, or the site goes stale and stops earning.

The listing page matters more than the browsing interface, because most arrivals come from a search for one specific thing.

The sitemap regenerates when stock changes rather than on a schedule somebody has to remember.

None of that is code. It is judgement, and judgement is the part that actually compounds between projects.

What differed, and why it mattered

The second client sold a different mix, with far fewer, more expensive vehicles. That sounds like a detail and it changed the design.

With a small inventory, filtering is pointless. Everything fits on one screen. What matters instead is depth per vehicle: more photographs, more history, more specification, because a buyer at that price point reads everything before making contact.

Had I copied the first build I would have shipped a filtering interface over eleven cars, which would have looked professional and been faintly ridiculous.

What I got wrong

I underestimated how much of the first build was tuned to the first client’s volume. I started by porting the listing grid, then spent a day undoing density decisions that made sense for a hundred vehicles and looked sparse and strange with eleven.

Starting from the content rather than from the previous solution would have been faster. That is a lesson I have to relearn periodically: the previous solution is a reference for the problem, not a starting point for the design.

Where it landed

A site the owner runs alone, listings that rank for the specific vehicles they carry, and a codebase that stayed simple because it was never asked to serve two masters.

If a third dealership arrives, then I would extract the shared parts, and I would be extracting from three real examples rather than guessing from two.

Questions people actually ask

Why not turn the first build into a reusable product?
Because two clients is not a product, it is a coincidence. Generalising from two examples produces configuration nobody needs and a codebase serving a hypothetical third customer who may never arrive.
What actually transferred between the two?
The patterns and the judgement, not the code. The shape of the listing page, the two minute rule for updates, the server rendering decision. Almost none of the components moved across unchanged.

Published May 2026, updated July 2026.

Hiring someone to own work like this?

I am open to senior backend and full stack roles, remote and permanent.

Get in touch / Read the CV