Introduction

A studio's own website is both a marketing tool and a proof of its capability. A slow, dated, or difficult-to-update website can undermine trust before a conversation begins. Getozvea was conceived as a site that communicates quality while giving its owner control over everyday content changes.

Literature review and background research

Websites are important trust and decision-making touchpoints for small service businesses. A content management system separates editable content from presentation, allowing a non-technical owner to update a site without editing code.

General platforms such as WordPress provide breadth and a large ecosystem, but also introduce plugin maintenance, database configuration, and a wider security burden. Headless services offer flexibility but create external dependencies and possible subscription costs. Static sites are fast and simple, but often require a rebuild for each change.

For a single site with a small, stable set of content types, a bespoke backend and focused admin interface offered the best fit: control over the experience, no third-party subscription, and only the features the owner actually needs.

Research methodology and workflow

Development followed an iterative, incremental approach. The public visual design was established first, then the backend, dynamic content, and admin panel were built around a concrete layout rather than abstract assumptions.

Requirements analysis

System design and architecture

The system uses three cooperating parts: a public frontend, an administrative frontend, and a shared Node.js and Express backend. Both frontends communicate with the backend through a defined request-and-response interface, while the backend acts as the single source of truth for all editable content.

A file-based store was chosen because the content volume is modest and relationships are simple. It keeps deployment, backup, and recovery straightforward, while its limitation is explicit: concurrent multi-user editing would justify a proper database migration.

Interface and user experience

The public interface avoids interchangeable template patterns by using a deliberate palette, serif display type, geometric sans text, and a consistent rhythm of headings, supporting copy, and content grids. The admin interface prioritises clarity and predictable controls over visual flourish.

Implementation overview

The frontend keeps structure, styling, and content population separate. A page shell requests current content and fills predefined placeholders, building services and portfolio grids from the returned data rather than assuming a fixed number of entries.

Backend routes are grouped by responsibility: public reads, authenticated writes, uploads, authentication, and contact submissions. Focused modules centralise data access and authentication checks, making the system easier to test and change.

Testing and quality assurance

Deployment and operations

The system is designed to deploy as one unit to a host running a modern server-side JavaScript runtime. The critical hosting requirement is persistent file storage because content and uploaded images live on disk. Serverless or temporary filesystems require external storage before deployment.

Challenges, evaluation, risks, and conclusion

The main technical challenge was keeping the data model, backend routes, and frontend rendering synchronised as new fields were introduced. Treating the data structure as the authoritative definition and rechecking dependent features reduced regressions. Image uploads also needed to be persisted with the relevant entry rather than merely returning a file reference.

Design iteration revealed that familiar agency patterns could weaken the project's claim to distinctive design. The admin panel also became clearer after long, undifferentiated forms were split into focused content areas. Time was managed by keeping the scope narrow and deferring multi-language support, granular permissions, and advanced analytics.

Within its stated scope, the system met its objectives: it has a distinctive public interface, a working backend, authenticated content management, image handling, persistent contact submissions, and a documented testing approach. Its deliberate limitations are the single-admin model, file-based storage, and baseline rather than full professional security hardening.