Technology that earns a company money — not the kind that costs it.

For most company websites a framework is pure overhead. React or Next.js require a Node.js build pipeline, regular dependency updates (the npm ecosystem typically pulls in hundreds of transitive dependencies) and more expensive hosting with SSR or edge function support. The vanilla approach means: zero build process, no security patching of dependencies, direct control over every kilobyte sent to the browser, and deployment by simply uploading files over FTP/SFTP.

The result is measurable: a static HTML document with critical CSS inlined reaches First Contentful Paint under 0.8 s and a Lighthouse score of 95–100, while a typical React SPA starts with 150–300 kB of JavaScript before the first render. A framework makes sense for complex applications with shared state — for a presentation site or a shop with a few hundred products it is a negative investment.

I design solutions to run on ordinary shared hosting: Apache or Nginx, PHP 8.1+, optionally MySQL/MariaDB. In Slovakia that means running costs from roughly €3–6 per month (Websupport, Hostinger, Forpsi and similar), including a free Let's Encrypt SSL certificate. No VPS, no containerisation, no Node.js runtime and no CI/CD infrastructure needed.

Static assets (CSS, JS, images) are served with long cache lifetimes (Cache-Control: max-age=31536000, immutable) and versioned filenames, so repeat visits put practically no load on the server. A normal company website handles thousands of visits a day even on the cheapest plan.

The form uses layered protection without annoying CAPTCHAs: a honeypot field hidden from people but visible to bots; a timing token (submitted under three seconds after load = bot); a CSRF token bound to the PHP session; server-side validation and sanitisation of every input via filter_var() and htmlspecialchars(); and rate limiting per IP address. E-mail headers are assembled safely to prevent header injection attacks.

From a GDPR standpoint: the form collects only what is needed to reply (name, e-mail, message), processing rests on the legitimate interest of answering the enquiry, nothing is stored in third-party databases, and the site uses no tracking cookies by default — so it does not need a cookie banner either.

GEO (Generative Engine Optimization) means shaping content so that generative AI systems — ChatGPT, Perplexity, Claude, Google AI Overviews — can correctly understand, cite and recommend it. Technically that means: semantic HTML5 (article, section, a correct heading hierarchy), schema.org structured data in JSON-LD (ProfessionalService, FAQPage, Person), clear factual statements instead of marketing phrases, FAQ sections with complete self-contained answers, and an llms.txt file in the root directory giving AI crawlers a machine-readable summary of the site.

Entity consistency matters just as much: the same name, services and location across the website, the LinkedIn profile and company registers. AI models build a knowledge graph, and consistent data significantly raises the chance the system names you in answer to a query like "Loxone integrator Slovakia".

The core is the Loxone Miniserver, with peripherals connected either over the Tree bus (wired, deterministic communication — preferred for new builds and renovations) or wirelessly over Loxone Air (868 MHz, suitable for retrofits without touching the walls). A typical commercial project covers: lighting with presence sensors and daylight-based control, motorised shading automated by sun position, zoned HVAC control, access control and per-circuit energy metering.

The critical part is the logic configuration in Loxone Config — for example getting blind auto-calibration right, the priority between manual and automatic modes, or scenes for the building's different operating states. I also take over existing installations where the original integrator left the logic unfinished: configuration audit, documentation and optimisation are a service in their own right. In commercial buildings the payback typically comes from energy savings of 20–30 % on lighting and heating.

Sizing comes from measuring real load, not from catalogue recommendations: I profile CPU utilisation, the memory working set, storage IOPS and network throughput of the existing operation. For small and mid-sized companies a single- or dual-socket Dell EMC PowerEdge (R series for racks or T as a tower) with a RAID array on a hardware controller, ECC memory and redundant power supplies usually comes out best — and the form factor matters too (1U vs. 2U affects cooling, noise and expandability).

Cloud versus on-premise is not ideology, it is arithmetic: with stable, predictable load an owned server often works out at a third to a half of the cost of equivalent cloud capacity over three years, and the data stays physically in the company. Cloud makes sense with fluctuating load, geographic distribution, or when there is nowhere safe to put a server. For most clients I propose a hybrid: critical systems locally, backups and peripheral services in the cloud.

Core Web Vitals are the three metrics Google uses as a ranking factor: LCP (Largest Contentful Paint, target under 2.5 s), INP (Interaction to Next Paint, under 200 ms) and CLS (Cumulative Layout Shift, under 0.1). I hit them systematically: critical CSS inlined in the head, fonts with font-display: swap and preconnect, images in modern formats (WebP/AVIF) with explicit dimensions against layout shift, lazy loading below the fold, JavaScript with the defer attribute and no render-blocking resources.

Because I do not use frameworks, the main source of poor INP — hydration and long JS tasks — simply does not exist. The resulting sites routinely land at Lighthouse 95+ on mobile, a range most builder platforms (Wix, Webflow with plugins, an overloaded WordPress) never reach.

Yes, that is a normal part of the work. With websites I start with a technical audit: code analysis, security risks (outdated PHP versions, unpatched plugins, SQL injection vectors), performance and SEO status. The output is a report with prioritised recommendations — sometimes repair is worth it, sometimes rebuilding is cheaper, and I will tell you straight, with the numbers.

With Loxone installations the usual problem is undocumented configuration: I take over the Loxone Config project, document the existing logic, fix the problem blocks (badly set shading auto-calibration, priority conflicts or missing failure handling are common) and hand over complete documentation, so you are never again dependent on a single supplier.

Custom presentation website: 2–4 weeks from design approval. Online shop: 4–8 weeks depending on payment and stock integration. Loxone project for a commercial building: 1–2 weeks for the design, delivery according to construction readiness. Server installation including migration: typically within 2 weeks.

The pricing model is a fixed price for a clearly defined scope — not an open-ended hourly rate. Every quote also includes an estimate of running costs over three years (hosting, licences, service), so you compare total cost of ownership rather than just the entry price. Service support after handover is optional, not mandatory — you get the documentation and the credentials, the solution is yours.

Yes. Web development, e-commerce, SEO/GEO optimisation and consulting run fully remote for clients across the EU — I work in Slovak, Czech and English. I also have experience with international e-commerce including regional specifics (currencies, VAT regimes, marketplace platforms).

Physical installations (Loxone, server infrastructure) I deliver primarily in Slovakia and the Czech Republic; larger EU projects by arrangement. Remote administration and support of existing installations is possible from anywhere — both Loxone Miniservers and servers are configured for secure remote access over VPN as standard.