09 Review & continuity
Security-aware architecture
Access control, data isolation and secure defaults designed into the architecture — in the data model, the file storage and the server, not added after launch.
Outcome: Security decisions made deliberately — and written down.
Security-aware architecture means deciding, while the system is being designed, who can see and change which data and where each rule is enforced — in the data model, the file storage and the server — rather than adding those rules after launch.
It matters most for software that holds client, financial or personal data, serves several organisations from one database, or shows different roles different things. Reviewing a system you already run is a separate service: technical audit & architecture consulting.
Typical needs
- Sensitive client, financial or personal data
- Roles that must see different things
- Several companies or offices whose data must stay apart
What you receive
- Role-based access and data isolation designed into the data model
- Secure defaults: HTTPS, security headers, secrets kept on the server
- Private file storage without public links, with access checked on every download
Approach
How the work runs.
- 01
Map access first
Before the database schema is written, list who uses the system, which organisation each record belongs to and which fields are sensitive — and agree who may see, change and delete what.
- 02
Enforce it in the database
Row Level Security policies check every row against the user’s organisation and role, so the rules hold even when the database is reached outside the app.
- 03
Keep files and keys private
Documents go to private storage without public links and are served only after a server-side check. API keys and other secrets stay on the server and never reach the browser.
- 04
Secure defaults on every change
Every response is served over HTTPS with HSTS and security headers, and CI scans dependencies and secrets, so the defaults stay in place as the code changes.
Technologies
- PostgreSQL Row Level Security
- HTTPS, HSTS & security headers
- Dependency & secret scanning
The engineer who does this work is the founder, Filip Volf — you work with him directly.
Questions
About this service.
How is this different from technical audit & architecture consulting?
A technical audit produces a written review of a system that already exists: findings, priorities and trade-offs. This service designs and builds the controls themselves — access rules, data isolation, private storage and secure defaults — into a new system or into the part of an existing one being rebuilt. An audit can come first and show where to start.
Can you promise our application will be secure?
Nobody can honestly promise absolute security. What you get is specific controls, each stated precisely: who can reach which data, where that is enforced, how files are served and which secrets stay on the server — and anything not yet in place is called a plan.
What happens when someone leaves or changes role?
Access is tied to each person’s own account and role and checked in the database itself, so deactivating the account or changing the role changes access with it — there is no shared password or link left to revoke. In Pametni Advokat every user has a personal sign-in, a deactivated account loses access immediately, and deleting records is reserved for the lawyer.
Related services
- 05
APIs, backend architecture & PostgreSQL
Outcome: Business rules enforced once, where the data lives.
- 08
Cloud infrastructure & integrations
Outcome: Routine releases and observable integrations.
- 10
Technical audit & architecture consulting
Outcome: What to fix first, what can wait — and why.
Next step
Let’s talk about what you’re building.
Describe what you need built or fixed, how the work runs today and the constraints. You get clarifying questions or a first outline of the approach — by email, in English or Serbian.