Questions, answered properly

We build, grow and automate digital products. In practice that is four things: website development, SEO, app development and AI automation.

Most projects start with one of them and grow into a second. A new website often leads into search work; an internal tool often leads into automating the process around it.

Businesses that have outgrown their current setup. That usually looks like one of a few situations: a website that no longer reflects what the company does, a manual process that has become a bottleneck, a spreadsheet doing a job that needs real software, or a site that gets no organic traffic and nobody knows why.

We work with companies internationally and run projects remotely. Size matters less than clarity - a founder who knows the problem is easier to help than a large team that has not agreed on one.

You send us a description of what you are trying to do. It does not need to be a formal brief - a few paragraphs is enough to tell whether we are a fit.

From there: a call to understand the problem, then a written proposal with scope, sequence, timeline and cost. Nothing is billed before that proposal is agreed. If we do not think we are the right people for it, we will say so and point you somewhere better.

Two models, depending on the work. Defined projects - a website, an application, an automation build - are quoted as a fixed price against a written scope, so you know the number before it starts. Ongoing work like SEO or continued development runs as a monthly retainer.

Cost is driven by scope, integration complexity and how much is genuinely custom versus configured. We give you a real number after a scoping conversation, not a range on a pricing page that changes once we understand the project.

Yes, and often that is the better option. Before proposing a rebuild we look at what is actually wrong. Sometimes the answer is a redesign; sometimes it is a performance pass, an information architecture fix, or a content problem that a new build would not solve.

If we do inherit a codebase, we start with a review so we can tell you honestly whether it is worth extending or replacing.

You do. Code, designs, content and accounts belong to you, and we hand over repository access, documentation and any credentials created during the project. We do not hold hosting or domains hostage as a retention strategy.

A focused marketing site is usually a few weeks; a larger site with custom functionality, integrations or a content migration takes longer. The variable that moves timelines most is not development - it is content and decisions.

We give you a schedule with dates in the proposal, and we tell you which parts depend on you so nothing stalls silently.

Yes. A redesign is a good fit when the structure still works but the design, performance or content no longer does. We keep what is working - particularly pages that already earn search traffic - and rebuild around them.

If URLs change we map redirects before launch, so existing rankings and links are not thrown away. More on that in website development.

Yes. Booking flows, calculators, gated content, member areas, multi-step forms, integrations with a CRM or payment provider. If the requirement is closer to an application than a website, we would scope it as app development instead, and say so.

The technical foundations are, always: crawlable structure, clean URLs, correct heading hierarchy, metadata, structured data, fast loading, mobile rendering and an XML sitemap. That is part of building a website properly, not an upsell.

What is separate is ongoing search work - keyword research, content production, link acquisition and continuous optimisation. That is SEO as a service, and it runs after launch.

Yes, where that makes sense. We set up a CMS for the content that changes regularly and leave the structural parts in code, which keeps the site fast and stops the design drifting over time. Handover includes a walkthrough of how to edit, add and publish.

We deploy to modern static or edge hosting, which is fast and inexpensive to run. You own the accounts. After launch you can maintain the site yourself or keep us on a support arrangement for updates, monitoring and ongoing improvements.

SEO is being found in a list of results - Google, Bing, the traditional ten blue links. GEO, generative engine optimisation, is being cited inside an AI-generated answer, in ChatGPT, Gemini, Claude, Perplexity or Google's AI overviews. AIO, AI optimisation, is the wider work underneath both: making your content, entities and structured data legible to machines rather than only to people.

They are not three separate disciplines with three separate budgets. Most of the underlying work overlaps - clean structure, clear answers, credible sourcing. What changes is that you are now writing for a system that summarises you as well as one that links to you. More on how we approach all three.

No one can promise that, and you should be wary of anyone who does. These systems do not publish their selection criteria, they change frequently, and the same question can return different sources on different days.

What we can do is make you a plausible source: content that answers a specific question directly, factual claims that are easy to verify, structured data that identifies who you are and what you do, and a site that AI crawlers can actually read. That is the same work that makes you rank - it just has a second beneficiary.

No, and the framing is wrong. AI assistants are largely built on top of the same web index and the same signals. A page that search engines cannot crawl is also a page an AI system cannot cite.

What has changed is the pay-off for some kinds of content. Pages that existed only to capture a simple factual query lose traffic, because the assistant answers it without a click. Pages that offer something a summary cannot replace - real judgement, specific experience, actual data - matter more, not less.

Honestly: less precisely than traditional SEO, and we will not pretend otherwise. There is no equivalent of Search Console for AI assistants. Nobody hands you impressions and clicks.

