ILikeBigJeeps: a Wrangler-only platform built to be found
My own product: a platform for Wrangler owners built around structured rig data, so a stranger searching for a specific build lands on a page that is genuinely the best answer to their question.
The problem
Wrangler owners are one of the most passionate communities on the road. They wave at strangers, leave rubber ducks on each other's dashboards, and name their vehicles. They had nowhere to put any of it.
- Facebook groups. Forty thousand members, a dozen admins, and a post about a lift kit buried under three arguments and a marketplace scam.
- Instagram. Your rig photo shown to a fraction of your own followers, sandwiched between a supplement ad and somebody's engagement announcement.
- Forums. Genuinely great information, last redesigned when the TJ was current.
- And the good answers are unsearchable. The best build photos live inside apps that show nothing to Google, so the one question everybody asks has no findable answer.
The information exists and the community exists. The home does not. And the question a Wrangler owner actually has is dead simple: what does a 2021 Rubicon look like with a 2.5-inch lift on 35s in Sarge Green? Nobody had a good answer to that, Google included.
What I built
The first instinct with any community platform is to widen the door: add Broncos, add trucks, add off-road enthusiasts generally. I went the other way and locked the taxonomy to Wranglers, CJ through JT, and stopped there.
That is the decision the whole product rests on. A general off-road platform competes with Instagram and loses. A platform where every page is a Wrangler build becomes the best resource on earth for one specific question, and that specificity is what search engines reward and what members actually want. Narrow is not small. Narrow is findable.
- Structured rig profiles. Year, model, trim, doors, color, lift, tires, and the mod list that will never be finished. Every rig gets its own page, its own URL, and its own gallery, and emits `Vehicle` structured data with lift height and tire size as real properties.
- A chronological feed, and Explore. You see what the people you follow posted, in the order they posted it. Explore is the workhorse: filter every build on the platform by model and spec. This is the "what would mine look like" machine.
- Collections and moderation from day one. Saving, following, notifications, reporting, and content moderation are part of the data model rather than an admin panel added after the first incident.
Everything expensive or slow runs as a background job rather than blocking a request: image processing, OG image generation, email, notifications, and cleanup of orphaned uploads.
Two pillars from the original plan, the Wrangler Depot marketplace and club portals, are deliberately held back until after launch. Both are described at the end of this write-up.
| Where builds live today | ILikeBigJeeps | |
|---|---|---|
| Finding a build like yours | Buried in a 40,000-member group | Filterable by model and spec |
| Your rig's home | A post that scrolls away | A permanent page with its own URL |
| Who sees it | A fraction of your followers, chosen by algorithm | Chronological, plus pages a stranger can find in search |
| Search visibility | Effectively invisible to Google | Server-rendered with Vehicle structured data |
| Tracking | Ad tech and behavioural profiling | None |
The outcome
Fifteen weeks from first commit to a launch-ready build, developed in phases so there was working software to look at throughout rather than a reveal at the end. Launching August 2026.
The growth channel is built into the product rather than bolted on afterwards. Every public page is server-rendered, and the app emits a dozen distinct structured-data types across rig profiles, user profiles, and Explore pages. Sitemaps are generated dynamically and split by content type rather than flattened into one file, so a rig gallery and an Explore page can be crawled and refreshed on their own cadences.
Cost behaviour was designed in at the same time. Images are processed once into three WebP variants and served from zero-egress object storage, search runs on PostgreSQL rather than a separate search service, and the schema is indexed for the queries the app actually makes. The platform is built to stay affordable at 500 users and at 50,000, because deferring the infrastructure bill is how good products die.
Built with
Narrow on purpose
The taxonomy decision looks like a marketing choice and is actually an architecture one. Locking the data model to Wranglers, CJ through JT, means every rig on the platform shares a structure: generation, model, trim, door count, lift height, tire size, color. Once that structure exists, several features fall out of it almost for free.
Explore becomes a filter over real fields rather than a text search over captions. Rig profile
pages become genuinely useful search landing pages, because a page of builds matching an exact
spec is the best available answer to a question people already type into Google. And the
Vehicle structured data those pages emit carries lift height and tire size as machine-readable
properties rather than prose a crawler has to guess at.
A wider platform gets none of those, because you cannot build a filter over a field that does not exist for most of your content.
Search visibility as the acquisition channel
Search here is not a checklist item added before launch, it is the growth model, so it was designed into the rendering strategy from the start.
Every public page is server-rendered. Rig profiles emit Vehicle, clubs emit Organization
and Event, user profiles emit Person, and supporting types like QuantitativeValue and
PropertyValue carry the spec details that make a build page specific rather than generic.
Twelve distinct types across the app.
Sitemaps are generated dynamically and split by content type, five of them: rigs, clubs, explore pages, users, and the root. Splitting matters more than it sounds. A rig gallery changes on a completely different cadence from a club’s event calendar, and separate sitemaps let each be crawled and revalidated on its own terms instead of being flattened into one file that is always slightly out of date.
The parts that were genuinely hard
Images at volume. A photo-first platform lives or dies on its image pipeline. Every upload is resized into three variants at 400, 800, and 1600 pixels, converted to WebP at quality 80, and never enlarged beyond its source. That work happens in a queued background job, so the upload request returns as soon as the original is stored rather than blocking on processing. Storage sits on zero-egress object storage, because an image-heavy social platform on standard object storage is a bill that grows faster than the user base does.
Everything slow moved off the request path. Image processing, OG image generation, transactional email, notifications, and cleanup of orphaned uploads all run as queued jobs. Each retries on its own and scales independently. The alternative is a web request that occasionally takes ninety seconds and a user who assumes the site is broken.
Trust tooling shipped with the features, not after. Reporting and content moderation exist as first-class parts of the data model rather than an admin panel bolted on following the first incident. In a community product, moderation is not a feature request, it is a requirement, and retrofitting it is considerably more expensive than building it in.
Held back until after launch
Two of the four original pillars are deliberately not in the launch build. Both are real plans rather than vague intentions, and both are better served by waiting.
Wrangler Depot, a marketplace for buying and selling Wranglers and Wrangler parts, is the clearest beneficiary of going second. Its whole advantage over a general classifieds site is fitment: because every rig is already structured by generation, model, trim, and door count, a parts listing can declare exactly what it bolts onto instead of “fits most Jeeps” and hope. That advantage depends on the vehicle taxonomy being populated with real builds, which is exactly what launch produces. Shipping the marketplace first would mean launching a fitment filter with nothing to filter.
Club portals are the other. The plan is public landing pages, event calendars with RSVPs, member directories, announcements, and meeting notes, with the public side open so prospective members can find a club and the rest behind its own door. The piece I am most interested in is meeting notes: volunteer-run clubs lose their own history constantly because minutes depend on whoever remembered to take them, so a club uploads a recording, Whisper transcribes it, and Claude turns the transcript into structured notes on the meeting record. That is AI doing something the members genuinely will not do themselves, which is the only kind worth building. Clubs need members before any of it matters, so it follows launch rather than leading it.
Holding both back is the same discipline as the taxonomy decision, applied to time instead of scope. Three pillars shipped properly beats five pillars half-finished, and a launch is the worst possible moment to be maintaining all of them at once.
Questions this raises
Why limit the platform to Wranglers instead of all off-road vehicles?
Because a general off-road platform competes with Instagram and loses, while a platform where every page is a Wrangler build becomes the definitive answer to one specific question. When someone lands on a page of builds matching their exact model, trim, lift, and tire size, they do not need to be sold on signing up. The niche is not a limitation here, it is the acquisition strategy.
How does a structured data model change what the product can do?
Once every rig shares a structure of generation, model, trim, doors, lift, and tires, several features fall out of it almost for free. Explore becomes a filter over real fields rather than a text search over captions, and rig pages become genuinely useful search landing pages because a page of builds matching an exact spec is the best available answer to a question people already ask. A wider platform gets none of that, because you cannot filter on a field most of your content does not have.
What does it take to make a photo-heavy platform affordable?
Processing every upload once rather than serving originals: three resized variants at 400, 800, and 1600 pixels, converted to WebP, generated in a background job so the upload request returns immediately. Storage sits on zero-egress object storage specifically because an image-heavy social platform on standard object storage produces a bill that grows faster than the user base.
Why run so much work in background jobs?
Because transcription, image processing, and email are slow, failure-prone, and nobody should wait on them. Running them as queued functions means a request returns immediately, a failure retries on its own rather than surfacing as a broken page, and each job scales independently of the web app.
Why hold back the marketplace and club portals until after launch?
Because a launch is the worst possible time to be maintaining four pillars at once. Rig profiles and Explore are what make the platform worth visiting on day one, and they are what the search strategy depends on. The Depot and club portals both get materially easier once real rigs and real usage exist, since the Depot needs the vehicle taxonomy populated to make fitment filtering useful, and clubs need members to organise. Shipping three pillars properly beats shipping five half-finished.
This is your own product. What does that show a prospective client?
That the planning, the architecture, and the scope discipline are the same whether or not somebody is paying for them. It started as a paragraph-long idea and became a full product requirements document, data model, design system, and phased roadmap before a line of code was written, which is the same translation step any client project needs and the part that prevents expensive surprises in month three.
Have something like this to build?
Tell me what you're working with and where it's stuck. If it's a fit, we'll book a scoping call - no obligation, and I respond personally.
Let's Talk →