The Shopify Agency Founder Who Turns Away £3k Projects on Purpose

Meet Your Interviewee

Key Numbers

The Interview

Most agencies measure themselves by what they add. Octavian Contis, founder of oContis Studio, starts by asking what can go. Eight-plus years across agency and in-house development taught Octavian that rushed contracts trade quality for speed, and that most store problems come from old decisions nobody revisited.

One belief runs through all twelve answers: restraint is a skill, and the honest option is often to do less. Octavian filters clients at £3m+ revenue and £10k+ budgets, enters through a stack audit of around £1,000 to £1,500, and tells clients to keep an app when building it would be a vanity project. Octavian would rather lose a development invoice than build £10k of software to solve a £1k problem. Few agencies say that part out loud.

1What did you spend money on in the first year of oContis Studio that you would now call a complete write-off, and roughly what did it cost you?

In the first year, I spent too much money on tools, subscriptions, and software that I thought would help me build the agency faster. Some of it was useful, but a lot of it was premature. I was paying for systems before I had enough volume to justify them, and in a few cases I ended up replacing them once I understood what the business actually needed.

I’d put the total write-off at roughly £3,000–£5,000.

Contis wasn’t a catastrophic amount of money, but it taught me a useful lesson: don’t build infrastructure for the company you think you’re going to have. Build for the company you actually have, then upgrade when the constraint becomes real.

2Most Shopify agencies sell builds. You sell “Shopify Stack Recovery”, fixing what other people shipped. Walk us through how you landed on cleanup as the offer rather than new builds.

I didn’t really decide one day to sell “cleanup”. It came from noticing a pattern in the work I was already being asked to do.

A lot of Shopify projects look finished from the outside, but once you get into the codebase you find abandoned apps, duplicated functionality, questionable integrations, performance issues, theme code nobody wants to touch, and technical decisions that made sense at the time but no longer make sense for the business.

I kept getting pulled into those situations because I’m comfortable going deep technically and also talking to the client about why something needs changing. Over time, I realized there was a real gap between “we need a new Shopify store” and “our existing store has become difficult to maintain, and we need someone senior to untangle it.”

That also changed how I thought about new builds. A new build can be a great project, but it’s not necessarily where the most valuable problems are. If a merchant already has traffic, customers, data, integrations, and years of accumulated decisions sitting inside Shopify, fixing the underlying stack can have a much more immediate commercial impact than rebuilding everything from scratch.

So “Shopify Stack Recovery” is really a description of the work I naturally ended up doing. I’m not interested in cleaning up code for the sake of clean code. The objective is to understand what the business actually needs, remove the unnecessary complexity, fix the technical constraints, and leave the merchant with a stack that is easier to operate and improve.

The funny part is that I never really set out to specialize in other people’s mess. I just discovered there was quite a lot of money in being willing to open the cupboard everyone else had been avoiding.

“

Every business carries decisions from its past. The work is not to erase that history, but to understand what still deserves to remain.

3Your site gates inbound at £3m+ merchant revenue and £10k+ project budgets. What was happening in the business before that gate existed, and what did you have to turn away to make it stick?

The £3m revenue and £10k project thresholds came from a capacity problem more than a positioning exercise.

Earlier on, I was much more willing to take on smaller Shopify jobs because they were useful for keeping work moving. The problem was that a £2k or £3k project could still consume almost the same amount of communication, discovery, context switching, and senior decision-making as a much larger engagement.

I also found that smaller projects tended to generate more fragmented work. A merchant might come in for a few fixes, then another request, then an app issue, then something else. Individually, none of it was difficult, but collectively it made the business reactive.

Once I had enough demand, I realized I didn’t need to accept every project that came through the door. So I started filtering for merchants where the technical work was actually meaningful to the business and where there was enough budget to do it properly.

The £10k figure isn’t a magic number, and the £3m revenue figure isn’t a claim that smaller merchants don’t need good development. They’re simply useful signals that there’s usually enough complexity, commercial upside and internal maturity for the type of work I want to do.

The difficult part was actually sticking to it. I had to turn away small builds, one-off fixes, and projects where the budget didn’t match the amount of senior involvement required. That was uncomfortable initially because saying no to revenue feels counterintuitive when you’re running a growing agency.

But it made the business considerably easier to operate. Fewer projects, better clients, less context switching, and more time spent solving problems where the technical work genuinely matters.

4Lanoguard came out of your work with a 17.2% conversion lift. What was actually broken before you touched it, and what single change carried most of that number?

When we first got involved, the problem wasn’t simply that Lanoguard had a low-converting page. The bigger issue was that the store had accumulated a lot of developer-dependent customization.

