A website that had grown by addition, rebuilt around one decision

My website had reached a familiar point: it could describe a wide range of work, but the relationship between those capabilities needed to become clearer. Web design, WordPress, SEO, hosting, maintenance, performance, and audits all had a place. Presenting them as a collection of available services made the visitor responsible for deciding how they fitted together.

The Fernando Kylas website rebuild began with a different question. What should someone understand about my work before choosing a service? The answer shaped the project: I help organisations identify the right problem and choose a proportionate way forward. The website needed to make that judgement visible.

This case study examines the version-three planning and prototype phase recorded in my 2026 project documents. It explains the reasoning behind that phase, not the current live sitemap or a completed launch. Later plans can differ. The intended benefits are not measured improvements in traffic, speed, or enquiries.

The situation: capability had become the organising principle

The earlier website presentation described web design, SEO, and hosting, with separate routes for subscriptions, maintenance, managed hosting, design, SEO, and audits. Each represented work I could provide. The difficulty was how that presentation related to the broader consulting practice I wanted the website to explain.

A visitor could recognise an individual service without understanding whether it was the appropriate starting point. Someone experiencing poor visibility might choose SEO immediately, even if the website’s content structure or proposition needed attention first. Someone asking for a redesign might need a diagnosis before committing to replacement.

The issue was therefore larger than a crowded menu. The structure described what was available more clearly than how a sensible decision should be made. Adding another explanation or feature could increase the amount of information while leaving that basic responsibility with the visitor.

The diagnosis: the website needed a hierarchy of judgement

The archived consultancy experience blueprint records a clear direction: position the practice as a digital impact consultancy, with implementation capabilities supporting that wider role. It places diagnosis before planning where the problem is unclear, and implementation where the required work is reasonably understood. Ongoing care supports the system afterwards.

That sequence gave the rebuild a practical test. Could the website help someone recognise their situation and understand an appropriate next step? The answer needed to be visible in the architecture and copy, rather than relying on the visitor to infer it from a title such as consultant.

This also clarified what the project should preserve. Technical expertise remained important. WordPress, UX, SEO, performance, and care were still part of the work. The change concerned how those capabilities were organised and explained so that they supported a decision instead of competing for equal attention.

The central decision: organise around recognisable needs

The project record documents an August 2026 decision to organise that phase around three solution ranges: WordPress websites, SEO and visibility, and website audits. These provide recognisable entry points for different situations while allowing the underlying work to remain appropriately connected.

WordPress websites covers needs such as a new website, a substantial redesign, migration, rescue, or ecommerce. SEO and visibility addresses discovery and related technical or performance concerns. Website audits provides a starting point for organisations that can see symptoms but need evidence before deciding what to fix.

The three ranges do not imply that every problem falls neatly into a single discipline. Their purpose is to help a visitor begin the conversation. The detailed scope still needs judgement. A useful website can guide selection without pretending that a few clicks replace understanding the organisation.

The homepage has an argument to make

The homepage outline for that phase moved through a starting point, recognition of the problem, the service ranges, how the work moves, standards, proof, and an introduction to me. Insights and a final invitation complete the sequence. Those sections give the page a narrative role beyond displaying available work.

The order matters. Before asking someone to choose, the page needs to help them understand what kind of help is being offered. Before asking for trust, it needs to show the standards and evidence behind that help. The structure creates room for those questions rather than treating every section as interchangeable decoration.

This is also a useful constraint on content. A proposed homepage addition needs to contribute to the visitor’s understanding at that point. If it repeats information or introduces a separate priority, it should earn its place. The page can be substantial without becoming a storage area for everything the business wants to say.

The service ranges connect capabilities to outcomes

The WordPress range brings strategy, UX, design, implementation, SEO foundations, performance, training, and handover into the context of a website project. The visitor does not have to assemble those disciplines independently before understanding what a properly considered build involves.

The visibility range allows for focused work as well as situations where several discovery systems need attention together. Its planned content includes standards, boundaries, proof, and guidance before deciding. That structure makes room to explain both the value and the limits of the work.

The audit range has an especially important boundary: an audit should be useful on its own and should not commit the client to implementation. That preserves the value of diagnosis. The recommendation needs to stand on the evidence rather than depend on selling the project that might follow.

The enquiry journey supports a considered request

The documented prototype journey used four stages: explore, choose, complete the setup, and review and request. The first establishes the problem, scope, evidence, and indicative investment. The next helps visitors compare related routes by situation, then consider relevant supporting requirements before sending the request for personal review.

