I build AI products and run them in production.

Context

Companies in Bosnia and Herzegovina are required to keep accurate, inspectable records of working time and absences. Most run this in spreadsheets: error-prone, unauditable, and painful the day a labor inspector shows up.

Constraints

• Auditability

  Every change to a time record must be traceable — who, what, when. A record that can be silently edited is worthless in an inspection.

• Multi-tenant from day one

  Each company's data fully isolated, with company-level roles and approval chains.

• Non-technical users

  HR staff and site managers, not engineers. The audit guarantees have to hold without anyone thinking about them.

• One engineer owns everything

  Architecture had to stay simple enough to operate alone, on a small infrastructure budget.

Architecture

Everent is a multi-tenant Next.js application on AWS, backed by PostgreSQL. Time and absence records are written through a service layer that appends every mutation to an immutable audit log. Reports are generated from the same event history, so a report and its audit trail can never disagree. The AI reporting layer sits beside the service layer — it never touches the database directly.

AI system design

• The reporting assistant turns questions like “who was on leave in March and who approved it” into structured, tenant-scoped queries.
• The model never writes SQL. It selects from a fixed set of validated query templates and fills typed parameters; anything outside the schema is rejected, and the user gets structured filters instead.
• Answers cite the records they were built from. Quality is checked against a golden set of question–result pairs that runs on every prompt or template change.

Decisions & tradeoffs

• Append-only event log

  Chose

  Every mutation appended to an immutable audit log.

  Rejected

  Soft-delete flags on mutable tables.

  Because

  An inspector-grade audit trail has to be a property of the data model, not of developer discipline.

• Template-constrained AI queries

  Chose

  The model fills typed parameters in validated query templates.

  Rejected

  Free-form LLM-generated SQL.

  Because

  Wrong numbers in an HR report are worse than no report; templates cap the blast radius of a bad generation.

• One database, row-level tenancy

  Chose

  A single PostgreSQL instance with an enforced tenant scope.

  Rejected

  Database-per-tenant.

  Because

  At this scale, a fleet of databases buys nothing that an enforced tenant scope does not.

Outcome

• 14 companies run their HR operations on Everent
• ~1,100 employees tracked daily
• Inspection-ready reports in under a minute — previously a day of spreadsheet work
• 99.9% uptime over the past six months

• TypeScript
• Next.js
• Node.js
• PostgreSQL
• AWS
• OpenAI API

I can take a regulated, unglamorous business problem and ship a production system that companies trust with their compliance.

Context

Professional surveillance equipment is bought on specs: coverage, compatibility, storage, regulation. Buyers who cannot translate their problem into those specs stall or buy wrong, and the seller pays for both.

Constraints

• Wrong answers cost money

  Recommending an incompatible camera is not a bad UX moment — it is a returned order.

• A living catalog

  Products, prices, and availability change weekly. Whatever the AI knows has to track that.

• Technical depth

  Spec sheets and compatibility matrices — the assistant must reason over structured data, not marketing text.

Architecture

A Next.js storefront on AWS with the catalog in PostgreSQL. A sync pipeline embeds products and spec documents into a vector index whenever the catalog changes. The advisor service composes hybrid retrieval — structured attribute filters plus semantic search — and passes only retrieved catalog data to the model.

AI system design

• The advisor is a constrained agent: it can search the catalog, compare retrieved products, and compose a recommendation — nothing else.
• Every product it mentions must come from the retrieval step; a response that references an item outside the retrieved set is rejected before it reaches the user.
• When retrieval confidence is low, the assistant says so and routes to a human instead of guessing.
• Retrieval quality is measured as hit rate on a curated set of real buyer questions; the set grows every time a session goes wrong.

Decisions & tradeoffs

• RAG over fine-tuning

  Chose

  Retrieval over a catalog that changes weekly.

  Rejected

  Fine-tuning on catalog data.

  Because

  Retrieval tracks a living catalog for free; a fine-tune is stale the day it ships.

• Hybrid retrieval

  Chose

  Structured attribute filters combined with semantic search.

  Rejected

  Pure vector search.

  Because

  “Night vision under 300 euros” is a filter plus a similarity query; embeddings alone get the price wrong.

• Refusal and handoff

  Chose

  Low retrieval confidence routes to a human.

  Rejected

  Forcing a recommendation from weak retrieval.

  Because

  A confident wrong answer is the most expensive output this system can produce.

Outcome

• ~1,800 advisor conversations a month
• Four in five advisor sessions end on a relevant product page
• Product discovery cut from minutes of spec reading to a short conversation

• TypeScript
• Next.js
• Node.js
• PostgreSQL + pgvector
• AWS
• OpenAI embeddings + LLM

AI with guardrails as the product itself — retrieval, evaluation, and failure paths designed before the first prompt was written.