Even relatively basic merchandising changes required a developer, which meant the marketing team couldn’t iterate quickly. The theme was rigid, the code had accumulated technical debt, and there were several parts of the customer journey that hadn’t really been designed for continuous optimization.

We first rebuilt the storefront around Shopify 2.0, giving the team proper control over sections and merchandising. That gave us a much better foundation for CRO rather than trying to optimize a brittle implementation.

The 17.2% figure came from one of the winning Shoplift tests we subsequently ran. I wouldn’t claim that one change magically fixed the entire store because that’s not how the work happened. The lift was the result of identifying a specific friction point in the journey, testing the change against the existing experience, and letting the data decide whether it worked.

What I think is more interesting about Lanoguard is that the CRO became an ongoing process rather than a one-off redesign. We’ve continued testing different parts of the DIY and application-center journeys, with winning tests reaching up to 17.2% higher conversion and 13.4% higher revenue per visitor.

So if you ask me what was actually broken, I’d say the ability to iterate was broken first. Once we fixed that foundation, we could actually start finding and proving the conversion improvements instead of guessing at them.

5Scrumbles is listed at 68% brand revenue growth. How much of that do you honestly attribute to the stack work versus everything else the brand was doing at the same time?

I wouldn’t claim that the stack work caused 108% revenue growth. That would be a pretty convenient story, but it wouldn’t be an honest one.

Scrumbles was growing for a number of reasons at the same time. They were expanding distribution, launching products, investing in retention and acquisition, and growing the DTC channel. Our work was one part of that picture.

What I can attribute to the stack work is removing technical constraints that were getting in the way of that growth.

When we started, they had a fragmented setup with custom functionality sitting outside Shopify, a quiz running on AWS, Recharge handling subscriptions, limited merchandising control, and a data model that had accumulated a lot of bespoke work. The problem wasn’t that any one of those things was completely broken. It was that every new initiative had to work around the existing architecture.

We consolidated that. We migrated the custom app from AWS to Gadget, moved subscriptions from Recharge to Skio, rebuilt the theme around merchant control, introduced custom Shopify Functions for postcode-based delivery, and reworked the data architecture.

There are also some things we can measure more directly. The quiz and Klaviyo segmentation work, for example, produced a 39% increase in gross sales and a 29% increase in orders over six months on the Shopify storefront, while returns fell 10%.

So I wouldn’t take the 108% and say “we delivered that.” I’d say the business was growing aggressively and our job was to make sure the technology wasn’t the thing holding that growth back.

That’s actually how I think about technical work for a growing merchant. You don’t necessarily get to own the revenue number. You own the constraints you can remove, the opportunities you can unlock, and whether the business has a platform it can continue growing on.

“

Technology does not always create growth directly. Sometimes its deeper purpose is to remove the barriers that keep growth from becoming possible.

6Checkout extensibility forced every Plus merchant off scripts and into UI extensions and Functions. Where do you see merchants spending money on that migration that they will not get back?

The biggest waste I see is treating the migration as a one-for-one rewrite.

Shopify has changed the architecture for a reason. Scripts are being deprecated entirely, with Shopify directing merchants toward Functions for things like discounts, shipping, and payments. Checkout. Liquid has already been sunset for parts of the checkout experience, with UI extensions becoming the supported way to add custom checkout functionality.

The mistake is taking every old customization and saying, “We need to rebuild this in the new framework.”

I’ve seen merchants spend serious money recreating little bits of checkout logic, styling, and UI that were originally built because Shopify didn’t provide a native solution at the time. Some of those customizations aren’t actually contributing enough to conversion or revenue to justify rebuilding them.

The other area is over-engineering Functions. If a merchant has a relatively simple discount or shipping rule, rebuilding a whole custom app architecture around it because that’s how the old implementation worked is unnecessary. Shopify’s current Functions APIs cover a lot of what merchants previously achieved with Scripts.

I’d start with an audit of what the old customizations actually do, whether they still serve a commercial purpose, and whether Shopify or an existing app now provides the functionality. Then migrate only what survives that exercise.

The money merchants won’t get back is the money spent preserving technical debt in a new framework.

A migration should simply be an opportunity to simplify the stack.

7You run stack audits as an entry point. What is the most common thing you find that the merchant has no idea is costing them money, and what is the typical bill for it?

The most common one is app and script bloat.

Not necessarily an obviously terrible app. It’s usually five or six perfectly reasonable decisions that have accumulated over two or three years.

A merchant installs an app for reviews, another for upsells, another for a campaign, another developer adds a tracking script, then they replace one of those tools but never completely remove the old implementation. Eventually you have multiple apps doing overlapping jobs, scripts loading on pages where they aren’t needed, and sometimes paid subscriptions that nobody even realizes are still active.

Shopify itself now recommends auditing unused apps, tracking pixels and third-party scripts because of the cumulative impact they have on storefront performance.

