Industries

Choose custom only when the template blocks the job

A different-looking homepage does not settle the custom-versus-template question. The useful question is whether the available website controls can support the way your dealership needs to present vehicles, answer buying questions, and manage content. Before commissioning a custom DealerCenter website, identify the specific behavior the stock option cannot deliver through its supported settings. That makes the decision a practical comparison of requirements, constraints, and ongoing responsibility.

If search work is part of the scope, our website rule applies. We only do SEO on a site we built.

Find the constraint before choosing the build

Start with a task rather than a design preference. Perhaps your dealership needs different information for retail buyers and commercial buyers. Perhaps a vehicle detail page needs a clearly organized explanation of equipment, condition, and purchase steps. Write down what a visitor should see and do. Then ask whoever controls the proposed template to demonstrate that exact journey, including the mobile version and the editing process behind it.

The distinction matters because an unattractive implementation is not necessarily a template limitation. Typography, image selection, content hierarchy, and page settings might address the issue within the existing system. A structural restriction is different: the supported controls cannot produce the required arrangement or behavior. The available project record does not establish DealerCenter's current template capabilities, so each alleged restriction needs a demonstration rather than an assumption.

Separate three kinds of change

• Configuration changes use controls already available to the website administrator, such as an editable field or an exposed layout option. Confirm the actual controls rather than relying on a feature label.
• Content changes improve what the page says and how information is organized within its existing structure. These can solve unclear messaging without changing the underlying website architecture.
• Structural changes require access beyond those controls. Examples to test include changing the order of inventory information, introducing a new page relationship, or connecting an unsupported external service.

What a stock template cannot be made to do

A template cannot reliably support a requirement through configuration when that requirement sits outside its exposed controls and supported extension points. That is the mechanical boundary to investigate. It is not evidence that a particular DealerCenter template lacks a particular feature. Ask for a working example, identify which controls produce it, and establish whether the change remains supported when the underlying website receives updates.

Consider a proposed vehicle page with a buyer-specific equipment summary above the inquiry form. The requirement contains several questions: where does that summary originate, can the page place it in that position, and can staff maintain it without editing code? If the design depends on a field the source never provides, changing the template alone will not solve the problem. The constraint may belong to the data rather than the presentation.

Similarly, a visual workaround is not the same as supported control. Hiding a required element with styling might leave inaccessible content, confusing page order, or maintenance problems. Before accepting a workaround, inspect its effect on keyboard navigation, small screens, form behavior, and future edits. A custom implementation should address a defined limitation directly, with a maintenance plan that the dealership can understand.

Compare the pages buyers actually use

Inventory lists and vehicle detail pages

Use representative inventory to evaluate both approaches. Include a vehicle with sparse information, one with extensive equipment details, and one with many photos. Check whether headings, specifications, and inquiry options remain understandable across those conditions. Test what happens when a photo is unavailable or a description is unusually long. These examples expose whether the proposed structure handles ordinary variation or only looks convincing with carefully prepared demonstration content.

Supporting pages and purchase questions

Inventory is only part of the decision. Map the pages that explain your dealership's process, location, trade-in questions, and contact options. Determine whether staff can create and update those pages with an appropriate structure. If several subjects must be squeezed into one generic content area, assess the actual effect on clarity before deciding that a separate design system is necessary.

Custom presentation creates responsibilities

Custom should describe the scope of control, not imply that every part of the system becomes editable. A separately built frontend may still depend on an inventory source, a form provider, or a hosted service with its own restrictions. Document those dependencies. The dealership should know which parts an agency can change directly, which require another provider, and which cannot be changed under the proposed arrangement.

Ownership also needs a concrete definition. Ask who controls the domain, source files, hosting account, content, and connected services. Establish how another developer could maintain the site and what materials would be supplied at handover. These are contract and implementation questions to resolve for the proposed engagement; a polished design does not answer them.

Build a decision record before approving design

Create a short requirement register with one entry per meaningful constraint. Each entry should include the buyer task, the current obstacle, the template demonstration, the proposed alternative, and the person responsible for maintaining it. Record unresolved questions explicitly. This prevents an attractive mockup from becoming a substitute for evidence that the eventual website can function as intended.

The decision can then be proportionate. Keep the stock approach when supported settings and better content meet the requirements. Consider custom work when an important requirement remains blocked and the proposed build demonstrates a maintainable solution. If the blocker comes from inventory access or a third-party service, resolve that dependency before treating design freedom as the answer. Ninetyfifth Marketing's evaluation framework starts with that distinction.