From Portfolio Website to Intelligent Business Platform

A website built to learn—and to prove

I did not begin this project with a large team or a finished product specification. I began with a practical need: I wanted one place where my experience in development, logistics, marketing and international business could be understood as a complete story.

A conventional CV could summarise that story, but it could not show the details behind it. So I started building. HTML gave the information structure, CSS created a responsive visual system, and JavaScript added navigation, interactions and reusable behaviour. Each improvement taught me something, and each real limitation became the next development task.

The website became both my portfolio and the evidence of how I approach a complex, evolving project.

What the platform already does

The public website has grown far beyond a digital business card. It now combines several connected products:

• A multilingual portfolio that makes my experience accessible to international readers.
• An online CV supported by detailed pages for companies, responsibilities and documented projects.
• A concise downloadable PDF CV with direct links to deeper evidence online.
• A blog for ideas and case studies, plus DevNotes that document my continued learning.
• Structured metadata, international SEO and sitemaps designed for discovery across different search markets.
• Node.js scripts for generation, translation workflows, consistency checks, PDF production and routine audits.

Static pages keep the public layer fast and resilient. Automation behind those pages reduces repetitive work and helps maintain consistency as the number of languages and documents grows.

The next step: from publishing to useful action

The future version will run on a Plesk-managed server. It will connect the website, a controlled server mailbox and Codex-assisted workflows. The objective is not to create a machine that sends as many messages as possible. It is to build a system that can identify a small number of genuinely relevant opportunities and prepare better communication.

Codex can assist with development, analysis and the preparation of workflows. The application itself must remain observable and controlled: clear permissions, explicit rules, logs, limits and human oversight are part of the architecture—not additions for later.

How an opportunity becomes a conversation

Imagine the system identifies a vacancy that requires international logistics experience, multilingual communication and web-development knowledge. Instead of sending a generic application, it can build a relevance map: which parts of my CV match, which portfolio pages demonstrate that experience and which questions still require my judgement.

For business development, the workflow is similar. A potential customer is considered only when it matches clearly defined services and market criteria. The system prepares context and a possible introduction; it does not treat every email address as permission to contact someone.

The value is not maximum automation. The value is better research, better decisions and more relevant human communication.

Initially, external messages should enter an approval queue. Later, carefully tested low-risk workflows may become more automated, but only when consent, regional requirements, opt-out handling, sending limits and quality controls are properly implemented.

Engineering principles for the future server

A credible platform needs more than an intelligent model and mailbox access. I want the next stage to be built around several non-negotiable principles:

• Least privilege: every service receives only the access it needs.
• Human control: important messages remain reviewable before they leave the server.
• Traceability: searches, decisions, drafts and sends create useful audit records.
• Quality before volume: relevance and personalisation matter more than the number of contacts.
• Privacy and compliance: personal data, retention, consent and opt-outs are designed into the workflow.
• Operational safety: rate limits, duplicate prevention, monitoring, backups and recovery are included from the start.
• Separation of environments: development and testing cannot accidentally trigger production communication.

The exact deployment architecture will evolve as the Plesk server, mailbox integration and production workflows are implemented. I will update this article with diagrams, technical decisions and measured results as those components move from plan to working system.

Why I am sharing this before it is finished

I want future partners and developers to see more than the final interface. Good collaboration begins with a shared understanding of the problem, the intended value and the constraints that protect users.

This project connects several areas of my experience: software development, multilingual communication, logistics, marketing and practical business operations. I know the destination, but I also value the engineering discussion required to reach it—architecture choices, security boundaries, responsible automation and the points where human judgement must remain central.

The first version of this website showed that I could build and keep improving a real product. The next version is about building a platform that can act on information responsibly.