The direct bill can easily be £300–£1,000+ a month on a mature store. But that’s actually the smaller problem. If those scripts are slowing down the mobile experience, the real cost is the conversion you’re losing without seeing it as an invoice.

I’ve seen enough stores where the merchant thinks they have a conversion problem, starts looking at ads or redesigning the PDP, and meanwhile the browser is trying to execute a small software company before it can render the page.

A typical stack audit for me is around £1,000–£1,500, depending on the complexity. The interesting part is that the audit usually pays for itself if we find even a few redundant apps or a meaningful performance issue.

And I don’t automatically recommend removing apps. That’s another trap. If an app makes the merchant money, keep it. I want to know what each piece of the stack does, what it costs, what it contributes, and whether there is a simpler way of achieving the same outcome.

“

Complexity becomes costly when it survives without purpose. A simpler system begins with asking why each part exists.

8Apps solve a problem on Monday and become a tax by year three. What is your actual decision rule for when a merchant should rip out an app and pay you to build the thing custom?

My rule is pretty simple: I don’t recommend custom development just because I can build it.

An app should be removed when the cost of keeping it, the limitations it introduces, and the dependency it creates are greater than the cost of owning the functionality ourselves.

I usually look at four things.

First, commercial importance. If the functionality is genuinely core to how the merchant sells, I’m much more interested in owning it than if it’s a minor convenience feature.

Second, how much the app is constraining the business. If the merchant has to change their customer journey, data structure, or operational process to accommodate the app, that’s a strong signal.

Third, the total cost rather than the subscription price. A £100/month app is only £1,200 a year, so rebuilding it for £10k purely to save the subscription makes no sense. But if that same app is causing workarounds, performance issues, data problems, and developer dependency, the economics change.

And finally, whether Shopify can already do most of the job natively. I’m not going to build a custom application to recreate something Shopify or a good existing app already handles properly.

The biggest red flag is when I hear, “We’ve always used it, but nobody really knows why anymore.”

That’s usually when I want to understand the actual requirement rather than the tool.

Sometimes the answer is to rip the app out and build something custom. Sometimes it’s to replace it with a better app. Sometimes it’s to remove it entirely.

The objective isn’t to reduce the number of apps. It’s to have the simplest stack that reliably supports what the business actually needs.

And yes, I’m perfectly happy telling a client to keep an app if building it ourselves would be a vanity project. I’d rather lose a development invoice than build £10k of software to solve a £1k problem.

9Contis reads as you plus a tight bench rather than a headcount agency. Is staying small a strategy or a constraint, and what does it cost you on deals you would otherwise win?

It’s a strategy, but not because I want to keep oContis artificially small.

I don’t think clients particularly care how many people are on the payroll. They care whether the right people are working on the problem.

The core of oContis stays lean, and I collaborate with specialists across email marketing, CRO, strategy, UX, and development depending on what a project actually needs. When things get busy, I can bring additional development capacity in as well.

That gives me access to a much broader skill set without building a permanent headcount around every capability an ecommerce business might eventually need.

There is a trade-off. There are larger retainers and bigger delivery contracts where having a large permanent team makes the procurement process easier. Some clients also want the reassurance of seeing 20 or 30 people behind an agency.

But I don’t see that as a reason to build a 30-person agency.

The constraint is really coordination. If I bring too many people into a project, I have to make sure the quality and technical direction don’t get diluted. That’s why I tend to stay close to the technical and strategic side myself and use collaborators where their specialist knowledge actually adds value.

It also means I’m not selling a fixed team of developers. I’m selling access to the right capability for the problem.

So yes, there are deals we probably wouldn’t win because we’re not a large agency. But there are also projects we can take on precisely because we don’t have to maintain a large permanent team.

For me, staying lean is less about limiting growth and more about keeping the business adaptable. If demand changes, I can change the team around it rather than carrying yesterday’s hiring decisions into tomorrow.

10What is one growth initiative that surprised you, either by working far better or far worse than you expected?

One that surprised me was LinkedIn.

I tested using AI to help produce and publish content because, on paper, it made perfect sense. I could produce more content, publish more consistently, and spend less time writing. I expected the increased volume to at least maintain engagement, if not improve it.

It did the opposite.

Over roughly two weeks, reach and engagement dropped by around 90% despite posting more frequently. It was a useful reminder that increasing the amount of content isn’t the same thing as increasing the amount of attention you get.

What surprised me wasn’t necessarily that people could tell the content was AI-generated. It was that the whole thing became less effective once I removed too much of my own thinking and context from it.

I stopped treating LinkedIn as a content production problem and went back to writing about things I was actually working through: Shopify architecture, CRO decisions, client problems, AI tooling, things I’d changed my mind about.

