Digital products ·
Architecture begins when a prototype has to keep living
Web application architecture describes the product beyond its visible interface: how the browser talks to the server, where data lives, who has access and what happens when something fails. A prototype can hide these decisions while it demonstrates one successful path. Once real users and data arrive, architecture determines whether the product can evolve without continual reconstruction.
The interface shows an action; architecture carries it through
A user presses a button and sees a result. Between those moments, the application validates input, checks permissions, calls a server, reads or changes data and returns a response. Architecture identifies each participant in this route and its responsibility.
A static website may perform most of its work in the browser. A web application introduces accounts, private data, business rules, background tasks and external services. These responsibilities cannot safely remain inside one screen component.
Clear separation answers practical questions: where to look for a failure, which part can be replaced and who may change a record. The diagram exists to make the product governable rather than to display technical vocabulary.
Client, server and data form the central loop
The client runs in the browser. It displays state, accepts user actions and sends requests. Secret keys cannot live there, and a visual restriction alone cannot enforce access because the code and network requests exist on the user’s device.
The server receives a request, verifies authority and applies product rules. It decides whether an order may be created, a status changed or a private document displayed. It also connects the application to email, payments, a CRM, AI and other external systems.
The database preserves state between requests. Its schema represents the product’s concepts and their relationships. When entities merely reproduce an accidental first mock-up, every interface change forces a painful data change.
Define boundaries before choosing technologies
Begin with users, key actions, data and the consequences of failure. These reveal the boundaries between public and private, reading and writing, immediate responses and background work, and owned systems and external services.
The technology stack follows those decisions. A small customer portal may need one application and one database. A system with many integrations may need queues, dedicated workers and operational monitoring. A larger number of components is not evidence of maturity.
Useful architecture matches the current problem while preserving a clear route for growth. It avoids building infrastructure for imaginary millions of users, while keeping critical data out of a disposable prototype.
AI accelerates code but does not own architectural consequences
A model can quickly generate a screen, an API route and a table. Each fragment may work alone while the combination duplicates rules, names one field in several ways or bypasses an access check. Faster generation raises the cost of decisions that remain implicit.
AI-assisted development benefits from short architectural records: the source of truth, role model, module boundaries, error rules and external dependencies. These decisions give the model stable context for later changes.
Code needs tests beyond the successful path. Examine repeated requests, interrupted connections, invalid formats, expired sessions and unavailable dependencies. Architecture becomes visible where the system must stop safely.
A monolith often suits the first working product
A monolith keeps server interfaces, product rules and data access in one deployable application. For a small team, this simplifies release, testing and diagnosis. Responsibilities can still be separated into clear internal modules.
Independent services become justified when parts of the system truly operate differently: they scale separately, need distinct permissions, have their own release cycle or must continue when a neighbour fails. Splitting for fashion only adds networks, synchronisation and monitoring.
The boundary should follow load and the process of change. When one capability delays every release or requires a separate security model, it has a reason to become an independent service.
Test architecture through change and failure
A diagram is useful when the team can trace a new scenario through it. What changes when another role is added, an identity provider is replaced, status history is introduced or a failed operation is repeated? The answers reveal real dependencies better than a technology list.
The second test is failure. The application should distinguish invalid input, denied access, temporary unavailability and an internal fault. Important operations need a record, repeatable behaviour and a way to determine whether the action completed.
Within the Method, I begin architecture with a map of actions and data, assemble the smallest working loop and test it with a real change. The prototype gains a foundation for growth, while technology remains a consequence of the product.
From an idea to a digital product
If the task calls for a service or internal tool, we can define the first complete journey and a path to a working release.