The decisions made before building
determine whether development succeeds.

Shopify can do a great deal, but it is not right for every business.
We have had projects where, after being asked to develop something, we said “Shopify isn't the right fit here” and the client rethought the premise.
With enough effort we could have made it work. But bending your operations around the wrong tool, and carrying that mismatch for years, costs more.

We look not only at whether it can be built, but at how well the tool fits over the years you'll be using it.

Before considering how to implement, we go back to what needs to happen for the people receiving it and the people running it.
On one project we were told a system was needed to issue and send documents in a fixed format. When we checked the purpose, what was actually needed wasn't the document — it was certain information reliably reaching the recipient.

So we built the necessary information into a notification that was already in use. The recipient gets the same content, and no new work was added on the operations side.

Going back to the purpose often finds a more natural answer while reducing how much has to be built.

Before custom development, we work through whether it can be solved with what's already available.
Development cost isn't the only reason. We also think about who maintains it after launch, and who keeps up as Shopify changes.
With a public app, maintenance and updates are shared across many users. Build the same feature yourself and that responsibility sits with the client and with us from then on.

On one request to finely control behaviour at checkout, we met the goal with a combination of theme work and operational change rather than custom development. It cost less, and it left room for the client to adjust things themselves later.

The same concern — “these app fees are getting heavy” — leads to different answers depending on the size and stage of the business.
If the burden on the business is large and custom development would pay off, it's worth building even while taking on the maintenance. If the burden is still small, staying on the public app keeps you lighter.

What we look at isn't the figure itself, but the burden relative to the business and the gain a custom build would deliver.

There is also this: the moment you build it yourself, maintenance becomes your responsibility. A setup that requires a request to a development company for every change narrows the range you can move in on your own.
We weigh both — what you pay now, and the dependency you're left with.

We consider Shopify Plus only when a requirement appears that nothing else can meet.
Having more features available is not the same as your business needing more features.
Upgrading on the grounds that you “might use it one day” only raises your fixed costs ahead of features you aren't using yet.

You can choose it when you need it, against the requirements and the state of the business at that point. That is one of the reasons to be on Shopify in the first place.

With external integrations, what we look at is not how easily they connect, but whether you can still decide your own operations afterwards.
Depend on one integration service and that service's limits become the ceiling on what you can do. Keep bending to its specification and its convenience starts to outrank how the business actually needs to run.
We don't hand over all your data just because it can be connected — only what the purpose requires crosses the boundary.

Keep the dependency small and, when the other side's specification changes, the blast radius stays small too.

Our estimates are built from the scope that has to be newly designed and implemented, not from a page count.
The same number of pages takes a completely different amount of work when everything is built from scratch versus when existing pieces are combined.

An existing section can be reused. A standard feature will do. A setting change is enough.
We don't price those parts as if they were new development.
What costs what, and why — we write estimates you can follow.

If the budget falls short, we won't take on the same work for less.
Forcing the number down pushes the shortfall onto design, testing and how the data is held — the parts that come back to bite you later.

Instead we set out the goal and the priorities, and split the work into
what to do now,
what to do if there's room,
and what to move to a later stage.

Start small where it matters most, and keep what was deferred as a live option for the next step.
We don't cut the budget — we decide which scope leaves the most value inside it.

Reviewing is itself a process that spends your time.
Opening the screen. Checking the content. Gathering opinions internally. Putting the reply together.
All of that costs you time.

On projects with a wide scope we break things up early and align direction often. Where the scope is contained, we review in larger batches. We adjust the approach by weighing the risk of rework against the burden of reviewing.

That said, cutting reviews is not the goal in itself.
A final review before launch, and testing on both sides, always happen.

What we build is handed over in a state you own and can run yourself.
The code and the accounts needed to operate it are your assets. We don't lock your data into a particular app or into a form only we can handle — we design with the possibility of moving to another approach in future.
We leave as little as possible that requires a request to us for every change.

Once operations have settled, it keeps running without us.
That is the ideal state after handover.

So that limitations and risks don't surface later, we align on the premises before starting.
Where a condition is difficult, we say up front where the problem lies, and think with you about whether changing the premise would let it go ahead.
A limited budget alone is never a reason for us to decline. If what to do now can be separated from what to defer, we look at ways to start small.

That said, there are conditions we may not be able to take on.