Protected application structure
Public assets and the front controller live in public_html; PHP configuration, templates and logs live outside the public webroot.
BRAVACA LABS · WORKING INTERNAL BUILD
Working internal build
A lightweight PHP website system built for controlled growth.
This is a real Bravaca internal build: the production-oriented PHP foundation powering the Bravaca website. The purpose is to keep deployment simple on Hostinger while leaving room for proof, products, local sites and future content growth.
WORKING PROOF & NEXT ROUTES
Evidence before claims.
Real Bravaca build notes, documented Lab models and specific next-step engagements connected to this page.
Stateless form security
The enquiry form uses signed time-limited CSRF tokens, a honeypot, rate limiting and server-side validation without starting a session on every visitor request.
Canonical + security layer
Clean URL normalization, noindex handling, CSP, security headers, caching controls and structured-data support are part of the shared system.
01
Problem
Bravaca needs a global site that can grow into services, Labs, products, work, research and governed local-market sites without introducing a heavy CMS or exposing internal application files.
02
What was built
- Single PHP front controller for clean routing
- Private application/config layer outside public_html
- Reusable page-data and templates
- Responsive design system using the supplied Bravaca production assets
- Canonical redirects and consistent SEO metadata
- Organization, WebSite and breadcrumb structured data
- CSP and common browser security headers
- Stateless CSRF, rate limiting and SMTP-ready contact handling
- XML sitemap and robots controls
03
Why this architecture
For the current Bravaca site, a small PHP system keeps hosting requirements low, reduces dependency surface and makes individual pages easy to audit. It is not presented as the right architecture for every future product.
04
Current limitations
- SMTP credentials must be added privately on the real Hostinger account before enquiries can send.
- The final privacy notice still requires genuine legal/controller details.
- Client proof, testimonials and commercial product statuses must be added only when verified.
- Real-world Core Web Vitals and mail delivery must be verified after staging deployment.
EVIDENCE STANDARD
What this page does—and does not—claim.
Status is intentionally “Working internal build”. This page documents what is actually present in v0.3; it does not claim client results or performance measured on the production Hostinger server.
BRING US THE PROBLEM
You do not need to choose the service first.
Tell us what you are trying to improve. We will help define what should happen next.