How to Build a Car Dealership Website Without Code
A car dealership website without code starts with two descriptions: the dealership, and the shape of a vehicle listing. Zugo turns that into a working site, boots it in a sandbox before handing it over, and publishes it to a live address. A simple site is a single build; a stock listing platform needs a database behind it.
The listing is the product. Everything else on a dealership site is scaffolding around the moment a buyer compares two cars, and a listing that is missing mileage or service history loses to the one that is not.
What does a car dealership website actually need?
Four blocks carry most independent dealers. A stock list that can be filtered. A detail page per vehicle with photographs and full specifications. An enquiry route, which is usually a test-drive request rather than a purchase. A page about the dealership itself: location, opening hours, warranty terms, and who you are.
The filter matters more than the design. A buyer arrives knowing roughly what they want, and the useful filters are price, mileage, fuel type, transmission, and year. Anything beyond those five is decoration for most independent forecourts.
The detail page is where trust is won or lost. Twelve honest photographs including the wear, a full specification, mileage, previous owners, service history, and any advisory from the last inspection. A listing that shows the scuff on the bumper sells faster than one that hides it, because the buyer who drives forty miles and finds it anyway does not buy.
What should the prompt say?
Describe the vehicle record before you describe any screen. That order is what separates a working stock site from a pretty page you rebuild in a week.
A website for an independent used car dealership in [city]. Each vehicle has: make, model, variant, year, mileage, price, fuel type, transmission, body style, colour, number of previous owners, MOT or inspection expiry, a description, and up to 15 photos. The main page is a filterable list of vehicles in stock, sorted by newest listing, showing photo, title, year, mileage, and price. Each vehicle has a detail page with the full specification, the photo gallery, and a "Book a test drive" form asking for name, phone, email, and preferred day. Sold vehicles move to an archive rather than disappearing. Plus pages for finance, part exchange, warranty, and contact with a map.
Every field named there is a guess removed. The general principles of prompting a builder are in how to build an app with AI; the dealership-specific part is naming the whole vehicle record up front, because adding a field to fifty existing listings later is real work.
Where does the stock list actually live?
By default a generated site can hold data in the browser, which is fine for a demo and useless for a forecourt. Your sales team cannot update it from the office, and clearing the browser clears your stock.
Connect Supabase and the site gets a real Postgres database, accounts for whoever manages listings, and file storage for the photographs. That last part is not a detail: a dealership site is fifteen images per vehicle, and images need somewhere to live.
| Requirement | Browser-only build | With a database connector |
|---|---|---|
| Two staff updating stock | Not possible | Both work from the same list |
| Listings survive a cleared cache | No | Yes |
| Photo galleries per vehicle | Awkward at best | File storage included |
| Marking a car as sold | Manual and error-prone | One field, reflected everywhere |
| An enquiry attached to a vehicle | Lost with the session | Stored against the listing |
Test the connection the honest way: add a vehicle, close the browser entirely, open the site on a different device, and confirm the listing is there with its photographs.
How do you keep the stock list honest?
Two rules do most of the work, and both are worth stating in the prompt.
Sold means sold, visibly. Ask for sold vehicles to move to an archive with a clear label rather than vanishing. A buyer who bookmarked a car deserves an answer, and an archive of sold stock is also quiet proof that cars move off your forecourt.
Every listing carries a last-updated date. Stale prices are the fastest way to lose a phone call, and a visible date makes staleness obvious to you before it is obvious to a customer.
Edits are the cheapest action in Zugo at 3 credits, so keeping the list current is a habit rather than a project: "mark the 2019 Golf as sold and move it to the archive", "reduce the Fiesta to $8,450 and add a note that the price is negotiable."
The third rule is about photographs rather than data. Use the same set of angles on every car, in the same order, so the list looks like one forecourt rather than a collection of private adverts. Consistency here reads as professionalism at a glance, before anyone has read a single specification.
Should the site take payment, or generate enquiries?
For nearly every dealership, the answer is enquiries. Cars are not bought in a checkout, they are bought after a test drive, a part-exchange valuation, and a finance conversation.
Where payment genuinely fits is deposits. A refundable holding deposit taken through Stripe turns a serious buyer into a committed one and costs you nothing to add. Say the refund policy on the page in the same words you would say it in person.
The other half is what happens after an enquiry. Resend delivers the confirmation to the customer and the alert to your sales desk. A test-drive form with nothing behind it is the most common broken thing on dealership sites, and it is invisible until you test it yourself.
A finance calculator is worth adding for a different reason: it answers the monthly-payment question before someone has to ask it. The mechanics of building one, including how to state the formula so the numbers are right, are covered in the calculator app guide. State your assumptions on the page, because a monthly figure without the term, deposit, and rate beside it is misleading rather than helpful.
What does it cost to build?
Zugo bills in credits per action. A quick build is 6 credits. An edit is 3. A multi-page platform is 12 credits plus 3 for each page past the first three, which is the bracket a dealership site sits in once it has a stock list, a vehicle detail page, finance, part exchange, and contact.
The Free plan gives 5 credits to look around. Pro is $25 per month with 200 credits, and Business is $99 per month. Because edits are the cheapest action on the meter, the efficient pattern is one carefully described build followed by many small changes, which also happens to be the natural rhythm of a forecourt where stock turns over weekly.
Hosting for the published site is included, so there is no separate server bill. Hi-Fi mode, which spends more effort on the visual pass, doubles both prices. Set against what a single extra sale is worth on a used car, the monthly figure is not the number that decides this; whether the stock list stays current is.
How do you know the build actually works?
Zugo boots every build in a sandbox before showing it to you, and a build that failed to load is reported as a failure rather than handed over as a blank screen. That lowers the risk of losing a day to a broken page, and it does not replace your own testing, because "the listing page rendered" and "the enquiry reached the sales desk" are different claims.
Four checks before you advertise the address. Submit a test-drive request with your own details and confirm both emails arrive. Add a vehicle with fifteen photographs and open it on a phone on mobile data, since that is how most buyers will see it. Mark a car sold and confirm it leaves the main list. Use every filter and check the results are actually filtered rather than merely re-sorted.
The filter check is the one people skip and the one that fails most often. Set a maximum price, then look at the last row of results and confirm it really is under that figure. A filter that quietly ignores a field looks completely normal until a buyer drives over for a car that costs three thousand more than they budgeted.
Where does an AI builder stop for a dealership?
Four honest limits, worth knowing before you commit.
Stock feed integration is a developer's job. Importing from a dealer management system, or pushing your stock out to the big classified portals, means their formats and their authentication. There is no connector for that, and for most independents the manual entry is faster than the setup would be.
Vehicle history and valuation lookups are paid data services. A registration lookup that fills in the specification, or a live trade valuation, comes from a provider with a contract and an API key. That is an integration project.
Regulated finance is not a website feature. If you broker credit, the disclosures, permissions, and representative examples are legal obligations. A calculator can illustrate; it cannot make an offer compliant.
Photography is still yours. The builder writes layout and structure. A used car sells on its images, and no generator supplies fifteen honest shots of the actual vehicle.
Everything below that line fits comfortably: a fast, filterable, honest stock site with working enquiry routes and a finance illustration, built in a day and kept current in plain text. If tracking what is on the forecourt matters as much as displaying it, the inventory app guide covers the stock-record side of the same problem. Describe the vehicle record first, connect the database, then start at zugo.dev.