You launched your Shopify store a few months ago. Everything runs smoothly. Conversion rates are okay, customers are happy. Then, somewhere between month 12 and 18, you notice: Something isn't right anymore.
New features suddenly take longer. Your theme gets slower and slower. Apps don't talk to each other. And the code -- which nobody documented -- has become impenetrable.
That's not a coincidence. We call this the 18-month problem.
In over five years of Shopify development, we've seen this dozens of times. And we know what causes it: It's not about Shopify. It's about architecture.
The 18-Month Problem: Three Symptoms, One Cause
When we speak with new clients who want to optimize their system, I often hear the same complaints:
1. Theme Patchwork: "Our theme has become impossible"
The theme -- that's the visible surface of your store -- becomes the first victim of poor architecture in most stores. Here's what happens:
- You need a new landing page. The developer modifies the existing theme.
- You need a custom collection page. A different developer works on it.
- After 18 months: The theme is a conglomerate of customizations, workarounds, and patches.
- A new feature no longer takes one week -- it takes three weeks because all dependencies need to be understood.
Without structure, your theme becomes a monument to technical debt.
2. App Dependencies: "We can't replace any system without breaking everything"
The second symptom is subtler -- but more expensive in the long run.
Instead of custom logic, you rely on apps. That's sometimes the right decision -- but often only because the alternative architecture wasn't planned:
- You need a custom collection page with complex filter logic? App.
- You need a custom discount system? App.
- You need inventory management with special rules? App.
After 18 months: You have 12 apps installed. Together they cost 800/month. And each of these apps has an API with different interfaces. Replace one app? That means you have to rewrite code everywhere the app stores data.
3. Undocumented Code: "We don't know what's happening here"
The third problem is the most dangerous: Without clear architecture decisions, code is simply built -- without context, without a plan.
- Why do you store this data in Metaobjects?
- Why does this calculation happen in the theme and not in a Product Variant?
- Why are there 24 collection templates instead of five intelligent templates?
Nobody can answer. The developer who built it left long ago.
What Shopify Architecture Actually Means
Let's clarify: Shopify architecture is not simply "clean code" or "best practices."
Shopify architecture is a decision structure that defines:
- Where your logic lives (Shopify Admin, Theme, API, Custom App?)
- How your data is organized (Metaobjects? Product Variants? Custom App?)
- Which systems talk to each other (APIs? Webhooks? GraphQL?)
- When you need apps and when you write custom code
Most stores haven't made any of these decisions consciously. They reacted -- to new requirements, to time pressure, to whatever worked fastest at the moment.
The result: A system that's impossible to maintain.
A Real-World Example: Bekateq
Bekateq is a B2B store with a very specific requirement: Customers need individual volume discounts per item. That's impossible with Shopify's standard discount system.
The wrong-way solution: Buy an app that can do it. Cost: 200/month. Automation: Zero.
The right-way solution (the one we built with Bekateq):
- Data structure: Custom Metaobjects for "Customer-Specific Pricing"
- Logic: A small Custom App (80 lines of code) that adjusts prices when items are added to cart
- Integration: Directly into the Cart GraphQL Query -- no detour through external APIs
The result: 4,400+ lines of strategic custom code instead of 12 expensive apps. Maintainability: 100%. Cost: A fraction.
That's architecture.
Metaobjects, Custom Logic, Structured Data -- Simply Explained
If you want to rethink your store architecture, you need to understand three concepts:
Metaobjects: The Data Container
Metaobjects are Shopify's newest (and best) answer to the question: How do you store custom data in a structured way?
Instead of putting properties on Products (which didn't scale), or storing JSON strings in product.metafields.namespace (which becomes unmaintainable), you can now define templates:
Customer Pricing
-- Customer (relationship)
-- Product (relationship)
-- Discount Percentage (number)
-- Valid Until (date)
And Shopify stores it in a structured way. You can filter, sort, and build logic on top of it.
When you need Metaobjects: Whenever you want custom data that's associated with multiple Products or Customers. Pricing, bundles, variant rules, personalization -- they all live in Metaobjects.
Custom Logic: Where Your Magic Happens
Custom Logic is not theme code. It's not an app. It's the layer between Shopify's database and your customers.
Custom Logic can be:
- Product logic: When Product A is purchased, Product B must automatically be added to cart.
- Variant logic: Certain combinations of options are not allowed.
- Pricing logic: The price depends on customer attributes or quantities.
- Order logic: After checkout, something specific must happen.
The question isn't "do you need Custom Logic" -- but "where does it live?"
In the theme? No -- that becomes too slow and unmaintainable. In an app? Only if there's no better way. In a Custom App that you control? Yes -- that's architecture.
Structured Data: Your System as an API
Good architecture makes your store an API, not a black box.
This means:
- Your data is structured (Metaobjects, not JSON strings).
- Your logic is clear (Custom Apps with one responsibility, not monolithic code).
- Your interfaces are documented (GraphQL queries, not secret admin code).
This makes it possible to:
- Onboard new team members (everything is documented).
- Build new features (everything is modular).
- Replace systems (everything is based on clear APIs).
How We Approach Architecture Projects: Real Examples
This all sounds theoretical. Let me show you concretely how it works in reality.
Case Study 1: J.Clay -- 3 Iterations Over 5 Years
J.Clay is a fashion e-commerce with high demands for personalization.
We didn't redesign everything at once. We built an architecture for evolution:
Iteration 1 (2020): Foundation
- Metaobjects for size tables
- Custom App for size prediction logic
- Clear separation: Theme handles rendering, Custom App handles logic
Iteration 2 (2022): Scale
- New Metaobjects for customer preferences added
- Custom App extended with personalization engine
- No theme refactor needed -- everything runs through new APIs
Iteration 3 (2024): Performance & Intelligence
- GraphQL queries optimized (before: 500ms for collection page, after: 120ms)
- AI-based recommendation engine added (again: through Custom App)
- Theme was never a bottleneck
The result: +107% revenue growth over 5 years. And the theme? The same as 2020, just optimized.
That's good architecture.
Case Study 2: Bekateq -- From 12 Apps to 0
Bekateq is a B2B store with complex requirements. They had 12 apps installed -- all trying to fill different parts of a missing architecture plan.
We built an architecture plan:
Apps: 0 (seriously) Custom Metaobjects: 8 (Customer Pricing, Volume Pricing, Approved Vendors, etc.) Custom Code: 4,400+ lines across 4 Custom Apps Collection Templates: 24 (not 12,000 CSS hacks) Monthly Costs: Down from 2.5k to 400
And the most important point: The system is maintainable. Every Custom App has one responsibility. Every Metaobject has a reason to exist. Every template has a goal.
When a new person joins the team, they can be productive in two weeks -- not after two months.
Checklist: Does My Store Need an Architecture Revision?
If you recognize one or more of these points, then yes:
- Your store is older than 12 months and new features take longer than at the beginning
- You have more than 8 apps installed
- Your theme code is > 5,000 lines (without dependencies)
- You use JSON strings in metafields instead of Metaobjects
- Your developers can't explain "why" something was built that way
- You're paying more than 1k/month for apps that only do one thing
- A new collection page variant took more than a week
- Your store has custom logic that "somehow works, but nobody understands it"
- You have multiple versions of similar templates (e.g., 5 different collection pages)
- Changing a feature requires updating code in 3+ different places
3+ checks? You need an architecture revision.
And yes, that costs time and money. But it costs less than having a system that becomes unmaintainable in the long run.
What We Would Do with Your Store
When you talk to us about an architecture revision, there's a clear process:
Phase 1: Audit (1-2 weeks)
We examine your current store:
- Code review
- App audit
- Data structure analysis
- Performance testing
Result: A report showing where the problems are.
Phase 2: Architecture Planning (2-4 weeks)
We build a new plan:
- Which apps can go? (and how?)
- Where is custom code needed?
- Which Metaobjects are necessary?
- How will the migration be performed?
Result: A technical roadmap we both agree on.
Phase 3: Implementation (6-12 weeks)
We build:
- New Metaobjects
- Custom Apps
- Refactored theme (if needed)
- Migration of old data
Result: A maintainable, future-proof store.
Our Architecture+ Service starts at 10k and includes all three phases.
The Uncomfortable Truth
Good Shopify architecture isn't sexy. There are no slides to share on LinkedIn. It's not a new app, not a new feature.
It's craftsmanship. It's planning. It's the opposite of "quickly hacked together."
But it's also the difference between a store you can easily scale in 5 years -- and a store whose complexity spirals out of control.
We've seen both kinds. We know which one is better.
If your store is getting older and you notice something isn't right, it's time to think about it. Not next year. Now. Before the 18-month problem catches up with you.
About Claudio Gerlich
Claudio Gerlich is the founder of smplx. and a technical Shopify partner since 2020. From Munsterland, NRW, he has architected and optimized over 50 enterprise stores. His expertise lies in planning systems that don't collapse -- even when e-commerce grows.
If you'd like to talk about your store architecture, reach out to us.