Ground rules
Know the rules before our first call.
How we start, how I bill time, what happens when something's urgent or the budget doesn't stretch, and what I don't do. I don't publish rates or surcharge amounts. The rules are all here.
Getting started
From the call to the first fix
01
Free call
You describe what's happening and what you need. We check whether there's a fit. Up to 50 minutes, by phone or Google Meet, whichever you prefer. No obligation and no cost.
02
Credentials, handled safely
I send the login and password through two separate channels and ask you to do the same. Access I'm given stays in a local password manager secured with a key file and a password, never in the cloud.
03
Paid audit
You know the audit's price before it starts. At the end you get a report: the state of the store and the server, a prioritized list of problems, recommendations with an estimate of the work. It usually takes 7-10 days, depending on my current workload and how quickly I get access and materials. The report is yours to keep regardless of what you decide next.
04
Fix or development
I work through the report's priorities, under whichever of the three models below you choose.
Ways of working together
Three ways, no price list
They differ in planning, and in how well I already know your store before something breaks. I take on a limited number of long-term clients. Not sure which fits? Let's work it out in a free call.
Model 1
A one-off job
A specific issue with a defined scope.
- Billed by time worked
- An estimate before we start, if you need one
- Timing follows my current queue, faster in express or urgent mode
Model 2
Prepaid hours
A pool of hours bought upfront for ongoing requests.
- Lower hourly rate than a one-off job
- We size the package together in the call
- Valid for one month; unused hours roll over to the next month only
Model 3
Monthly retainer
Knowing your business and your store's current state, I react faster and more accurately.
- Work scheduled ahead, express mode rarely needed
- Lower hourly rate than a one-off job
- Outage reaction can be faster than 4 hours, sometimes within the hour
Work modes
Faster, when you need it
I work Monday to Friday, 9:00-18:00 CET/CEST. Work scheduled ahead goes at the standard rate. When you need it faster, you get it faster, for a surcharge you know before work starts. You can send a request any time. Outside those hours I take it on if it needs doing and I can, for a surcharge.
Scheduled
Work in the normal queue, agreed on ahead of time. Billed at the standard rate.
Express
Done within 5 business days instead of the normal queue, for jobs that fit in that time. With a surcharge.
Urgent
An outage - something that's actually hurting the store. I react within 4 hours during working hours. With a surcharge.
Weekend
Saturdays and Sundays aren't my working days, but you can still send a request. If it needs doing and I can take it on, I do. With a surcharge, retainer clients included.
Pricing
I bill for time worked, not tasks
I track time in 5-minute increments, minimum 15 minutes. I give an estimate when you need one, as a range with a ±20% margin, or ±30% when the scope isn't settled yet. On a project with an estimate, two extra line items apply: coordination (10% of the time) and clarifying requirements with you (another 10%). For a bigger scope, you get three variants: cheaper, standard and expanded, broken down into tasks with hours.
When I see an estimate won't hold, I say so right away and we decide together what's next. I don't estimate an outage: fixing one usually takes 1-4 hours, and there's nothing meaningful to estimate there. I invoice in EUR, USD and PLN.
A tight budget
Four ways through when the budget doesn't stretch
Each one costs me a piece of the work. I'd rather say so outright than sell you something you don't need.
Cutting part of the scope
I show you what can be postponed or skipped without hurting the rest.
A simpler solution
The same goal for less, with the trade-offs named.
Part of the work on your side
You or your team take on the parts you can do yourselves.
Accepting minor flaws
Deliberately, and only minor ones. Never critical.
Working in someone else's code
Modules you can still update after my changes
Plenty of stores run for years on outdated modules because nobody knows what was changed in them. I sign, date and describe every change I make in someone else's module, and wrap it in start and end markers. After an update, those entries are easy to find and reapply. Any developer who comes after me, including yours, can see what I did and why. I also step in alongside an existing contractor, not to replace them. Specific cases, including a fix accepted into the PrestaShop core, are in the case studies.
When there's no staging environment, I set one up at the start of the engagement. It's not a condition for taking the job, just a way to keep changes from going straight to production. The exception is an outage: then I restore the store on production first, and set up staging once it's working again.
A bigger project
Example: moving to a newer PrestaShop
On your side: the graphic design, the module licenses, and the list of modules to keep. It's a good moment to drop the ones nobody uses anymore.
01
Environments
Dev, staging and production environments, with a repository and separate databases. Nothing goes straight to production.
02
Update or rebuild
The choice depends on whether the core and the database pass the tests on the new version. An unmaintained theme doesn't have to mean a new theme: dadum.pl uses Classic Rocket, a free rework of PrestaShop's default theme. Classic Rocket has no release for PrestaShop 8, but after a few changes on my side, it works on 8.2.
03
SEO through the migration
I keep the URL structure. After switchover, I monitor Search Console and fix whatever it flags.
04
Switchover
In the lowest-traffic window, tested at every stage.
Boundaries
What I don't do, or advise against
Graphic design
I don't do graphic design. I code the theme from a designer's mockups.
A new store on an off-the-shelf marketplace theme
I advise against it: no off-the-shelf theme is a good base for a new store, in my experience. A few of them, including Warehouse and Transformer, I've worked with enough to know their weak spots and how to work around them.
New builds on other platforms
I don't build new stores on Magento, Shopify or WooCommerce. I do work on other platforms where the platform itself matters less: server, DNS, configuration.
Jobs decided by the lowest price
I don't compete on price with offers on classified-ad sites. I work for companies that know a specialist costs money.
Outside my scope
When the problem goes beyond what I do
I tell you plainly and point you to a specialist, for example a data protection officer or a server administrator. I give them what they need from my side and handle contact with them on your behalf. The problem doesn't drop off my list just because it moved outside the code.
Next step
Let's start with a call
Tell me what's happening and since when.