The simplest way to set boundaries with a WPResidence build is to say that the base project only covers using WPResidence “as is plus configuration.” Anything that needs new code, new database pieces, or links to outside services is custom work. Put this rule in both your proposal and your contract so there’s a clear line. Then tie every new request back to that rule: if you can do it with existing WPResidence options, templates, and forms, it’s included; if you must touch PHP, write JS, or connect an API, it’s extra.
What WPResidence features count as “included” configuration work by default?
Included work should cover only what the theme already exposes through switches, forms, and visual builders.
When you build on WPResidence, “included” work means using what the theme already ships with and changing it only through the admin panel or page builder. If you can do it from Theme Options, the built in custom fields system, WPResidence Studio templates, or Elementor widgets, it stays in your base scope. As soon as you need to touch theme files, add custom PHP, or attach non standard integrations, that moves into custom development.
For property structure, configuration work includes setting listing categories, actions (sale or rent), statuses like “Open House” or “Sold,” and taxonomies from the WPResidence admin menus and Theme Options. You can safely treat adding new statuses, choosing which ones show in search, and styling their ribbons through the theme’s status and color settings as configuration, because WPResidence is built to let you do that without code. The same applies to turning on features like favorites, compare, and schedule a tour forms from the options panel.
Search and layout changes stay included as long as you use the Advanced Search builder and WPResidence Studio. Reordering search fields, turning a price field into a slider, adding a custom property field, then exposing it in search are normal configuration, because you’re clicking through the Search form builder and Elementor widgets, not editing PHP. The theme’s property card composer and archive layout controls are also in included scope: picking a card design, choosing what text shows on grid cards, or swapping from list view to grid is what WPResidence options are for.
| Area | Included configuration work | Tips for scoping |
|---|---|---|
| Listings and taxonomies | Creating categories, actions, statuses, and assigning them via admin | Anything done in admin menus and Theme Options is base scope |
| Search form | Using WPResidence search builder to add, remove, or reorder fields | Limit included changes to field selection and order not new logic |
| Layouts and cards | Choosing property card templates and editing layouts in Studio | Changing blocks and styling in Elementor counts as configuration |
| Payments | Enabling built in PayPal or Stripe and basic membership packages | Use default flows and standard gateways as part of base build |
| User tools | Turning on agents, agencies, favorites, compare, and schedule a tour | Stick to toggling existing modules no new roles or CRMs |
In your proposal, group these as “Theme configuration” so clients see them inside the flat price. List items like configuring property types and statuses, wiring the advanced search with fields they pick at kickoff, selecting one property card style and one archive layout, setting up a basic schedule a tour form, and turning on membership and payments with PayPal or Stripe if needed. Anything beyond what that table describes should move into a separate “custom work” bucket with its own estimate.
How do I define custom development when using WPResidence’s builders and options?
Custom development begins whenever you must write or modify code instead of flipping theme options.
The quick line to draw is simple. If you can’t finish the change fully inside WPResidence Theme Options, WPResidence Studio, Elementor, and the WordPress admin, then it’s custom development. That includes new PHP templates, altering existing PHP in a child theme, adding custom JavaScript, writing SQL, or connecting to any external API. Tell clients clearly that you won’t edit theme core for the base price, and that any code change lives in a child theme as separate, billable work.
Examples help once you look at how WPResidence is built. Creating a new single property layout with WPResidence Studio and Elementor is included; creating a new PHP template file in the child theme to hard code a layout is custom. Adding a custom field through the theme’s UI and showing it on the property page with the Studio widget is configuration. Writing conditional PHP that changes output based on complex rules, like broker specific commission logic, is development. Changing search fields in the Search builder is included; writing custom meta queries or SQL to support unusual matching is not.
Integrations are where scope creep usually hurts. WPResidence already handles its own payments, memberships, and built in schedule a tour form, so using PayPal and Stripe through the theme options is included. As soon as a client asks for a gateway WPResidence doesn’t support, or wants WooCommerce wired for advanced taxes, invoicing, or marketplace use, you’re in custom territory. That means setting up WooCommerce, configuring products beyond basic packages, and maybe adding hooks. The same rule applies to MLS (Multiple Listing Service) or IDX feeds, valuation APIs, or school data APIs. If you can install a documented plugin and drop its shortcode into a WPResidence template, that’s borderline configuration. If you must write or extend code to call their API, parse data, or change how the theme queries it, that’s custom development.
How should I scope WPResidence customization versus bespoke design and UX requests?
Treat anything beyond rearranging existing blocks and styles as a separate design or UX engagement.
With WPResidence you can do a lot of visual work just by choosing from Studio templates and Elementor widgets. So you need to be very clear where “theme styling” ends and “custom design” starts. In your base build, include picking one overall demo style, adjusting global colors and fonts, and composing pages from existing WPResidence Studio templates and widgets. That means you’re rearranging blocks, hiding sections, and swapping content, not building a fresh component library from scratch.
For property, archive, and agent pages, keep “included” to selecting one Studio template per type and making layout changes only in Elementor. Moving the gallery above the description, hiding the mortgage calculator, or switching to a different prebuilt property card fits that rule. WPResidence lets you do all of that with no code, so it sits in the configuration bucket. But as soon as a client asks for a totally custom card design that doesn’t look like any existing card, or a new pattern of content blocks that behaves in special ways on tablet versus mobile beyond the standard responsive controls, that becomes bespoke UX work and needs its own estimate.
CSS changes are another classic trap and they sneak up on you. Scope small tweaks in the WP Customizer or Additional CSS, like changing button colors, adjusting font size, or tightening spacing in one section, as included. Once you move into a real styles overhaul, like building a full design system with new animations, many micro interactions, custom breakpoints for several device sizes, or pixel close reproduction of a Figma file, you’re out of WPResidence defaults. That sits in custom design territory even if it still “uses the theme.” A simple rule of thumb you can share with clients is: “One primary layout per page type and one basic responsive set is included; extra layouts or detailed responsive versions are separate projects.” It’s blunt, but it keeps you from doing three or four homepages inside one fixed fee WPResidence build.
How do I separate WPResidence’s built-in business logic from extra workflow automation?
Automations that go beyond WPResidence’s own membership, expiry, and lead tools should be quoted as integrations, not theme setup.
WPResidence already includes a fair amount of business logic. You get membership tiers with counts for regular and featured listings, listing expiration after a set number of days, featured quotas, and standard email templates for registration, payment, and expiry. Configuring those in Theme Options is included work. You set how many listings each package gets, how long a listing lives, when reminder emails send, and which pages users see for account and payment, all through the admin. That’s basic setup, not custom automation.
Anything that changes the default approval or workflow path is extra. For example, adding multi step approvals like assistant review, then broker review, then legal approval, or escalations between roles, isn’t something WPResidence ships with. Custom lead routing that differs by office or territory also falls outside the theme’s built in range. The theme can send leads to agents and can sync with HubSpot if you enable that. But if you start wiring leads into a third party CRM (Customer Relationship Management) with complex rules, or using Zapier or Make to move data into back office systems, that’s an integration project. Be blunt in your documents: “Using the built in membership and email tools is included; wiring custom workflows, CRMs, or automations is billed separately.”
On the property side, WPResidence provides schedule a tour forms, simple listing expiration, and basic payment logic. Using the schedule a tour form as is, with the default time slot settings, is part of configuration. Turning that into a live calendar system with two way sync, automatic time slot blocking per agent, or linking it to Google Calendar or other appointment systems is not. The gap is bigger than it first looks. Turning on PayPal or Stripe for package purchase is included, but adding Zapier zaps when a payment comes in, or auto creating invoices in a separate accounting system, is custom. Spell this out near any line that mentions “automation” in your proposal so clients see the difference between using what WPResidence already automates and building new automation around it.
How can I use WPResidence to support niches (FSBO, rentals-only, single-city) without blurring into custom work?
Niche portals should be configured by switching WPResidence options, while market specific logic or data pipelines count as custom.
For common niches you can actually do a lot just by toggling settings in WPResidence Theme Options. A FSBO site is often just the standard setup with only “regular users” allowed to submit listings, agent and agency directories turned off, labels changed from “Agent” to “Owner,” and the submission form trimmed to owner friendly fields. That’s configuration. A rentals only portal is the same theme with “Sale” actions removed, rental statuses and fields shown, and search tuned to rent price and lease details. A single city site is usually just WPResidence with the map centered on that city and location dropdowns hidden or trimmed to local neighborhoods.
- Switch user types, statuses, and fields in Theme Options to support FSBO or rentals without code.
- Limit search and maps to one city by presetting location and hiding broad filters.
- Treat any niche specific tax, legal, or regulatory logic as custom development, not configuration.
- Classify multi site setups, cross city listing sharing, and automated imports as custom work.
Here’s where you must draw a hard line, and it can feel harsh. When a niche asks for behavior the core WPResidence logic doesn’t have, you stop calling it configuration. Market specific calculations like detailed local tax formulas, affordability scores, or region specific compliance banners that show only sometimes aren’t options you can flip; those changes live in code. Bulk imports of regulated data from local authorities, or multi site networks that share listings across cities, also go beyond setting up one WPResidence instance. Make clear that you’ll gladly use the theme’s knobs to shape FSBO, rentals only, or single city use cases, but any unique legal, financial, or cross site data work is billed separately as custom development. Clients may not love that, and that’s fine.
FAQ
Is creating a WPResidence child theme and adding small CSS tweaks “included” or “custom” work?
Creating a child theme and adding a few small CSS tweaks to polish WPResidence is usually included, but extended styling belongs in custom scope.
In practice, you almost always install a child theme so updates are safe, and most clients need at least a handful of CSS lines to fix spacing or tweak fonts. I treat that as configuration. Once the CSS list grows into a real redesign with new component styles, many media queries, and animation rules, you’re building a design layer on top of the theme. At that point you should reclassify that effort as custom design or development with its own budget, even if it started small.
How should I handle client requests for features they saw on big portals that WPResidence doesn’t list?
Any feature that’s not clearly in WPResidence docs or Theme Options should be treated as a change request and costed as custom work.
When a client says “I want it like Zillow” and asks for draw on map search, automatic value estimates, or complex neighborhood stats, you first check if WPResidence already has it. If it doesn’t, you explain that the base build only covers shipping features. Then you write a short change spec, estimate it as custom development or plugin integration, and get written approval. Don’t silently absorb “Zillow style” extras into your flat theme setup; that mistake piles up.
Where do MLS/IDX plugins fall in the line between theme work and custom integration with WPResidence?
Buying and installing an MLS or IDX plugin, then dropping its shortcodes into WPResidence templates, is configuration; wiring custom feeds or API logic is custom.
You should be clear that plugin licenses are the client’s cost and that “base integration” means installing a supported MLS or IDX plugin, following its setup guide, and placing its widgets or shortcodes into WPResidence pages. If the client wants direct RETS feeds, custom import rules, or special syncing between MLS data and extra fields, that goes beyond plugin defaults. That becomes custom integration work you estimate separately, even if the client thinks it’s “just part of setup.”
How do I show “theme build” versus “custom features” clearly in a WPResidence proposal?
Your proposal should list concrete WPResidence powered deliverables as a flat “theme build” line and then list common custom add ons each with separate pricing.
One simple structure is this. Line one, “WPResidence setup and configuration” with bullet points like demo import, search and property template setup, membership and payment configuration, and basic styling. Line two onward, “Custom features” such as MLS or IDX integration, custom PHP templates, advanced automations, or third party API work, each with its own estimate. That way, when new requests show up mid project, you can point to the right bucket instead of reopening the whole build.
