Web app development

A web app is an application you use in the browser, with personal logins and data that changes: client portals, private areas, booking systems, dashboards. Unlike a website, it does something rather than just showing pages. In web app development we design applications that are secure, fast and, in their public parts, easy to find. Pricing is by quote, after a free analysis.

We are an Italian agency and we work online, with clients across Italy and abroad. Write to us in Italian, English, Spanish, German or Portuguese.

Web app, website or native app

A website presents the same content to everyone. A web app recognizes who you are, saves your data and lets you get things done: make a booking, upload documents, track an order. The two often live on the same domain: public pages to get found, a private area to work in.

A native app is downloaded from a store and can use every feature of the phone, but it has to be developed and published for each platform. A web app works on any device with a browser, and updates for everyone at once. A middle ground is the PWA, a progressive web app that can be installed like an app.

Examples of web apps

• Client portals: documents, invoices, case status.
• Private areas: content or tools for members, agents, employees.
• Booking systems: calendars, availability, confirmations and reminders.
• SaaS: a subscription service with accounts, plans and payments.
• Dashboards: data from several sources, with filters and reports.

If the web app is meant to run the inside of your business, what you need is custom software, such as a management system built around your processes.

How it is built: frontend, backend, database and APIs

A web app has four parts:

• Frontend: what you see in the browser. We use React with TanStack Start, which supports server-side rendering.
• Backend: the logic that applies the rules, checks permissions and carries out operations. We work with Node.js, Python or PHP with CodeIgniter 4.
• Database: where the data lives. We use MySQL or PostgreSQL.
• APIs: the way the frontend, the backend and external services, such as payments or email, talk to each other.

It all runs on Linux servers, with Ubuntu and nginx. We choose the tools to fit the project, not the other way round.

Secure authentication and sessions

A web app protects people's data, and login is the most sensitive point. Our reference is the OWASP Top 10:2025, which includes broken access control (A01), authentication failures (A07), injection (A05) and security misconfiguration (A02). In practice:

• passwords stored only as hashes, never in plain text, and multi-factor authentication where needed;
• sessions with secure cookies, expiry and sign-out from the settings;
• permissions checked on the server on every request, not just in the interface;
• validated input and parameterized queries against injection;
• secrets never in the code or the repository, an isolated user for each application, least privilege;
• HTTPS, a firewall, automatic security updates, verified backups and reversible releases.

Performance and Core Web Vitals

A slow web app gets abandoned. We measure Core Web Vitals: according to web.dev, a good experience means LCP within 2.5 seconds, INP within 200 milliseconds and CLS within 0.1, measured at the 75th percentile of visits. INP matters a lot in apps, where people click all the time. We keep it under control by loading only the code each page needs, optimizing queries and caching where it makes sense.

SEO for the public parts

The private area should not be indexed, but a web app's landing pages, listings, catalogs or articles should. An application that builds its pages only in the browser makes crawling harder. That is why we use server-side rendering: Google receives ready-made HTML, with clean URLs, titles, structured data and a sitemap. The basics are in Google's SEO Starter Guide. Private pages are explicitly excluded. For the content strategy, there is our SEO consulting, and if the public pages target several countries or languages, international SEO.

Privacy and where the data lives

A web app almost always processes personal data. We define with you where the data is held (chosen server, backups, external services), who can access it and how long it is kept. If we manage the server, we tell you who has access to the data and how backups are stored. Non-essential cookies need a banner that asks for real consent. The wording of the privacy notice remains with your privacy advisor: we prepare the technical side.

Scalability

You do not need the architecture of a large platform on day one. We start simple but tidy: database indexes for frequent searches, code split into modules, slow operations such as sending emails and imports placed in a queue, caching where needed. If your user base grows, we measure where the application slows down and act there, with a more powerful server or by separating the part under strain. How much work that will take depends on how usage grows, and we do not promise it in advance. We use widespread, well-documented tools such as React, Node.js and PostgreSQL, so that another developer can pick up the code without depending on us.

Custom web app or off-the-shelf SaaS

Before developing anything, we check whether a subscription service already does the job. Often one does, and it is worth using. An off-the-shelf SaaS is fine if:

• your process is similar to that of many other businesses, such as an appointment calendar or an advanced contact form;
• the available settings are enough and you can adapt to the product's workflow;
• you need to start right away and the subscription stays affordable as your users grow.

A custom web app makes sense when your process is your competitive advantage, when you need to connect data that off-the-shelf products do not connect, when the per-user fee becomes heavier than development, or when you want to control where your data lives. There is also a middle way: keep the SaaS for what it does well, and we develop only the missing piece, connected through API integrations.

What goes into a first MVP

An MVP is not an incomplete version of everything, but the complete version of one thing: the main journey your users need to be able to complete. It usually includes:

• sign-up and login, with only the roles that are strictly necessary, for example customer and administrator;
• the main flow from start to finish, such as making a booking, submitting a case or tracking an order;
• an essential admin panel to manage users and data;
• the email notifications you cannot do without;
• security, backups and measurement already in place, because they cannot be bolted on later.

Advanced reports, secondary automations and non-essential integrations stay out of the first version. We decide on them together, looking at how users actually use the MVP.

How we work: from the MVP onwards

1. Analysis. Goals, users, essential features and what can wait. What you get: a prioritized feature list.
2. Prototype. Clickable screens to test the user journey. What you get: the prototype for your approval.
3. MVP development. The minimum version that solves the main problem, tested on devices and browsers, with security and performance checks before going live. What you get: the app online, access and documentation.
4. Testing with real users. We collect errors and the points where users get stuck, and we fix them.
5. Evolution. New features based on what users actually do, with incremental releases.

How long it takes

It depends on the number of features, the integrations and how quickly approvals come in. An MVP with a few features arrives much sooner than a complete product: that is why we recommend it as the first step. The quote sets out the timeline phase by phase.

How much it costs

Pricing is by quote, after a free analysis of the project. It depends on features, user roles, integrations (payments, email, management software), the amount of data, security requirements and maintenance. The overall picture is on the web development page.

What we do not do

• We do not tie you to us. Code, domain, access and data stay yours, with documentation.
• We do not launch without testing security and performance.
• We do not suggest a web app if a website is enough.

Who looks after your project

Your point of contact is Eugenio Tommasi, who has been doing SEO since 2009 and builds websites and software. One point of contact for development, SEO, content and campaigns.

The first step

Describe the idea and who will use it: we will tell you what an MVP needs. Ask for a quote. If you also have a website you want to grow, tell us about that too.

Sources

• OWASP, Top 10:2025
• web.dev, Web Vitals
• Google, SEO Starter Guide