Making a creative brief concrete enough to price.

Make the commercial scope understandable

Adfyo is CONVRO’s creative-production and advertising business. Its website has to explain several related services without collapsing them into a vague promise: preparing creative material, adapting it for different formats and managing advertising after the material exists.

The useful product interaction is the estimate builder. A visitor can change the scope and see an itemized consequence, rather than starting with a contact form that leaves both parties uncertain about what is being requested. For a founder, this connects web engineering to the practical work of making an offer understandable.

I see this as a useful contrast to Reesponder and Cheapwork. An interactive estimate does not automatically require a continuously running application server. Here, the build can produce the pages while the browser handles changes to the scope.

Next.js at build time, React in the browser

The inspected release uses Next.js, React and TypeScript with static export. Nginx serves the generated HTML and assets from a versioned release. Dedicated pages cover the creative offer, advertising, pricing, contact and the way the business works.

Static export does not mean that every interaction is static. React can maintain calculator state and update the visible estimate in the browser, while the initial page remains a deployable document. This keeps the serving layer small and gives the release a concrete output that can be inspected before it becomes the public root.

The trade-off is clear: changing build-time content requires another build. Features that need private credentials, trusted pricing enforcement or persistent customer records would need an appropriate server-side boundary. Those requirements should not be smuggled into client code simply because the rest of the site is static.

Turn a service list into a manipulable model

The public calculator exposes variables people can reason about: the number and length of edited videos, additional opening hooks, export formats, captions and production options. Advertising has its own configuration, including channels, reporting and the platform budget.

Numeric inputs complement sliders. A slider is useful for exploration, while an exact input lets a visitor express a known quantity. The visible receipt updates the line items, so the number is connected to the decisions that produced it.

I want the estimate to keep three things separate: one-off work, recurring management and money paid to advertising platforms. Combining them into one unexplained total would make the interface look simpler while making the commercial meaning less clear. The receipt preserves those distinctions and gives the first month its own context.

The public flow also offers a shareable estimate and a route into contact with the selected scope. That reduces re-entry and keeps the conversation anchored to an editable configuration. An estimate remains an estimate; browser state is not a signed commercial agreement.

Media, reading and interaction compete for space

A creative business needs visual material, but large media can easily overwhelm navigation and explanation. The site uses separate routes and components for the offer, galleries and estimate experience. Each has a different reading and interaction task.

The calculator benefits from a parallel desktop composition: controls beside the itemized receipt. On a phone, the same content needs an intentional reading order and controls large enough to operate accurately. Merely scaling down the desktop would make both the inputs and their consequences harder to understand.

The portfolio screenshot is captured from the real public calculator. It contains an example configuration, not a fabricated customer result, an endorsement or evidence of revenue. Its role is to show the implemented interaction.

What requires verification before a release

For this architecture, a successful framework build is necessary but insufficient. A release needs usable static routes, correct asset paths, working internal navigation and a calculator that remains understandable at minimum, maximum and empty-input states. A copied estimate link should restore a coherent scope rather than a misleading partial total.

The deployed source and public calculator were inspected for this case study. Historical accessibility scores, performance scores and conversion improvements were not supplied and are not claimed. A future change to the calculator should be tested against its business rules as well as its visual layout.

Static hosting reduces the public application’s server execution surface. It does not eliminate browser dependency risk, unsafe external destinations or the need to validate data at any downstream service. Client-side estimates must not become trusted billing input without independent server-side verification.

Deployment and maintenance

The live deployment uses versioned releases containing a generated output directory. The public root selects one of those releases. That separates the production serving path from the build workspace and supports reviewing a candidate before switching it into use.

Framework assets can be cached independently of HTML, but a release still needs to keep references consistent. A page from one build must not point at removed assets from another. Retention and cleanup policies therefore belong in deployment design, particularly on a server hosting several products.

The useful lesson is to keep the architecture proportionate. An interactive, visually rich website can still have a small serving model. Complexity should be added when a product requirement needs it, with a clear explanation of who owns the new state and how it is maintained.

Outcome

The public result is a website that connects the creative offer to a concrete scope-building interaction. It demonstrates product-oriented frontend work: modeling a decision, presenting its consequences and keeping the path into a business conversation understandable.

Alongside the AI and messaging projects, Adfyo shows another part of my work at CONVRO: choosing an appropriate technical foundation for a commercial product, and caring about the interface people actually have to use.