01 · Review
Architecture and build-vs-buy review
You get each option’s five-year cost, the point at which the recommendation would change, and a date to revisit the decision.
- A written document
- Assumptions ranked by sensitivity
// Engineering studio · Sarajevo · remote
Software for places where a mistake costs money
We design, build and run custom software and apps for payments, identity documents, POS terminals, warehouses and fleets, for clients in the US, Europe and West Africa.
deploy — production● streaming
$ mt deploy --env production
✓ types no any, typed requests
✓ tests foundations, payments
› cutover CloudFront origin swap
✓ live no visible change for users
- Regulated finance
- Government ID
- Healthcare under HIPAA
- Construction sites
- Logistics and fleets
- Retail data
- Cross-border payments
Counted
6
years shipping production software
Counted
11
client systems, four of them for direct clients
Counted
2
client products we built were sold, one of them to a US bank
Counted
0
recorded outages through four phases of one live product
The tag above each number says how we got it.
// Case studies · 18
Four case studies to start with
We don’t name clients, and their systems sit behind logins. Each case explains what had to stay as it was, what we decided and what the numbers showed.
$ mt case open --id 04
Technical Lead · Jul 2022 – 2026 · direct client · team of 12
Four years rebuilding a live US marketplace
could_not_change: The marketplace was the client's only source of revenue, so nothing could be taken offline or rewritten in place.
CountedZerorecorded outages across 4 phases
Measured60 → 90+Lighthouse performance; SEO 30 → 90+
Derived2M+ / dayanalytics writes, yearly report under 1 s
Node.js · React · Next.js · Expo · MySQL · OpenSearch · InfluxDB · Redis · AWS
$ mt case open --id 13
Data warehouse architect · 2025 – present · direct client · the choice of warehouse was mine
A 15-minute report now opens in 0.2 seconds
could_not_change: The BI tool generates the queries and customers' saved reports depend on the schema, so neither could change.
Measured15 min → 0.2 sthe largest customer’s report
Measured4 min → 0.1 sa second heavy report
Scope200M+products in the source system
Amazon Redshift · S3 · MySQL · materialized views
$ mt case open --id 09
Full-stack engineer · 2024 · 6 months · direct client
Passport applications taken where there is no network
could_not_change: The applications included biometrics, and the people the agents visited often had no connection.
Measured$24k → $2kmonthly AWS bill
Counted3causes found: over-provisioning, loops, uploads through the backend
StatusLivein production, app on Google Play
React · Next.js · Expo · PostgreSQL · AWS · offline-first · biometrics
$ mt case open --id 10
Full-stack engineer · 2020 · 6 months · via agency
Remote identity verification that holds up in review
could_not_change: Regulation required video identification, and each session's record had to hold up in a review years later.
Counted6 stepsgestures and numbers, random in every session
Not accuracy98%of model proposals were confident; the other 2% were business questions, not technical ones
OutcomeSoldthe client’s product, acquired at MVP stage
TensorFlow · WebRTC · React Native · Node.js · AWS · NFC / ICAO 9303
// How we decide
You choose from three options
Each proposal we make has a fastest, an optimal and a best option. For each one we give the price and what has to be true in two years for it to pay off.
Real example · Campaign and email system for a marketplace
Fastest
An account on a ready-made service: you use its templates and import users from a CSV.
Trade-off
You’re live in days, but from then on the business depends on a service you have no say in.
Must be true in two years
Campaigns remain a side channel, and revenue doesn’t depend on them.
Optimal
We send the email ourselves, through an external provider.
Trade-off
Better control over content and timing, but the data still sits in someone else’s dashboard.
Must be true in two years
Volumes stay moderate and nobody needs per-user history.
Best
Our own system around the sending service: templates, a queue, bounces and opens per user, all in the admin dashboard.
Trade-off
Costs the most up front, but one system covers campaigns, renewals and bulk sends.
Must be true in two years
Renewals and campaigns keep driving revenue. The client chose this option.
// Principle
Keep the logic and the data in your own system.
Sending an email is a commodity. The product is knowing which user didn’t open it, and seeing that on the user’s profile in your admin dashboard.
// Build vs buy, 2026
Asked to make the case for building, we advised against it.
We costed five scenarios over five years. Building came out at about twice the price, so we recommended renegotiating with the existing vendor and named the contract value at which that recommendation would change.
// Ways to hire us
Pick the engagement that fits the problem
We’ve done each of these more than once. A written review has a fixed price; builds and lead roles are billed by the hour.Working with us remotely: hours, contracts, invoices
02 · Build
A system, from first commit to production
It covers web, mobile and the API, including the parts with no SDK: payment gateways, passport chips, POS terminals and thermal printers.
- You choose an option before we start
- Code that moves money is tested even when nothing else is
03 · Lead
A Technical Lead on your team
Four years on one product: rescue, rebuild, a shared design system and AI in the team’s daily work, plus hiring and mentoring.
- Coding standards turned into automated checks
- Specialists grown into full-stack engineers
// AI in a client team · 2026
Standards checked on every commit
On a US marketplace we turned the team’s coding standards into automated checks, since conventions nobody enforces get ignored. Each codebase has its own rule set, run in the pre-commit hook and again in CI. Claude works within those rules every day, on components, tests and integrations.
Estimate · Jira tickets~50%increase in team throughput
Outcome0tests written by hand on the marketplace once the rules ran in CI
git commit -m "feat: fleet table"
$ pre-commit run --all. ● web no-explicit-any ✓. ● web typed api calls ✓. ● web component ≤ 200 lines ✗. FleetTable.tsx has 231 lines: split it. ● api request/response types ✓. ● cds primitives tested ✓. ✗ commit blocked · 1 rule failed. same rules run again in CI, no bypass
// Writing
Recent articles
20 OCT 2026 · 5 min
Working with a software team in Bosnia and Herzegovina: what to check
Time zone, contracts, code ownership, personal data, invoices and holidays: what a US or EU company should check before a team in Sarajevo starts work.
19 OCT 2026 · 4 min · Data
Technical due diligence: read the bill before the code
Before you buy or fund a product, its cloud bill shows what the system really does. How I read an unfamiliar system, and what the assessment contains.
26 SEP 2026 · 5 min · Platforms
Our design system as a skill made an AI agent at least 2× faster
An AI agent built the same design in 31.7 hours with our design system as a library, then 2.5 hours with it as a skill. A newer model explains part of the gap.
22 SEP 2026 · 10 min
The biggest fool: six confident AI errors in one afternoon
In my cost research an AI made six errors, none hedged, each making the story tidier. The same pattern shows in 1,598 court cases and invented package names.
// Next step
Every client so far came by referral. This is the first time we’re asking.
We start with a 30-minute call that commits you to nothing. Afterwards we come back to you with the options and what each one depends on.