That performed considerably better.

The lesson for me was that automation is great when it removes repetitive work. It’s much less useful when you automate the part that actually creates the value.

I still use AI heavily. I just don’t outsource the thinking to it.

11What is a lesson that took you far longer to learn than it should have, and what did the delay cost you in money or clients?

The lesson that took me far too long to learn was that not every client who can pay you is a client you should take.

Early on, I was much more focused on keeping the pipeline full. If there was a Shopify project, I could solve it, and the money was reasonable, I’d generally find a way to make it work.

The problem is that a technically straightforward £2k or £3k project can still consume a disproportionate amount of time if the client is indecisive, constantly changes direction, or needs a lot of hand-holding. Meanwhile, that same capacity could have gone into a much more valuable engagement.

I don’t have a clean number for the total cost because the highest cost was opportunity cost rather than invoices I can point to. But I know I lost time on projects that I should have declined, and there were probably several larger engagements I wasn’t available for because my capacity was tied up.

It also took me a while to understand that pricing doesn’t fix a bad-fit client. You can charge more, but if the underlying problem is that the client doesn’t value the work, you’ll still spend too much energy managing the relationship.

Now I qualify much harder around the problem, the merchant’s maturity, budget, decision-making process, and whether I can actually create meaningful value.

That was probably one of the more expensive lessons I’ve learned because the mistake wasn’t losing a £3k project. It was allowing a £3k project to occupy the space where a £15k or £30k project could have been.

12AI coding tools have made a Shopify theme tweak or a basic app close to free to produce. For an agency selling technical depth, where does the defensibility move next?

I actually think AI has created a new problem for technical agencies.

It has made it very easy to “not write code”. You describe what you want, the AI produces something, you test it, it seems to work, and you ship it.

But six months later, someone has to answer a very basic question: what exactly did we build, why does it work this way, and what happens when we need to change it?

I’m already seeing merchants come to me with this problem. They have had AI build a theme feature, an app, or some custom functionality, and now they need someone to untangle it. Quite often, by the time I’ve understood what was actually built, rebuilding it properly is faster and safer than trying to maintain it.

The fundamental issue is context.

AI is very good at solving the problem that’s immediately in front of it. It has limited context about the entire business, the history of the codebase, the operational requirements, the other integrations, and all the weird dependencies that have accumulated around an ecommerce store.

And ecommerce is basically a giant dependency graph.

Your storefront talks to Shopify. Shopify talks to payment providers, fulfillment, ERP, CRM, email, subscriptions, reviews, analytics, marketplaces, and a dozen other systems. Then you have customers, inventory, pricing, promotions, tax, shipping and operational processes sitting on top of all of that.

You can absolutely use AI to build pieces of that system. I use it myself. It can probably replace a lot of the work traditionally given to a junior developer.

What it can’t reliably replace, at least right now, is someone who understands the whole system and can make the architectural decisions around it.

So I think the defensibility moves towards context, architecture, technical judgment, and accountability.

Ironically, the easier AI makes it to ship code, the more valuable it becomes to know whether you should ship that code in the first place.

And I suspect “AI mess recovery” is going to become a fairly real category of work for agencies like mine – I’m writing that down. haha

“

The easier it becomes to create code, the more important it becomes to question whether the code should exist at all.

What Changed

Lessons for Founders

1Build for the business you have

• “A business should not carry the weight of a future it has not yet earned.”
• Octavian learned to invest in tools and infrastructure only when the business had enough volume to justify them. Founders should solve the constraints they face today and upgrade when the next constraint becomes real.

2Protect your capacity

• “Time is not merely something a founder spends. It is the space in which better decisions become possible.”
• A small project can become expensive when it occupies the capacity needed for a larger opportunity. Growth requires knowing which work deserves your attention and which work should be declined.

3Separate contribution from ownership

• “You do not need to claim the whole result to take responsibility for the part you changed.”
• Octavian does not claim responsibility for all of Scrumbles’ revenue growth. Instead, he focuses on the technical constraints his work helped remove and the opportunities it made easier to pursue.

4Automate repetition, not judgment

• “When automation removes repetition, it creates freedom. When it removes thought, it creates emptiness.”
• AI helped Octavian produce more LinkedIn content, but engagement fell when the process removed too much of his personal thinking. The lesson is simple: use automation to create more space for judgment, not to replace judgment.

5Question what you keep

• “The presence of something is not proof of its value. Every system deserves to be asked whether it still has a reason to exist.”
• Apps, integrations, processes, and technical decisions should not remain in place simply because they have always been there. Founders should regularly ask what each part contributes, what it costs, and whether it still serves the business.

What Octavian Would Tell Another Founder

“

“Maturity is not the ability to build everything. It is the wisdom to recognize what does not need to be built.”