The “Pennies on the Dollar” Concept for Custom Work
Hey everyone, today I wanted to talk about the “pennies on the dollar” concept that I often refer to when talking to clients about custom work.
Let me explain how it works — and then I’ll give you an example that just came up today.
Custom Work: So Powerful (But Also Expensive)
When you’re doing custom work, a lot goes into it.
First, you have to speak to an Account Manager (AM) to formulate your idea in enough detail to get an estimate (that part costs nothing).
Once you’ve got a rough idea and you’re ready to start coding, you head over to a retainer team, which typically consists of:
- Project Manager (PM): Tracks everything, manages communications, and keeps you on schedule. (The time saved and quality control from having a PM usually justify their cost.)
- Programmer: Handles the coding portion.
- Designer / Front-End Developer: Ensures it looks great and is mobile responsive.
- QA (Quality Assurance): Tests everything end-to-end to ensure it works properly — avoiding reopens and extra billable time later.
This is the general team structure for custom work.
And remember — it’s not just “time coding” that’s billable. The hourly rate includes all time spent — meetings, requirement discussions, revisions, communication — because those are real hours we pay for on our end too.
Sometimes, on smaller projects, a programmer or designer might also handle PM or QA duties. But for larger projects, the full framework applies.
Why It Costs What It Costs
Custom work is awesome, but it can be expensive — especially if you’re inexperienced or tend to change your mind during the project.
There’s a phrase we use often to help put cost into perspective:
“Just because something is easy to explain in concept does not mean it will be inexpensive to build.”
A feature that sounds simple in theory can still take tens or even hundreds of hours to execute properly.
We know this extremely well — we’ve completed over 50,000 custom projects of all shapes and sizes.
And while custom work can absolutely be worth it, if you don’t have an unlimited budget or much experience, the cost and time involved can quickly become frustrating.
The “Pennies on the Dollar” Concept
Here’s where the pennies on the dollar idea comes in.
It’s simple:
If something has already been designed and coded, you can often have it copied to your website for pennies on the dollar compared to building it from scratch.
That’s because most of the cost of a custom project is not just coding — it’s in:
- Ideation: Working with the team to develop and refine the idea.
- Communication: The back-and-forth to get every detail right.
- Testing: QA ensuring it all works flawlessly.
- Project Management: Coordinating it all.
Most of that time is not “in the code,” but it’s still billable.
A Real Example: Carly’s Building Module
Let’s use a real-world example — Carly’s Building Module .
That feature has a lot of custom code and communication time — hundreds of hours. It likely would’ve cost tens of thousands of dollars to invent from scratch.
(It was totally worth it to me — that’s why I built it!)
It also took months to build and went through lots of revisions.
And there’s no guarantee that someone else — especially with less experience — could have built something as good or as efficiently. For another developer, that same feature could easily have cost $50,000 USD or more.
But now that it’s already built (and it’s on my website, where I’m happy to share and let others request it), our customers can have our team copy it for maybe 15–20 hours total @matthutchings keep me honest here?) — instead of hundreds.
So, that’s pennies on the dollar — same result, tiny fraction of the original cost.
Today’s Example: Default IDX Fields vs. Custom Fields
Ok, now for my example from today — I was going to send this to him directly, but this is better since it does come up a lot, and now I’ll have a good place to reference it.
What often comes up for us is “default IDX fields” vs. more custom fields.
Our platform, by default, comes with a solid number of fields — usually 40 or 50 (things like beds, baths, square feet, etc.). That’s more searchable data than you’ll find on Zillow or MLS.ca, but still not 100% of everything that might exist in the MLS.
Why Don’t We Code Everything in the MLS?
There are a few reasons:
1. Cost:
CoreLogic / Matrix and other MLS platforms have hundreds of fields, most of which are never used.
If we tried to code hundreds of fields across hundreds of MLSs, it would cost millions of dollars — pure wasted effort and cost-prohibitive.
2. Consistency:
We’ve mapped fields that are consistent across almost all markets. But in some areas, there are one-off field types like “Horse Ranch.”
Since these are unique to certain regions, we avoid including them in the default — we don’t want “Horse Ranch” showing up as a search option in markets that don’t have them.
3. Feature Bloat:
In most MLS systems, you’ll see 30–40 useful “above the line” fields and hundreds that are never enabled. It’s messy and harder to maintain.
If a feature isn’t relevant or available to our customers, it just clutters the UI and creates confusion in the backend.
Where This Came Up Today
My friend @ChaseSalisbury just signed up and we launched AnnexRealEstate.ca .
Fortunately for him, he’s in the same market as we are, so this concept really helps him 
He brought up “suites” — which isn’t a standard search field — and mentioned he’d been chatting with @SammiHo about how to get it added.
Back in the day, suites wasn’t available at all, so I had to custom code it on CarlyCarey.com.
We built a workaround by doing a search for 2+ kitchens, and then we called that search “with suite.” Behind the scenes, that’s exactly what it’s doing.
Now, if Chase wants to copy that feature, he can easily do so — and it’ll cost him a fraction of what it cost me originally.
Originally, we had to have a developer:
- Find that field (since we weren’t pulling it before),
- Pull it into the database,
- Create all the queries,
- Decide whether to show it on the details page,
- Determine the field type (type-in, multi-select, etc.),
- And basically do all the things that go into mapping a new field.
Chase won’t have to pay for any of that groundwork.
Since it’s not a standard field, the only time we’d bill for is the communication and coding time to copy what’s already done — maybe an hour or two, max.
Important Note: AMs Will Not Shop Your Competition
IMPORTANT NOTE: Your Account Managers (AMs) will not shop your competition.
I’m using Carly Carey’s site as an example for a reason — because clients who are not in my market have my permission to have REW developers copy our features to their REW-only websites.
(Local competitors, however, must have my explicit permission before copying any of our features.)
For everyone else reading this: while things like IDX search fields aren’t unique or proprietary, other elements — such as design features or custom software — are proprietary (to REW, not to the client, and I’ll clarify why).
The one thing we don’t allow is this:
A competitor in the same city asking their AM, “Tell me all the custom things my competitor has done so I can copy them.”
That’s not how this works.
If it’s a site in a different state or province, and the features are publicly accessible, then sure — your AM can walk you through them. They just won’t (and shouldn’t) give you any insight into that customer’s backend.
But the scenario of “I’m in Calgary — show me all the best features your top Calgary client has” is a hard no.
AMs are not permitted to do it.
This isn’t because it’s illegal — technically REW owns the features, so we could copy them — but because we honour our customer relationships. That’s a line we don’t cross, and frankly, I wouldn’t want an AM doing that with my website either.
That said, if you’re outside my market (or a friend), by all means — have your AM walk you through any publicly available features you love, get an estimate, and have them coded for pennies on the dollar.
(Again, REW customers only — all rights reserved.)
By the way — folks like @Pozek and @ChrisColgan are great examples of this approach. That’s exactly why I spend personal time with them and partner on projects — they’re cool with sharing ideas as long as it’s not in their market.
So, if you want a list of the best features and what it might cost to copy them for pennies on the dollar, just let your AM know.
You could literally end up with a $100,000 website for $10–15K, or even a $1M website for $100–150K.
It’s a pretty compelling reason to adopt this concept — and a huge benefit of being with REW.
