Sometimes the Quote Is Part of the Work
A few weeks ago, I was contacted by an automotive performance parts manufacturer about doing some work on their Shopify store.
At first glance, it sounded pretty straightforward.
They wanted a more polished homepage. There was an upcoming publicity opportunity, so there was some urgency around making the site look better. They wanted customers to be able to find parts by vehicle. They wanted some prominent product categories on the homepage. There were conversations about navigation, product information, content, and making the whole thing feel more like a finished ecommerce site.
None of that sounded unreasonable.
In fact, it sounded like a fairly normal Shopify project.
Then I started trying to quote it.
And that is where things got interesting.
You Can’t Really Quote What You Can’t See
One of the recurring problems with website work is that the public website tells you surprisingly little about the website.
I can look at a homepage and tell you whether the design works. I can see whether navigation is confusing. I can search for a product, click around on a phone, inspect the code being sent to the browser, and identify plenty of problems from the outside.
What I can’t see is the machinery behind it.
For an ecommerce store, that machinery matters.
How are the products organized? How is inventory being tracked? Where does the product information come from? Which apps are controlling what? Are collections created manually or automatically? Is vehicle fitment stored consistently? Are shipping rules already configured? Are there old systems still hanging around from previous versions of the store?
There is an enormous difference between changing the wallpaper and discovering that the wall behind it has plumbing running through it.
So I needed access.
That part also had to be done correctly.
Shopify has a system specifically designed for outside companies and developers to access stores without the owner handing over a password. That’s a good thing. Everybody gets their own account, permissions can be limited to what they actually need, and Shopify maintains a record of who did what.
In this case, there was some existing account and development access that had to be sorted out first. A proper collaborator request had to be sent and approved. Then the permissions needed to be adjusted because simply having access to the store didn’t necessarily mean having access to the apps and settings I needed to evaluate.
None of this was particularly dramatic.
It was just friction.
And friction during discovery can be frustrating because nobody feels like progress is being made.
The customer wants a number.
I want to give them a number.
Instead, we’re talking about account permissions.
But the alternative is worse: make assumptions, produce a quote based on those assumptions, start the project, and discover two weeks later that half of those assumptions were wrong.
I’d rather have a few frustrating conversations before a project than an expensive one halfway through it.
Technical discovery & auditing
The public page doesn’t tell you much about the machinery behind it. Raymond Tec audits inherited and long-running projects to uncover the plugins, integrations, data, dependencies, and old decisions that determine what the next change will really involve.
Then I Got Inside
Once I finally had enough access to look around, the project changed.
Not because the customer had been dishonest about what they wanted.
They were describing the problems they could see and they knew the customers would encounter.
That’s an important distinction.
Most customers aren’t going to call and say, “I believe my underlying product taxonomy and historical application architecture need to be normalized.”
If someone actually calls me and says that, I’m probably going to assume they’re another web developer playing a prank.
Customers say things like:
“I want these categories on the homepage.”
“Customers should be able to search by their car.”
“I want this page cleaned up.”
“We need our products organized better.”
Those are completely reasonable descriptions of symptoms.
Discovery is where you figure out the cause.
And inside this store, there was a lot more history than the homepage suggested.
More Hands Had Been in Here than a Bus Station Sink
There were fewer than two dozen currently active products, but more than a thousand archived ones.
There were roughly two thousand collections.
There were numerous apps, some performing important functions and others representing different eras in the store’s development.
Vehicle fitment was already being handled by an app, but that didn’t mean the underlying product and fitment information was ready to support the experience the customer wanted.
Shipping, inventory, product sources, locations, fulfillment, and distributor relationships all needed to be understood before making major decisions about how the catalog should work.
Suddenly, “put eight product categories on the homepage” wasn’t really a homepage question anymore.
Which eight categories?
Where do the products inside those categories come from?
Are those products already in Shopify?
Are the archived products usable?
Should some of the thousands of existing collections be preserved?
Which collections are there because a person created them, which came from an app, and which are leftovers from some previous approach?
If a customer searches for a particular year, make, model, and engine, can we trust the products being returned?
These questions aren’t academic.
If I make a beautiful button that says “Exhaust Systems,” but the catalog behind that button isn’t properly populated, I haven’t solved the problem.
I’ve just made a very attractive entrance to an empty room.
The Catalog Told Another Story
I had already noticed some oddities while looking at the public site.
There were vehicle fitment ranges that didn’t appear to be accurate. There was placeholder copy still visible in places. Some product information appeared to have been copied from unrelated products. Image descriptions didn’t always match what was being displayed. Search information was inconsistent.
Individually, these aren’t catastrophic problems.
Every mature website accumulates weird stuff.
I maintain websites that have been through multiple redesigns, plugins, owners, developers, hosting companies, and business strategies. If you open enough cupboards, eventually you’re going to find a Tupperware lid that hasn’t matched a container since 2014.
The important question is whether the weird stuff is isolated or structural.
The deeper audit showed that simply turning old products back on wasn’t going to solve the catalog problem.
Hundreds of archived products were missing images.
A large portion weren’t configured to track inventory.
Many were missing useful search information.
And some of the major product categories envisioned for the redesigned site didn’t yet have a clean, usable catalog sitting there waiting to be activated.
That completely changes how you approach a Shopify project.
The original mental picture was something like:
Redesign the homepage, improve navigation, configure fitment, organize some products, and make everything prettier.
The reality was closer to:
Figure out what should constitute the product catalog, determine where reliable product information is going to come from, decide how inventory and fulfillment should work, clean up years of accumulated structure, verify the fitment system, simplify the applications involved, build sensible collections, and then design the customer experience around that foundation.
The homepage was still important.
It just wasn’t the beginning anymore.
Ecommerce catalogs & product data
Product data gets complicated surprisingly fast. Whether the store runs on Shopify, WooCommerce, Magento / Adobe Commerce, BigCommerce, or another platform, categories, collections, inventory, search, fitment, images, vendors, and fulfillment all have to agree about what you’re actually selling. Raymond Tec helps untangle ecommerce catalogs and product data before the front end gets built on top of bad assumptions.
This Is Where Shopify Project Quotes Get Uncomfortable
From the customer’s perspective, this can feel like the project is getting bigger every time somebody looks at it.
That’s not a great feeling.
You start with, “Can you improve my website?”
A week later somebody is talking about product data and shipping configuration.
What happened?
Did the consultant turn a modest project into a giant one?
Sometimes, yes. That absolutely happens in this industry.
But sometimes the opposite is happening.
The original quote was describing the visible request.
Discovery is revealing the actual work required to accomplish it.
Those aren’t always the same thing.
I could have produced a much smaller proposal by ignoring everything behind the homepage.
I could have changed some colors, rearranged some blocks, built some category graphics, installed another app or two, and handed over something that photographed beautifully.
The customer probably would have been happy with it for a little while.
But eventually somebody would click one of those categories.
Eventually inventory would matter.
Vehicle fitment would matter.
Shipping and fulfillment would matter.
Eventually they would want to add hundreds or thousands of products.
And then the project we didn’t do the first time would still be waiting for us.
Only now we’d have a shiny new website sitting on top of it.
Discovery Also Happens While the Target Is Moving
There was another wrinkle.
While I was reviewing the site and preparing the proposal, work was continuing on the store.
Pages were changing. Collections were being created. Content was being edited. Different approaches were being tried.
Again, this isn’t inherently bad.
It’s the customer’s website. Of course they’re allowed to work on it.
But it makes discovery interesting.
Imagine somebody asks you to estimate the cost of remodeling a kitchen.
You show up Monday and measure everything.
On Tuesday they move the refrigerator.
Wednesday there’s a new cabinet.
Thursday somebody decides there should be an island.
Friday you’re staring at your measurements wondering whether you’ve accidentally entered an alternate universe.
Websites can move that quickly.
This is one reason estimates on existing systems sometimes contain ranges instead of beautifully precise numbers.
Precision is only useful when the underlying information is precise.
I’d rather say a project appears to require somewhere within a reasonable range of effort and explain why than confidently announce a number I manufactured from incomplete information.
False precision doesn’t make a proposal more professional. It just makes the surprise invoice later more awkward.
The Quote Became a Roadmap
By the time I finished reviewing everything, I wasn’t really writing a quote for a homepage anymore.
I was describing a sequence.
First, understand and stabilize the underlying store.
Then:
- Establish the product and catalog strategy.
- Determine how fitment, inventory, distributors, shipping, and fulfillment should interact.
- Clean up the collection structure and unnecessary legacy pieces.
- Build the front end around something we can actually trust.
That is a much larger project than moving some blocks around on a homepage.
It is also a much more useful project.
Whether the customer ultimately hires me to do it isn’t really the point.
The discovery process still produced something valuable.
It converted a vague collection of requests into a description of the actual system.
That’s useful information even when it’s uncomfortable information.
Sometimes “No” Is a Successful Discovery
This is the part of quoting work that doesn’t get talked about enough.
Discovery doesn’t always end with a signed proposal. Sometimes everybody gets to the end and realizes the project is larger than expected.
Maybe the budget doesn’t make sense; the timing doesn’t work; the customer decides they’re comfortable tackling portions of it themselves.
Maybe another company is a better fit.
That’s okay.
A quote shouldn’t be engineered backward from the number somebody hopes to hear.
The job is to figure out what it will reasonably take to achieve the desired result and explain that as clearly as possible.
Otherwise we’re not estimating the project. We’re negotiating with reality.
Reality is generally very bad at compromise.
The Most Useful Question Changed
At the beginning of this process, the question was:
“What would it take to make this Shopify store look better?”
By the end, the question was:
“What would it take to make this Shopify store work the way this business wants to operate?”
Those are very different questions. And that, ultimately, is why discovery matters.
The best website work isn’t just about making pages prettier. It’s about understanding what the business is trying to accomplish, figuring out what’s preventing that from happening, and then designing around the answer.
Sometimes that’s a new homepage, a catalog clean up, or simplifying five different systems that accumulated because each solved a small problem at a different moment in the company’s history.
Usually it’s some combination of all three.
Discovery can be tedious, frustrating, and make a project look larger instead of smaller.
It can even lead everyone involved to decide not to do the project.
But if it exposes the difference between the thing someone asked for and the thing they actually need, it did its job. And I’d much rather discover that before anybody starts tearing down walls.
Have a technical project that’s difficult to describe? Start with what’s broken, missing, annoying, or taking too much time. Tell Raymond Tec what you’re trying to accomplish, and we can work backward from there to figure out what the project actually is.
