Why is it priced by complexity instead of a flat package?
Because two "five-page sites" are rarely the same job. One is static text; the other
has a booking calendar, payments and an admin panel. Pricing at the lower end of the
first and the upper end of the second would mean overcharging half my clients.
So: the tier sets the base, pages and features scale it, and infrastructure is itemised
as its own line.
What counts as "additional configuration"?
Anything beyond writing the code and publishing it: registering or transferring a
domain, pointing DNS records, provisioning and hardening a VPS, issuing and renewing
TLS certificates, setting up email on your domain, building a deployment pipeline,
wiring a payment gateway, or migrating content off an existing host.
Do I need to supply hosting and a domain?
No. If you already own them I'll work with what's there and hand back the
configuration. If you don't, I'll set them up under your name with your payment
method so you keep ownership. Nothing gets registered inside my account.
How does payment work?
Fifty percent to start, fifty percent on launch. Larger web apps are split into
milestones tied to delivered features. Third-party costs — domain renewals, server
rent, paid fonts — always appear as line items at cost before anything is purchased.
How long does a project take?
A landing page is usually 4–7 days. A business site 2–3 weeks. A store or booking
system 3–5 weeks. A custom web app 5–9 weeks depending on integrations. The estimator
gives a live figure, and the timeline is confirmed in writing before work starts.
What if I want changes after launch?
Thirty days of fixes are included after launch — bugs, browser quirks, small copy
edits. After that it's either an hourly rate or a retainer, whichever suits you.
You're never locked in: the code, the server and every account are in your name.
Can you redesign something that already exists?
Yes, and it's a common request. I start with an audit of the current site — speed,
structure, what's ranking, what's broken — then propose either a rebuild or a targeted
fix list. Migrations run on staging first so there's no downtime.