This is a deliberate commercial boundary. The planned journey is not a checkout or a binding quotation. Its role is to help someone express a considered request with useful context, while leaving space to verify the fit and scope through a conversation.

The start-a-project outline reflects that purpose through a selection summary, project questions, qualification routing, and clear explanations of what happens next. The desired outcome is a better starting conversation. Whether it achieves that consistently will need to be assessed through actual use rather than inferred from the presence of a form.

Supporting work appears where it has a reason

The recorded architecture treated Extras as support for a chosen route, rather than a fourth equal service range. Examples include managed WordPress care, analytics, conversion tracking, copy review, content architecture, strategy, and specialist integrations. Their relevance depends on the project and its existing foundations.

The recorded rules also stated that paid Extras are not preselected. Some require an audit, verified foundation, or technical qualification before inclusion. These details matter because a guided journey can otherwise become a mechanism for adding cost without helping the visitor understand necessity.

The principle is to close a defined gap. If ongoing care protects the project, explain that relationship. If a specialist integration requires further assessment, make that clear. Supporting work should strengthen the outcome through an understandable reason, with the final scope reviewed rather than assumed.

Work and insights carry different kinds of proof

The proposed Work section was organised around selected projects and outcomes. Its case study template includes the situation, diagnosis, decisions, work, outcome, and what the project demonstrates. That sequence creates space to explain the thinking behind a result instead of relying entirely on finished screenshots.

Insights has a different purpose: to make useful thinking available before someone becomes a client. Its article structure includes context, an answer, guidance, practical next steps, related reading, and an invitation. This supports a body of content that can help readers make progress independently.

Keeping those roles distinct makes the website more coherent. A case study should document a particular project. An article can explore a broader principle, such as why website problems often begin with decisions. Together they can show both how I think and how that thinking is applied.

The build process tests direction before implementation hardens

The local project decision record documents an HTML-first workflow before WordPress implementation, with content and SEO planning, prototype builds, browser review, and design-system work. That sequence provides a way to assess the page experience before every decision becomes tied to the final publishing environment.

The archived planning and decision records also show the need to preserve narrative intent and approved components during review. These are useful observations because a rebuild can lose coherence through repeated small changes, even when the original direction was strong. A clear brief does not automatically guarantee a consistent finished experience.

For this project, the process makes the importance of decision records visible. The purpose of a page, its intended visitor thought, and its next action need to survive implementation and review. The lesson is applicable beyond a particular tool: preserve the reasoning that makes the design appropriate.

Launch scope needs the same restraint as the interface

For this phase, a coherent core website was the useful launch principle, rather than a complete but thin service library. Later ideas needed separation from the positioning, useful content, enquiry route, and technical foundations required for a meaningful release. That prevents the sitemap from becoming a demand to publish everything immediately.

A page deserves to launch when it has a clear job and enough substance to perform it. Its presence in a plan is not sufficient. This is particularly relevant to a consultancy website, where a weak page can obscure the standard of work more easily than an intentionally deferred topic.

The same restraint applies to functionality. The documented consultancy journey excluded a checkout for buying the consultancy’s work. The enquiry journey is designed around assessment and discussion. Keeping that boundary clear avoids building operational complexity that does not support the intended relationship.

What has changed, and what still needs evidence

The documented change is an architectural one: that phase connected capabilities through three service ranges, a guided request process, and distinct roles for proof and educational content. The organising question moved towards what the visitor needs to understand and decide.

The intended benefits are clearer self-selection, better project context, and a stronger connection between the website and the consulting practice. Those are objectives, not measured outcomes in this case study. They should be tested through comprehension checks, enquiry quality, journey completion, and feedback once the experience is in use.

Performance and maintainability deserve their own evidence too. A calmer sitemap does not prove a smaller download or faster interaction. The principles in a lighter site is a faster site is a cheaper site explain why the technical and operating results should be assessed separately from the strategic direction.

The lesson is to organise the decision before the pages

The useful shift in my rebuild was deciding what the website should help someone do. From there, the service ranges, content sequence, supporting work, and enquiry route had a shared purpose. That does not eliminate detailed design decisions, but it gives them a meaningful basis.

If your website has grown through additions, start by examining the choice it asks visitors to make. Do they have enough information to make it, and does the structure guide them towards an appropriate starting point? The answer may reveal a more important change than another feature or visual refresh.

The case also shows why a rebuild record needs a date and a defined boundary. A planning decision can be useful without remaining the final architecture forever. Preserve the reason for it, assess later changes against the actual business need, and measure the resulting experience separately. That is more instructive than presenting one sitemap as a permanent answer.