Tecnodata SA

Tecnodata SA is an IT services and technology consulting company based in Chile, working with medium and large B2B clients in Chile and across Latin America. Its services include IT outsourcing, infrastructure, cloud solutions, cybersecurity, software development and technology consulting.

The website is a corporate presence and credibility channel. It presents the company, its services, the industries it works in and its areas of expertise, and it generates new business opportunities through contact requests. It is not a transactional site, so downtime would not cost transactions directly — it would cost a sales and credibility channel at the moment a prospective client is evaluating the company.

That shaped what the site had to be good at. It is read by people deciding whether a technology company is competent, and a site that is broken, slow or visibly neglected argues against its own owner.

By the end of the engagement the site spanned dozens of pages covering service areas, industries, company information and contact.

The project was a greenfield build. Nothing was inherited: no prior codebase, no existing implementation to extend. The starting point was a Figma design already approved by the client, and the brief was to implement it as a new WordPress site, deploy it, and keep it healthy in production.

Two things made that harder than a straight build.

The design was fixed before implementation began. It had been approved, so fidelity was a requirement rather than a preference. And it was not only complex static layouts — the design specified animations as well.

The client had to be able to edit the site afterwards. Tecnodata required that future content changes be as easy as possible for their own team to make. That requirement was set before any technical decision and it constrained all of them.

Those two demands pull in opposite directions. Faithful reproduction of a detailed design pushes toward hand-written code. Easy content editing pushes toward a page builder. The project's central engineering problem was resolving that tension without sacrificing either side — and then living with the resolution for years, which is the part that actually tested it.

I worked as a Frontend / WordPress Developer at NOVAZ Group, the agency contracted by Tecnodata, and I led the development team on this project.

I was responsible for the technical decisions:

• Choosing Elementor as the primary page builder
• Defining the WordPress implementation approach
• Selecting the plugins, against the project's specific requirements
• Establishing the frontend technical architecture

And for the work itself: implementing the frontend, building pages, ensuring responsive behaviour, taking on the implementation tasks that were technically hardest, participating in the production deployment, and maintaining and evolving the site afterwards.

The team. UI/UX designers produced the Figma designs. Project managers gathered requirements and handled client communication. Other developers were involved occasionally where features overlapped. I coordinated mainly with the project manager, with designers to clarify implementation details, and directly with Tecnodata's Product Owner for review, approval and technical trade-off discussions.

What I did not own. I did not own the design, the client relationship, or the infrastructure. The hosting account, DNS, SSL certificates and backup strategy belonged to NOVAZ Group or the client's infrastructure team. I had the access required to deploy and to perform the technical work the project needed on the server, without owning the hosting environment — and the PHP version the implementation had to support was specified by the client rather than chosen by me.

So the accurate description is application ownership rather than infrastructure ownership. I owned the WordPress application and its technical implementation, and I worked across the infrastructure boundary without controlling it.

The site was built on WordPress with Elementor as the primary page builder, on the stock Hello Elementor theme.

No child theme. I deliberately chose not to build one: the approved design required no theme-level customisation, and Elementor, Elementor Pro and Theme Builder covered what the project needed. Adding a child theme would have meant a bespoke layer to maintain and re-audit on every theme or builder update, for no capability the project was missing.

Global structures through Theme Builder. Elementor Theme Builder managed the site's global structures, including the header and footer.

Custom code where the design required it. Not every section of the approved design could be reproduced cleanly in Elementor alone, and the animations in particular needed more control than the builder gives. Rather than compromise the design or abandon the builder, I wrote HTML, CSS and JavaScript for those sections specifically.

That code lived primarily inside Elementor HTML widgets, and I never modified Elementor core files. That is the detail the whole approach depended on: because the custom code sat in content rather than in the builder's internals or a theme layer, it stayed relatively isolated from plugin updates.

The decision rule I applied, section by section, was:

• Native Elementor where it reproduced the approved design cleanly — because that is what left the content editable by the client.
• Custom code in an HTML widget only where the design demanded control the builder could not give without compromising quality.
• No theme-level customisation, because the project never needed it.

Performance and SEO configuration. WP Rocket was used to configure caching and general performance settings. Yoast SEO was used to manage page titles, meta descriptions, sitemap generation and basic on-page SEO settings.

Other implementation detail. The site was Spanish only — no multilingual layer. Contact forms were built with Contact Form 7, with submissions delivered by email. Google Analytics, Google Tag Manager and Google Maps were integrated where required.

Plugin restraint. I avoided installing plugins unless they offered clear value and long-term maintainability. On a WordPress site, plugin sprawl is the ordinary cause of update fragility, security exposure and performance decay. The constraint was also practical: because the client specified the PHP version, every plugin had to be compatible with that environment, so plugin choice was never free.

Production use only.

CMS

WordPress

Page builder

Elementor, Elementor Pro, Elementor Theme Builder

Theme

Hello Elementor (stock)

Custom code

Hand-written HTML, CSS, JavaScript in Elementor HTML widgets

Forms

Contact Form 7

SEO

Yoast SEO

Redirects

Redirection

Caching

WP Rocket

Security

Wordfence

Deployment

Manual, migration-based

Analytics

Google Analytics, Google Tag Manager

Maps

Google Maps

Design handoff

Figma

For the duration of the engagement I was responsible for the ongoing health of the WordPress application after launch — continuously, from March 2023 to July 2026.

