00 / Velvict — Zenica & Sarajevo

We build software that survives production.

Anyone can ship a demo.

The hard part starts the week after launch: the migration that has to run on live data, the backup nobody has tried restoring, the error at 02:40 that wakes one person up. We write those parts. Since October 2023, from Zenica and Sarajevo, for teams in Bosnia, Germany and the United States.

Tell us what is breaking See how we work →

2023-10-23Founded
03People
02Offices
03Countries served
10+Years in production
Current local time in Zenica and Sarajevo:--:--Zenica & Sarajevo

The company is two years old. The person who will scope your project has been keeping systems alive for more than ten. Every figure here is checkable, which is why there isn’t a seventh.

02 / What you actually have

You already have a system. It runs the business and nobody enjoys talking about it. The developer who wrote it has moved on. Somewhere there is a spreadsheet that is the real source of truth, and one person who knows why the nightly job has to start at 02:40 and not 02:00.

Your inbox this quarter is full of people who want to put a chatbot on top of it.

None of them will be on the phone at 02:40.

03 / The stack

Sixteen marks, one row.

Anthropic, OpenAI and DeepSeek sit in this row at the same size as Postgres, Redis and .NET, in alphabetical order, because that is where they belong in a stack. A model vendor is a dependency. It does not get its own shrine.

Not all sixteen at once, and not all of them for you. Most projects need four or five of these, and choosing which four is most of the job.

04 / Engagements

Four things people hire us for.

01
The first version, shipped
The smallest version a real person can actually use.
We build the smallest version of your idea that a real person can actually use, put it somewhere you can reach it, and let you argue with it. Arguing with a running thing is cheap. Arguing with a specification is expensive and everybody wins the argument. Every internal tool ends up needing a CSV export and an audit trail, so both go in while the data model is still soft rather than after it has hardened around a report nobody can change.
TypeScript · React · Angular · .NET · Node · PostgreSQL
02
The system you already have, made survivable
We take on the thing nobody wants to touch.
This is what AESC hired us for. The work is unglamorous and it is mostly the same list: get it into version control, get a staging environment that matches production, write down how to deploy it, restore a backup to prove the backup works, then find the three queries that are responsible for most of the slowness. We do not rewrite it. Rewrites are how a working system becomes two broken ones.
SQL Server · MySQL · PostgreSQL · Redis · Elastic · Azure · AWS
03
The year after launch
A fixed monthly amount for a system that is already live.
Monitoring, backups, deploys and small changes, billed as one number a month. You get the runbook and the credentials at the start, not at the end, so you are never locked in by ignorance. We would rather you could replace us and choose not to. If a month goes by and we have not earned it, we will tell you before you notice.
Monitoring · Backups · Deploys · Small changes
04
AI, where it earns its keep
Sometimes the answer is a model. Usually it is a query.
We measure the boring version first and only ship the model if it beats it. Full argument below.

05 / Where AI sits

I will tell you when a model is the wrong answer.

A language model is a component with a failure mode you cannot fully enumerate. It will be confidently wrong in front of your customer. It will cost more in month six than the demo suggested. It will change underneath you when the vendor ships a new version on a Tuesday. None of that makes it useless. It makes it a dependency you engineer around, the same way you engineer around a network you do not control.

So before anyone writes a prompt, we write the evaluation set: real examples pulled out of your own data with the answers you expect beside them, checked by somebody in your building who knows what right looks like. It is version-controlled next to the code, which is what makes the Tuesday survivable — you re-run it against the new model and get a number instead of an argument. Then we build the version with no model in it at all — the query, the lookup table, the rules a person can read — and we score both against the same set. If the boring version wins, you get the boring version and a smaller invoice.

If the model wins, it ships with the parts nobody demos. Every input, output, latency and cost is logged, so that when it goes wrong you can read what happened instead of guessing. There is a ceiling on monthly spend and an alert before it. There is a path for when the API is down, because the API will be down. Anything that writes to your database or leaves your building goes past a person first, until there is enough evidence to stop doing that.

Retrieval and language models are good at some problems and expensive at most of them. A lot of what is being pitched as AI this year is a database query with a worse failure mode and a bigger bill. I would rather lose the work than sell you that.

06 / The work we can describe

We are grateful for the exceptional work Velvict did on our internal web app. Their attention to detail, quick turnaround, and ability to understand our needs exceeded our expectations and greatly enhanced our team’s workflow.

Amra Kljun · CEO · AESC

What it isAn internal web application for AESC. Not a public product.
Our relationship to itAmel part-owns AESC. So this is not an arm’s-length reference.
What we can show youNothing. It holds their operating data.

That quote is real and unedited, and it is also from a company Amel part-owns, which is why the row above says so rather than leaving you to find out. Treat it as a description of the work, not as a reference. Every screen of the application has live operating data on it, so there is no screenshot we could publish that would be both honest and legal, and we are not going to mock one up with invented data and call it a case study.

07 / What you keep

Three people is why it is written down.

A shop with sixty people can afford to keep the knowledge in the building. We cannot, so it goes into three files that leave with you.

01 PAGE
A decision record for every choice that is expensive to reverse.
Why Postgres and not the database the last developer preferred, why the import runs in one transaction instead of a hundred, what we considered and rejected, and what it would cost to change our mind later. One page each, dated, in the repository next to the code they explain.
03 DRILLS
A runbook with three procedures in it, and all three have been run.
How to deploy it, how to restore a backup, how to roll back the last release. A backup nobody has restored is a rumour, so we restore one before we write that section down.
01 LIST
Every account, key and domain the system needs, and whose name each one is in.
The registrar, the DNS, the mail sender, the object store, the payment key, the certificate that expires in fourteen months. This is the document companies discover they never had on the day the person whose personal card is paying for the domain stops replying.

None of the three is written for our benefit. If you replace us next year, your next developer starts from those files instead of from a phone call with us, and that is the entire reason they exist.

08 / What we are not

There are three of us. We take a small number of projects at a time, and if we are full we will tell you the date we are free rather than start and go slowly. If your project needs thirty engineers by March, we will say so in the first forty-five minutes and you will not have wasted a week finding out.

Most of what we build ships under somebody else’s name. We are often the engineering team behind another studio’s project, so the logos belong to them and not to us — which is the honest reason this page has no wall of them.