Client Web Delivery

Two Very Different First Contracts

Stack: HTML · CSS · JavaScript · PHP · Next.js · TypeScript · Strapi · Resend · Docker · Dokploy

New Art Vanguard and Arsenale Moto were my first paid client projects, completed during my final year of high school.

At New Art Vanguard, I joined two other developers on an established HTML, CSS, JavaScript, and PHP website. My work had to fit the existing design and codebase without disrupting production.

Arsenale Moto placed me in the opposite position. As the sole developer, I had to clarify the requirements, choose the architecture, build the public site and CMS, connect the customer workflow, configure deployment, and prepare the client to operate it.

Together, the contracts taught me that delivery is broader than implementation. The code must fit the team that maintains it and the people who use it after launch.

Working Inside an Existing Site

My New Art Vanguard assignment covered content corrections, responsive improvements, and new pages that had to preserve an established visual identity. Within the three-person team, I updated more than five existing pages and delivered three new ones, including the animated coming-soon experience shown in the gallery.

The quickest technical solution was not always the right client solution. Some older sections were difficult to adapt, but a broad rewrite would have expanded the scope and introduced unnecessary risk. I reused stable patterns, isolated my changes, and rebuilt individual responsive sections only where the existing implementation prevented the requested result.

I also helped containerize local development and release preparation with Docker. The measured workflow dropped from roughly 20 minutes to 15, but reproducibility was the more useful outcome: setup relied less on one developer's machine, and the team had a shared path for running and preparing the application.

This project gave me an early lesson in restraint. Finding code I would write differently today is not, by itself, a business reason to replace it.

Turning Listings Into Content

Arsenale Moto primarily promoted motorcycles through social media. Building equivalent website pages by hand would have made every new listing a development request, so I shaped the project around one requirement: staff should be able to manage routine content without editing code.

I built six public pages with Next.js and TypeScript and used Strapi for the content layer. A shared motorcycle model supplies pricing, specifications, images, and listing copy through more than ten editable fields. The frontend renders every motorcycle from that model rather than maintaining a separate implementation for each vehicle.

The production catalogue grew beyond 30 listings. An authorized employee can complete the fields and publish a consistent page in roughly one minute. This turned motorcycle publishing into an everyday content task instead of an ongoing dependency on me.

Permissions From Conversations

The client did not begin with a formal content model or permission matrix. I had to learn which employees handled each type of information, which updates were routine, and which actions should remain restricted.

I worked from the activity outward:

staff task
    -> required content
    -> allowed actions
    -> CMS role and permissions

Those conversations produced ten staff roles with different levels of CMS access. The number reflects the client's operating responsibilities rather than ten versions of the same user. Each role exposes only the content and actions needed for its work.

Starting with people rather than fields made the structure easier to explain during handoff. Employees saw permissions in terms of tasks they already understood, while the CMS enforced the corresponding technical boundaries.

This was the first time I watched a data and access model emerge directly from requirements discovery rather than from a predefined school assignment.

A Form With Business Consequences

The website also needed to collect motorcycle valuation requests. I implemented the public form and a server-side delivery flow through Resend. Submissions are validated before delivery, with anti-spam controls, authenticated sending domains, and branded email templates.

The workflow now handles approximately 10–20 valuation requests per day. Delivery logic and credentials remain on the server; the browser only submits the customer's input.

That volume changed how I viewed a familiar feature. A broken classroom contact form is inconvenient. In production, a failed valuation request can mean a customer lead never reaches the business. Validation, email authentication, failure behavior, and testing were therefore part of the feature—not finishing touches.

Deployment Had to Be Operable

For Arsenale Moto, I configured the VPS, Docker services, domains, HTTPS, environment variables, backups, and health checks. GitHub changes move through a repeatable Dokploy deployment path rather than an undocumented sequence of server commands.

Launch was not complete when the site first returned a successful response. Staff still needed to know how to publish motorcycles, incoming valuation requests had to reach the right place, and another deployment needed a documented route.

The handoff therefore included CMS training, deployment instructions, credential guidance, and documentation for the client's regular workflows. I also provided post-launch support while those workflows moved from explanation to daily use.

Owning the complete project made the gaps visible: if permissions, recovery, or operator guidance were missing, there was no separate team waiting to supply them.

Delivered Results

Across the two contracts, I delivered:

• more than five updated pages and three new responsive pages for New Art Vanguard;
• an animated page integrated into the client's existing visual system;
• a repeatable Docker workflow for team development and release preparation;
• six public Arsenale Moto pages and more than 30 CMS-managed listings;
• a shared motorcycle model with over ten editable fields;
• task-based permissions across ten staff roles;
• an approximately one-minute publishing workflow;
• a server-side valuation flow handling around 10–20 daily requests;
• GitHub-to-Dokploy deployment on a configured VPS;
• training, operational documentation, credential guidance, and post-launch support.

The repositories are private client property, so the live products and the outcomes above are the public evidence for this work.

What Client Work Changed

School projects usually begin with a specification. Client requests arrive in the language of the business: what takes too long, what customers should see, who needs access, and what must happen after a form is submitted.

I learned that requirements are part of the work, not a document I can always expect to receive. Conversations need to become pages, roles, workflows, acceptance criteria, and explicit assumptions before too much code depends on them.

The two projects also taught opposite forms of responsibility. New Art Vanguard required judgment about changing only what served the agreed work. Arsenale Moto required me to notice and resolve decisions that no other developer owned.

The CMS remains the result I value most. Its success is not that I used Strapi; it is that employees can publish motorcycles consistently without waiting for a code change.

What I Would Improve

For future contracts, I would create one short requirements record before implementation: agreed pages, editable content, roles, workflows, acceptance criteria, open questions, and explicit exclusions. Most decisions here were resolved correctly through messages and meetings, but a shared reference would expose assumptions earlier and make scope changes easier to discuss.

I would also write the handoff alongside the system rather than assembling most of it near launch. If somebody else must operate the product, their documentation belongs in the delivery plan from the beginning.

Links

• New Art Vanguard
• Arsenale Moto