A team asks an AI builder for a customer portal. It adds accounts, documents, approvals, and a dashboard. Each feature works in the preview. Six iterations later, several parts of the application can change the same customer status, and nobody is sure which record is authoritative.
Architecture is often discussed as something to address after the prototype. In practice, a prototype already contains architectural decisions. The question is whether those decisions were deliberate, understood, and appropriate for the application’s intended use.
Draw the system before choosing its shape
Start with a simple map of users, data stores, external services, and business operations. It does not need elaborate notation. The purpose is to establish where information enters, where decisions are enforced, and which systems the application depends on.
For a supplier portal, distinguish the portal’s own workflow data from authoritative supplier records in an ERP system. Decide whether the portal can edit those records directly, submit a reviewed change request, or only display information received from another service. These are different designs, even if the screens look identical.
Also identify the deployment constraints. Customer-managed hosting, regional data requirements, private-network integrations, and recovery objectives can rule out an otherwise convenient builder setup. Finding that out after generating most of the application is expensive.
Define the trust boundaries
A trust boundary is a place where the application must not assume that incoming information is legitimate simply because another part of the interface produced it. A browser request, an uploaded document, a webhook, and a background job all need an appropriate validation and authorization model.
Do not let a request choose which tenant it belongs to without checking the authenticated user’s membership. Do not treat a hidden interface control as a permission check. Do not put a privileged credential in frontend code to avoid designing a server-side integration.
Write these boundaries as requirements that can be tested. “A reviewer can approve submissions only for their organization” is better than “make the portal secure.” The OWASP authorization guidance offers a useful foundation for translating broad security intentions into actual checks.
Decide what must happen together
Suppose accepting an order must reserve stock, record a payment decision, and notify a warehouse. A generated sequence of API calls may work in a demonstration. What should happen if the second call succeeds but the response is lost? What if the warehouse notification arrives twice?
Some operations can be kept within one database transaction. Others span systems that do not share a transaction. Those may need durable workflow state, retries, reconciliation, and compensating actions. The architecture should describe the business outcome when a step cannot complete.
Idempotency is particularly important when retrying an action could duplicate a charge, reservation, or approval. AWS’s discussion of idempotent APIs explains why retry behavior belongs in the API contract rather than being left to the caller’s optimism.
This is not an argument for microservices by default. A well-structured monolith can be easier to reason about and operate. Splitting a small system into services can introduce exactly the coordination problems the team is not yet equipped to handle.
Separate stable rules from generated interfaces
Interfaces often change faster than the business rules behind them. A team may safely experiment with a planning screen while keeping identity, authorization, billing, and authoritative records behind reviewed interfaces. The boundary lets the team generate and replace parts of the experience without repeatedly redesigning its core responsibilities.
The right boundary depends on the project. It could be an API, a module inside one application, or a workflow enforced by an existing enterprise product. What matters is that there is one understood place to enforce the rule, rather than several screens implementing slightly different versions.
Record the reason for the decision. A short architectural note can explain why sensitive documents live in a separate store, what the permitted access path is, and which tradeoffs were accepted. Future engineers and coding agents both need that context.
Ask for evidence before calling it production-ready
An architecture review should produce a small set of decisions and checks, not merely a diagram. Identify the critical flows, their owners, failure behavior, and the tests that demonstrate the boundaries hold.
For the supplier portal, useful evidence might include rejected cross-organization requests, safe handling of duplicate submissions, a verified document-retention policy, and a recovery exercise using a non-production copy. An unanswered question should be visible as a gap, not concealed behind the fact that the agent generated plausible code.
Vibe coding can be a productive implementation technique inside these constraints. It is less useful as a substitute for choosing them. Before asking for another feature, make sure the team understands which decisions the next prompt is allowed to change.
Related reading
- AI-Assisted Software Development: What Engineers Still Need to Own
- Disposable Software: When a Business App Should Work Like an Excel Model
- Vibe coding: platforms, B2B risks, and delivery choices
Put the right guardrails in place
SaM Solutions can assess your project, review its architecture, and help decide where AI-assisted development fits.