Web development

Web development means writing the code your case calls for, instead of adapting a template built for someone else. The difference doesn’t show on launch day. It shows six months later, when you need to change something and find out what it costs to touch what was assembled.

Built or developed: the difference that matters

The market uses “building a website” and “developing a website” as synonyms, but they describe very different practices.

Criterion	Assembled in a page builder	Developed in code
First version live	Days	Weeks
Page weight	Loads assets the screen doesn’t use	Loads only what the screen uses
Core Web Vitals	Hard to keep within thresholds	A project requirement
Cost of each change	Grows over time	Stable
Switching vendors	Locked into the tool	Any team can take over
Plugin updates	Can break the layout	Don’t affect the structure

Page builders aren’t wrong. To validate an idea quickly, or for a site that will live for three months, they’re the right choice. The problem is using one for a site that has to last for years, rank for competitive terms and support the company’s sales operation.

How we choose the technology

The decision comes from the problem, never from preference. In practice, three scenarios cover almost every project.

Content changes often and the people editing it aren’t technical

WordPress with a custom theme, no page builder. You get the editor your team already knows, and the site doesn’t pay the page builder’s performance cost. This is the most common choice for a business website with an active blog.

The interface has state, calculations or heavy interaction

React with Next.js, or Astro when the content is mostly static and the priority is shipping as little JavaScript as possible. Here the rendering model (in Portuguese) is an SEO decision, not just an architecture one: a page that needs JavaScript to exist is a page the crawler may not see.

There are business rules, permissions and integrations

Laravel or Node.js on the backend, with a relational database and a documented API. When the website is the front end of a system, the data layer is designed before the interface.

What we deliver with the site

A custom-developed website comes with the things that make it possible for someone other than us to work on it:

• A Git repository with a real commit history, not a final zip file.
• Technical documentation on how to run the project locally, how to deploy and where the architecture decisions are recorded.
• A staging environment separate from production, so changes are tested before they go live.
• Measurement in place: Analytics, Search Console and field monitoring of Core Web Vitals.
• Automated backups with tested restores. A backup that has never been restored isn’t a backup.

Migrating an existing site

Many of our projects rebuild a site that already has traffic. That’s more delicate than starting from scratch, because there are rankings to preserve.

The rule we follow: no URL that already ranks changes its address. We inventory the indexed URLs before we start and keep the existing slugs. When a change is unavoidable, we map 301 redirects (in Portuguese) one to one. Never a blanket redirect of everything to the homepage, which is the fastest way to lose rankings.

After go-live, we monitor index coverage and rankings for a few weeks. A temporary dip happens. A drop that doesn’t recover means something is wrong, and fixing it is our problem.