Home / Architecture

Website and app architecture

Architecture is how the website or app is built: which piece does what, which data is stored, how it ships and what you can change without breaking the rest. The aim is a base someone else can follow.

I do it myself. I'm David López Dayer, a software engineer for more than 15 years. I have built product with teams including Emirates, Coniq and Service2Media, and I have my own product, Growth Trainer. I do not pick a stack for your project before seeing it. The technology follows what you have to maintain.

What is included

A static site, like this one, can be the right decision when the content changes rarely and what matters is speed and control. An app with accounts, data and business logic needs a different base. Both can be well built. Choosing the complex one when you do not need it is an expensive way to look current.

Performance without theatre

I look at the weight of what gets downloaded: fonts, images and JavaScript that does not help. On this site the fonts are served from the same domain, the portrait is WebP with a JPEG fallback, and static files can be cached for a year because the HTML asks for a specific version. That is hygiene. It is not a score I will promise you.

I do not publish a Core Web Vitals number here as if it were a client result. Those figures come from real use, and every project has its own. If yours has a loading problem, we measure it and fix the cause.

Security on a public site

On a content site, practical security is specific: headers that stop another page from framing you, a content policy that does not load third-party scripts, and a form that stores nothing on the server because it opens your own email app. If your product has accounts, payments or other people's data, the scope is different and we talk before writing code.

Who it is for

Someone whose website or app can no longer be changed calmly, or someone about to build who wants to avoid that. Also a team that already has the design and the message and needs it built without a larger platform than the product needs.

If the problem is only copy and content structure, the architecture may not need to change. The first review exists so we do not open an engineering project when the fix is something else.

Decisions that stay written down

When something has to be built, I write down a few decisions and the reason for each one. Where the content lives. What is computed on the server and what in the browser. How a change is published and how you roll it back. Which data is personal and which does not need to be stored.

That avoids a project only its author understands. It also avoids repeating the same conversation every time a title or a flow has to change. If the site is static, the decision can be that simple: the HTML is the source, there is no database, and a change ships with the deploy.

If you already have a team, I use their way of shipping. I do not impose a new flow when the current one works. The job is to leave the change inside that flow, with a note someone else can read in ten minutes.

How the work goes

I look at what is there, separate what can change from what has to be rebuilt, and write it in an order. The first review is free and takes a few days. A change on something that already exists usually takes weeks. A new base is scoped after seeing the work. There is no public rate card: a review is not the same job as an app.

When the interface is part of the same job, it is described under website and app design. The criterion is the same: from the message to the code, without handing one decision to three suppliers.

What I do not do

I do not maintain a product blind, and I do not enter a system without seeing the code and the deploy. I do not add a framework, a CMS or an analytics layer because it is available. If your case needs a team larger than one person, I will say so.

Write from the contact form or to hello@dayer.es. With the URL, or the repository if you can share it, I will tell you where I would start.