What is measurable: whether you get cited when the question is asked, tracked by running a defined set of prompts on a schedule and recording which sources appear; referral traffic from assistants that pass one; and the classic signals that feed the same systems. We report what we actually observed, not an invented visibility score.

Technical fixes can show up in weeks - crawl errors, indexing problems, page speed and structural issues often resolve quickly once corrected. Competitive rankings for commercial terms take considerably longer, usually several months of consistent work.

Anyone promising fast rankings on competitive terms is either lucky or not telling you the whole story. We would rather set the expectation correctly at the start.

No, and neither can anyone else. Nobody controls Google's ranking systems, and results depend on your competition, your domain's history and the market you are in.

What we can commit to is the work: a technically sound site, pages that match real search intent, a sensible internal link structure, and clear reporting on what moved and what did not.

A crawl of the site to find indexing, structure and performance problems; a review of how pages map to actual search intent; an internal linking analysis; a look at structured data and metadata; and a competitive comparison for the terms that matter commercially.

You get a prioritised list - what to fix first, what it should improve, and roughly what each item costs to do.

Both. A one-off audit and fix cycle makes sense when the site has clear technical problems. Ongoing work makes sense when you are competing for terms where content and authority need to compound over time.

We will tell you which one your situation actually calls for.

Yes. Most SEO work we do is on existing sites. If the platform itself is the obstacle - for example rendering that search engines cannot read, or a URL structure that cannot be changed - we will tell you, and quantify what a rebuild would actually be worth before recommending one.

What changed, what it affected, and what is next. Rankings for tracked terms, organic sessions and their trend, indexing status, Core Web Vitals, and conversions from organic where tracking allows. Reports state what we did - not just charts without context.

Yes. Multi-tenant architecture, authentication and roles, subscription billing, admin tooling and the customer-facing product itself.

For a new product we usually recommend narrowing the first release harder than feels comfortable - ship the core workflow, put it in front of real users, then expand. See app development.

Yes. CRMs, payment providers, accounting systems, email platforms, internal databases and legacy systems with an available API. Where no API exists, there is usually still a route - scheduled exports, webhooks, or a small service in front of the old system.

That is a large part of what we do. Operations dashboards, inventory and order tools, approval workflows, reporting interfaces, client portals. These rarely need to be beautiful, but they do need to be fast, accurate and hard to use incorrectly.

The usual trigger is a spreadsheet that several people now depend on and nobody trusts.

Start with what the user is doing and where. A web application is faster to build, works everywhere, and updates without an app store review - usually correct for tools people use at a desk. A mobile app earns its cost when you need the camera, offline use, push notifications, location or a home screen presence.

Plenty of products need a responsive web application and no mobile app at all.

Software is never finished. We hand over documentation and access, and most clients keep an arrangement for fixes, iteration and new features. If you have an in-house team, we make the handover clean so they can take it forward.

The realistic wins are unglamorous and repetitive: reading incoming documents and pulling out structured data, triaging and routing enquiries, qualifying and enriching leads, drafting first versions of routine replies, summarising long threads, and moving data between systems that do not talk to each other.

If a task has a clear input, a repeatable judgement and a defined output, it is a candidate. See AI automation.

Usually, yes. Most business software exposes an API or webhooks, and that is normally the integration point. Where a system is genuinely closed, we work around it - scheduled imports and exports, or a thin service that sits alongside it.

The goal is automation that runs inside your existing stack, not another tool your team has to remember to open.

For the right tasks, with the right design. We keep a human in the loop wherever output is customer-facing or hard to reverse, build in validation so failures surface loudly instead of silently, and log what the system did so you can audit it.

Where a deterministic rule works, we use a rule. Not every automation problem needs a language model, and pretending otherwise is how these projects fail.

Whichever is the right answer. If an off-the-shelf automation platform covers it, we will configure that - it is cheaper to build and easier for your team to change. Custom development is for cases where the logic, data handling or scale genuinely require it.

We are not incentivised to build something complicated when something simple would hold up.

We look at frequency, time per occurrence, error rate and how annoying the task is to the person doing it. Something that happens fifty times a day and takes four minutes is worth attention. Something that happens twice a month is usually not, no matter how tedious it feels.

We would rather talk you out of an automation that will not pay for itself than sell it to you.

It will, eventually - an API changes, a format shifts, an edge case appears. We build in monitoring and alerting so you find out from us or from the system, not from a customer. Failure modes are designed to stop and notify rather than continue producing wrong output.