Pricing the job before the call
A cleaning firm whose customers decide under pressure. The site had to answer “how much” without a manager, in two languages, and stay inside GDPR.
What this was
and what I did on it
- Client
- Mopiko — a cleaning company in Poznań, Poland
- Audience
- Ukrainians and Poles who need cleaning quickly, often under stress
- My role
- Research, UX, interface, front-end, copy (UA/PL), SEO, GDPR, accessibility, deploy — one person
- Scope
- Homepage, a dedicated order flow with a live calculator, service pages, two language versions
- Built with
- Plain HTML, CSS and JavaScript — no builder, no framework, no build step
- Live
- mopiko.pl ↗
Nobody books cleaning calmly
they book it with guests at the door
People look for cleaning under pressure: guests arriving, a move, the end of a renovation. They will not read a long page or wait for a manager to call back — they need a price and a way to order, now.
So the site had one job: shorten the path from “arrived” to “messaged”, and on the way remove the three fears that stop the click — how much, what is included, can I trust them.
Five calls that shaped it
and what each one cost
-
01
Put the price before the contact form
The calculator prices the job on the spot — property type, rooms, bathrooms, area, add-ons — and a running “Your order” panel recalculates the total as you go. No manager in the loop, no “we'll get back to you with a quote”.
Trade-off. A calculator is a promise. Every rule in it has to match the real price list, so the pricing model had to be pinned down with the client before a single screen was drawn — and it has to be kept in step when prices change. -
02
Send the order in one tap, and keep a second door
The completed order opens Telegram with the whole thing already written out: rooms, add-ons, date, total. Three fields — name, phone, date — because each extra field costs conversion.
Trade-off. A messenger-first flow excludes people who don't use one, so a plain “leave a request, we'll call back” runs alongside it. Two paths to build and maintain instead of one. -
03
Two languages as two sets of pages, not a switcher
Ukrainian and Polish live as separate indexable pages tied together with hreflang, so Google can show the right one to the right person.
Trade-off. A runtime switcher would have been a fraction of the work and invisible to search. Separate pages doubled the copy to write and the surface to keep in sync — that is the price of being findable in both languages. -
04
Ask for consent before anything measures
An opt-in cookie banner and a privacy policy: no analytics fires until the visitor agrees.
Trade-off. It loses data at the very top of the funnel — the part every marketer wants. The alternative is exposure to fines up to €20M or 4% of turnover under GDPR/RODO, which is not a trade worth making. -
05
Build on tokens, ship on a pipeline
Colour, type and components sit on switches in one place, so a brand shade changes across the whole site in minutes. Every change deploys itself within a minute of being pushed.
Trade-off. More setup before anything visible exists. It pays back from the first change request onward — and the client can be handed the keys without a maintenance contract.
What the decisions look like
in the working product
Numbers I can stand behind
Lighthouse 12, mobile profile, measured on the live site on 2 August 2026 — not copied from launch day. Accessibility, best practices and SEO are the build and hold at the top. Performance is lower than it shipped: the page now loads 281 kB of Google Tag Manager added by the owner after handover, which is the single heaviest thing on it. I would rather publish that than a flattering number from a year ago.