05 Data, AI & platform
APIs, backend architecture & PostgreSQL
Data models, APIs and server-side logic that keep business rules in one place — with PostgreSQL doing the work it is good at.
Outcome: Business rules enforced once, where the data lives.
Backend work covers the part of a system nobody sees: the relational data model, the API other applications call and the server-side logic that decides what is allowed. The aim is one place for each business rule, enforced as close to the data as PostgreSQL allows.
The usual signs are the same rule implemented in three screens and a script, numbers from the database that nobody trusts, or a second application that needs data the first one owns. Before a first release is a good time too, while the model is still cheap to change.
Typical needs
- Business rules duplicated across screens, scripts and spreadsheets
- A database that grew without a model and is now hard to trust
- Several applications that need one reliable API
What you receive
- A relational data model with constraints and versioned migrations
- Documented APIs with validation at every boundary
- Access rules enforced in the database, not only in the interface
Approach
How the work runs.
- 01
Entities, keys and constraints
Records and their relations are modelled with keys, uniqueness and check constraints, so invalid states cannot be stored at all — not merely hidden by the interface.
- 02
Rules inside the database
Rules that must always hold — who may read a row, whether a payment may exceed an invoice — become policies, constraints or functions in PostgreSQL, so they apply to every application and script.
- 03
Validated API contracts
Every endpoint validates its input at the boundary and returns predictable errors, and the contract is documented where the developers who call it will look.
- 04
Versioned migrations
Each schema change is a reviewed migration, applied the same way locally, in a test environment and in production, so the history of the database can be replayed.
Technologies
- PostgreSQL
- Supabase
- Node.js
- TypeScript
- Python
The engineer who does this work is the founder, Filip Volf — you work with him directly.
Questions
About this service.
Why enforce business rules in the database?
Because the database is the one place every path goes through: the interface, imports, scripts and future applications. In Pametni Advokat, Row Level Security separates every office’s data even when the database is reached outside the app, and the database itself rejects overpayment.
Do you use Supabase or plain PostgreSQL?
Both. Supabase brings PostgreSQL together with sign-in and file storage, which suits many products — Pametni Advokat runs on it. Where you host the database yourself, the same data model and constraints work on plain PostgreSQL, with a Node.js or Python service in front of it.
How is this different from security-aware architecture?
Backend work builds the model, the API and the business rules. Security-aware architecture decides the access and isolation those rules must respect — roles, boundaries between organisations, secrets and secure defaults. In practice the two are designed together.
Related services
- 01
Custom software & SaaS
Outcome: One system of record instead of scattered tools.
- 08
Cloud infrastructure & integrations
Outcome: Routine releases and observable integrations.
- 09
Security-aware architecture
Outcome: Security decisions made deliberately — and written down.
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.