Website, Portal and App Development
Websites, portals and mobile apps built to render server-side, so search engines and AI crawlers can read every word. Structure is enforced by the template rather than by editorial discipline.
Built to be readable by machines
Every template gets a heading pattern, an answer-block pattern and structured data that matches the visible text. Client-only rendering is treated as a decision with a visibility cost, made explicitly rather than inherited from a framework default.
Portals start with permissions
Three decisions come before any interface is designed: which user roles exist, what each may see and do, and where each field’s system of record lives. Every portal we have been called in to rescue had a screen design and no agreed answer to those questions.
Handover to your editors
Editors should not be able to break the structure by publishing. Patterns live in the template, QA gates run at build, and the documentation explains what to do rather than what we built.
Get the readiness checklist for this work
Twelve questions we ask before quoting. Answer them yourself and you will know whether you are ready to buy.
Key points
- Server-side rendering is the default, not an upgrade.
- Structure is enforced by templates, not by editor discipline.
- Portal permission models are signed off before design starts.
- Platform choice follows who edits and what must integrate.
- Load behaviour is tested against a peak you name.
Common situations, and the service that fits
The questions that determine scope
| Question | If the answer is yes | If the answer is no |
|---|---|---|
| Must the content be found and quoted? | Server-side rendering per route | Client rendering is fine |
| Can you name every user role and its permissions? | Portal design can begin | Start with the permission matrix |
| Does it need device access or offline working? | Build an app | Build a responsive web application |
| Is your pricing customer-specific or contract-based? | Platform plus extensions, or custom | A standard platform will fit |
| Is your product data consistent today? | Build can proceed | Scope data remediation first |
Common questions
Will a new site actually generate more enquiries?
It will if the enquiry path is designed and measured, which is why tracking is wired before launch rather than after. We report on qualified enquiries, and we will tell you when the constraint is your offer rather than your site.
Can you rebuild without losing our search positions?
Yes, with a URL map, redirect plan and a dated pre-launch baseline. Most traffic losses at relaunch come from unmapped URLs and removed content, both of which are preventable.
Do you maintain the site afterwards?
Yes, as managed support covering updates, monitoring, backups and a defined change allowance.
Marked up as FAQPage structured data, matching the visible text exactly.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.