Leave the Shopify engineering
to us — all of it.
The planning and the client relationship stay with you.
Popaz takes on the Shopify engineering only — feasibility calls, requirements, architecture, ballpark figures, implementation.
We can come in before you've won the work, or join a project already underway.
WHEN WE JOIN
Four stages where we can join
One stage on its own, or several together — whichever suits.
We also take enquiries that are purely technical judgment calls.
- Before the proposal
- We set out feasibility, architecture and a ballpark figure.
We confirm whether it works on Shopify and come back with a proposed structure and rough costs. A technical check on your proposal deck or estimate alone is fine too. - Requirements definition
- We turn the request into a specification that can be built.
We separate what is and isn't possible, and join meetings where it needs explaining to the client. - Implementation
- We take on only the technical areas you need.
Theme work, custom apps, external integrations — whichever engineering piece the project is short of. - Across projects
- We support technical judgment across several projects at once.
Feasibility, architecture, ballpark figures, sitting in on proposals — as your ongoing technical desk.
ESTIMATES
Estimates and timelines come from breaking the requirements down.
We break your requirements down to the level of individual tasks and sort them into settled / needs confirming / not yet decidable, then build the ballpark figure and timeline from there.
Where the budget falls short, we don't simply lower the number — we split the work into what to do now, what to add later, and what to move to a next stage.
We also tell you what has to be confirmed for the figure to firm up, and which parts drive the schedule.
HOW WE APPEAR
We can work in front of the client, or behind you.
We can join under the Popaz name as an outside technical lead, or as part of your team.
If it helps, we'll use an email address and title you issue, and attend client meetings.
The client relationship stays yours. We hold up the technical side.
Just tell us which form you want for each project.
TAKING OVER
We take over live stores without taking them down.
The engineer has left. You want to change maintenance partners. The previous development company is unreachable.
In cases like these we don't start fixing straight away — we read the existing implementation first.
Read the current state
We separate what is working, what is broken, and what is no longer used.
Without touching the live store, we check the theme, apps, external integrations and how the data is held in a duplicated environment.
Write up what we found
We document what we established, what still needs confirming, and where a change would have knock-on effects.
It's written so it can also be handed to the next company.
Decide how much to hand over
All of it, or only part — either is fine.
Whether to rebuild or keep the current structure is decided after seeing the findings.
WHAT TO SEND
To start, we only need these.
The requirements don't need to be settled. But a bare list of features hides the purpose of the project, which actually makes pricing harder. Once we've seen the material, we'll also tell you whether we're in a position to take it on right now — we cap the number of projects we hold at once.
Where the project stands
A quick note on the situation — new build, replatform, added features, a takeover.
Whatever materials you have to hand are enough; there's no need to prepare anything for us.
What you want us to handle
The scope you'd like this time — a feasibility check alone, an estimate, requirements definition, implementation, sitting in with the client.
If that isn't decided yet, that's something we can work through with you.