A website you won’t have to rebuild every two years.

It depends on scope, which is why no single figure fits every website. What weighs most is how many pages and functions it has, what must be connected to other systems, the level of performance and accessibility required and who will maintain the content afterwards. We don’t publish a figure because a figure without a scope is not information: what is in is first agreed in writing and the fee is worked out from that. To compare two proposals, the guide how much custom software costs explains the method, which also applies to a website.

It lays down a sound technical base, but no one can guarantee rankings. That base includes clear structure, speed, crawlable pages, structured data and measurement so you know which pages bring enquiries. How far it climbs also depends on content, competition and time, and anyone who promises a specific position isn’t telling you everything.

We need one person who can decide and answer questions about the business, and access to the systems involved. It doesn’t take much time, but it has to be steady: that is what stops us building on assumptions.

No, and confusing the two is expensive. A website communicates and attracts: its job is for someone to find you, understand what you do and get in touch. A digital product is a tool that gets used —by your team or by your customers— and supports a business process. They are defined differently, built differently and maintained differently, even if they look alike on the outside and share technology underneath.

Yes. We are a studio based in Lanzarote and we work with businesses in the islands and across Spain, remotely with the same method. Wherever you are, scope, deliverable and price are agreed in writing before we start.

Yes. Before touching anything, we take stock of what already works: which pages receive visits, at which URLs and which links point to them. Whatever moves to a new URL is redirected, and whatever ranks is kept. What we won’t promise is that your rankings will rise after the change: that depends on far more than the website, and anyone who guarantees it either doesn’t know this area or isn’t telling you the whole story.

Yes, and it is usually the cheaper way to do it. We define a first version around what really has to be there on day one, and write down what comes next and why. It is the same reason the scope is closed before we start: a website that starts small and planned grows much better than one that starts big and is cut back midway through the project.

Your team can. The handover includes the repository, the technical and deployment documentation and the relevant access, so that another team can carry on without depending on us. Which parts of the content stay editable, and how, is decided in the definition phase, because it shapes how the site is built. And if you would rather not deal with it, a maintenance agreement is available.

When the brief is simple and standard, an off-the-shelf tool can be the right answer, and we will say so. It falls short in three places: when the website has to connect to what you already have, when performance and accessibility have to be measured rather than assumed, and when leaving that tool later costs more than avoiding it would have. We build with standard technology so that last cost doesn’t exist.