• WordPress core updates
• Theme and plugin updates
• Evaluating plugin compatibility before applying updates
• Selecting new plugins when a requirement called for one
• Implementing new functionality and building new pages
• Fixing production issues
• Maintaining the Elementor implementation as the site grew

Some of this was proactive — I reviewed the application, updates, compatibility and general site health on my own initiative. The rest arrived through tickets and client requests. Tecnodata handled day-to-day content updates; larger changes, new pages and technical work came to NOVAZ Group.

Deployment. Development was local. Completed and validated features went to production through a manual, migration-based process. There was no automated pipeline. After every deployment I verified the production environment and resolved anything I found before treating the work as complete.

Across the infrastructure boundary. Where an issue involved the hosting infrastructure, I diagnosed it and coordinated directly with the hosting provider or the infrastructure team to resolve it — without owning that layer.

Updates. I evaluated compatibility before applying updates rather than after. Across the years I maintained the site, no WordPress or plugin update caused a production incident.

The project was deliberately not dependent on me. Technical knowledge was shared within the NOVAZ Group development team, other developers knew the project and where the custom code lived, and the relevant implementation details were documented. The intent was that the project could carry on without any one person, and that was a design goal rather than an afterthought.

What I brought to it was not that I was the only one who could maintain it. It was several years of accumulated context, having led the implementation and made the key technical decisions, and being able to diagnose or implement changes efficiently because I understood the system deeply.

The real challenge was sustained rather than acute. No dramatic incident stands out. The difficulty was translating complex designs into a maintainable WordPress implementation, and then making the same judgement call again and again over several years: was Elementor sufficient for this section, or did it need custom code?

Getting that boundary wrong in either direction has a cost. Too much custom code and the client can no longer edit their own site. Too little and the approved design degrades. The balance held — through years of maintenance and updates, without generating recurring production issues.

One concrete failure worth recording. After one of the migration-based deployments to production, some mobile layouts were affected. Not an outage: certain responsive styles no longer behaved as they had locally.

I diagnosed it by reviewing the affected sections at mobile breakpoints and inspecting the CSS, then corrected the relevant responsive rules and re-verified the affected pages in production.

The lasting outcome was not the fix. It was adding an explicit post-deployment responsive verification step, specifically after migration-based deployments — the class of deployment that had caused it.

Elementor as the primary system, with custom code isolated where the design required it. This was the decision the project turned on.

The requirement that drove it came from the client: future content changes had to be as easy as possible for their team. So the page builder was chosen to satisfy an operational need of the business, not a technical preference. Had long-term editing stayed under my control, I might have chosen a more code-heavy approach with a custom child theme. The choice was contingent on who would maintain the content.

The two options I was choosing between:

1. 1Force everything through Elementor, and compromise the approved design.
2. 2Abandon the builder for custom code, and lose the editability the client needed.

I took neither. Elementor stayed the primary system, and I dropped to hand-written HTML, CSS and JavaScript only for the sections the builder could not carry.

Bought

Design fidelity without compromising the builder. Relative isolation from Elementor's internals. Approximately three years of WordPress and Elementor updates with no update-caused incident.

Paid

Custom code distributed across multiple widgets rather than centralised, which made maintenance less centralised as the site grew.

I found that cost by maintaining the system, not by predicting it.

The approach was agreed with the client, not imposed. Some of the most important conversations on this project were not about code. For several complex sections and animations, I asked the client for approval to build them with custom HTML, CSS and JavaScript rather than with Elementor alone, and explained the trade-off: visual fidelity against future editability against technical maintainability. The final implementation approach was agreed after that explanation. It was not only a coding decision.

Two decisions of restraint. I avoided plugins that did not offer clear value and long-term maintainability, and I did not build a child theme the design did not require. Both reduced the amount of bespoke surface that had to be maintained, re-audited and kept compatible. Both connect to the update record above — there was less to break because there was less that was custom.

Two things I would do differently, both of which only became visible through maintaining the site rather than building it.

A staging environment. The original workflow — local development, then migration-based deployment — was effective and reliable. But validating changes without a dedicated staging environment means testing against production, and the responsive regression above is exactly the class of problem staging would have caught first.

Centralised custom code. Elementor HTML widgets were a practical way to reproduce the sections the builder could not handle cleanly, and the approach remained stable. But as the site grew, custom code spread across multiple widgets made maintenance less centralised than I would now prefer. Related: the implementation was documented, and I would document the custom sections more explicitly than I did.

If I built this project again I would keep Elementor for content flexibility, and add a staging environment, centralised reusable custom code, more explicit documentation of the custom sections, and a clearer deployment checklist.

The underlying lesson is the one I would carry to any long-lived system:

A solution can be technically successful and still reveal maintenance improvements only after you have lived with it for several years.

I led the development implementation from an approved design, defined the WordPress architecture behind it, participated in the production deployment, and then maintained and extended the application for approximately three years.

That last part is the reason I put this project forward. Plenty of work can be judged by whether it launched. This one can be judged by something harder: the architectural decisions I made at the start — Elementor as the primary system, custom code isolated in HTML widgets, no child theme, deliberate plugin restraint — were tested by roughly three years of real production use, content growth, client requests, and WordPress, theme and plugin updates. They held. The implementation stayed maintainable rather than becoming progressively more fragile, which is the usual fate of a page-builder site carrying custom code.

It also shows the boundary of what I owned. I ran the application layer and coordinated across an infrastructure boundary I did not control, which is the position most in-house web work actually occupies. And the decision that mattered most was not the one I preferred technically — it was the one that matched how the client would have to operate the site after I handed it over.