Frequently asked questions about web development

Because price follows scope, and scope emerges from the conversation. A five-page site and a five-page site with a catalogue, user accounts and three languages are different projects described in identical words. Ballpark figures for standard packages are on the pricing page; the exact number appears once the scope is clear, and doesn't move afterwards without your agreement.

Three things: the number of distinct page types (types, not pages — forty product cards are built once), the number of languages, and whether there are integrations with external systems. Design matters less than people expect; integrating with someone else's API matters more.

Yes, work starts with a deposit and the rest is paid by stage. That's normal in both directions: you don't pay in full for work that hasn't started, and the developer doesn't build the whole project hoping to be paid at the end.

Yes. It fixes scope, timelines, price and how the work is accepted. It states separately that rights to the result transfer to you on full payment — worth checking in any development contract, not only this one.

Then it's more honest to narrow the scope than to cheapen the execution. What works: launch a first version with whatever the site can't function without, and build outwards as budget appears. What doesn't: build everything at once, badly — that site usually gets rebuilt from scratch within a year.

An understanding of who your customer is and what they should do on the site. Everything else — structure, copy, design — is built around that. A logo, photos and service descriptions speed things up, but not having them doesn't block the start.

By default we draft the structure and the text, and you check the factual parts — prices, terms, names. Copy about your business written without your input always comes out generic, which is why a round or two of substantive revisions is built into the process.

Your own photography is best — it's what separates the site from a dozen similar ones. If there isn't any, stock images are used at launch and a shoot is planned separately. There's an article in the blog on briefing a photo shoot.

Revisions within the agreed scope aren't capped — the point is that you're satisfied with the result. The limit is different: changes that alter the scope itself (a new section, another language, different catalogue logic) are discussed separately, because that's an addition rather than a revision.

Design is signed off before development starts, on mockups rather than on a finished site. Reworking a concept at that stage is cheap; reworking it on a built site is expensive, which is exactly why sign-off comes first.

Usually a few hours in total: an initial conversation, sign-off on structure and design, checking the copy, and acceptance. Most of it falls in the first week; after that we mainly need answers to specific questions.

Yours. This matters on principle: a domain registered to a contractor makes you hostage to that relationship. If the domain is already in someone else's name, transfer it before launch rather than after.

You do, directly to the provider. It's cheaper, and more importantly you don't lose the site if the working relationship ends. Helping you choose and configure it is part of the job; paying on your behalf isn't.

Source code, access to the server, database, admin panel and any connected services, plus documentation for running the site. The project has to work fully without us — that's verified at acceptance.

Nothing breaks. The site runs on your domain and your hosting, you hold the access, you hold the code — any developer can pick it up. The stack is chosen to be a common one for exactly this reason.

As many as clients actually contact you in, plus one to grow into. An extra language isn't a menu item — it's a full set of copy that has to be maintained, and a half-empty version does more harm than not having it.

Yes, if multilingual support is designed in from the start — then it's translating content rather than rebuilding the site. If the site was built single-language, adding a second one usually means restructuring every page URL, which is separate work.

Yes. Several projects in the portfolio were built for businesses in China, Tajikistan and international markets. The work is fully remote, so a client's location doesn't change the process.

No. Discussion, design sign-off, acceptance and handover all happen online. For web development that's been standard for years, and location doesn't affect the price.

You do, through the admin panel, without contacting a developer. Being able to change text, products and news yourself is built in by default; a site that can't be updated without emailing a contractor goes stale within six months.

Yes, it's part of handover: a walk-through of the admin panel using your real tasks, plus short documentation you can come back to. No separate course is needed — the interface is designed for someone who isn't a developer.

Defects in the delivered work are fixed at no extra charge — that's a contractual obligation, not a support plan. New features and enhancements are separate work.

Ongoing support is a separate service: updates, backups, monitoring and changes as needed. It isn't mandatory, but a site that never gets updated becomes vulnerable over time, so it's worth deciding on deliberately rather than by default.

No, and it's important to know that before starting. Development includes SEO preparation — structure, metadata, structured data, speed, correct page URLs. Promotion itself is continuous work after launch, and a separate service.