Company facts
The facts about Micro Tech: what we do and what proves it.
Micro Tech is a software engineering studio in Sarajevo, Bosnia and Herzegovina, working remotely for clients in the US, Europe and West Africa. It designs, builds and runs systems where a mistake costs money: payments, identity documents, POS terminals, warehouses and fleets. It also provides technical leadership for those systems.
This page puts the plain facts in one place for anyone comparing studios. Each capability below links to the case studies that show it.
01
At a glance
- Name
- Micro Tech
- Legal entity
- OR Micro Tech
- Registered address
- Zaima Šarca 14, 71000 Sarajevo, Bosnia and Herzegovina
- Based in
- Sarajevo, Bosnia and Herzegovina
- Shipping production software since
- 2020
- Clients in
- US, Germany, Sweden, West Africa
- How we work
- Remote · 9–18 CET · 4 h overlap with US and EU
- Engagements
- Project · Long-term · Technical lead embedded in your team · Fixed-price written assessment
- Billing
- Development is billed by the hour. Only a written assessment has a fixed price, with its scope, the document and the delivery date agreed up front.
- Languages
- English, Bosnian
- Website
- www.microtech.consulting
- A 30-minute call
- Book on Calendly
02
What we do and the proof
Each area lists the services we offer in it and the case studies that show the work. An area goes on this list only when at least one case study backs it.
Technical leadership and software architecture
Zero-downtime migration and legacy modernization
- 04 · Four years rebuilding a live US marketplace Zero outages
- 02 · A design system for 30+ white-label brands ~100 / 30+
Marketplace and multi-tenant SaaS platforms
Identity verification, KYC and official documents
Payments and fintech
Data engineering: warehouses, analytics and high-write data
AWS architecture and cloud cost reduction
React Native, offline-first apps and hardware integration
Design systems and component libraries
AI-assisted engineering and rescuing AI-built apps
Human-in-the-loop model integration
The model in production was a computer-vision model for identity checks, not a language model.
Business systems: ERP, permissions and regulated records
Web applications and APIs
- 04 · Four years rebuilding a live US marketplace Zero outages
- 08 · One codebase for five kinds of user 506 routes
03
Sectors and markets
Clients are listed by sector and market. We don’t name them.
- Logistics: a US marketplace for truck services
- Regulated finance: remote KYC in Germany
- Government: identity documents in West Africa
- Cross-border remittance and POS terminals
- Healthcare and finance: meetings under HIPAA
- Construction: ERP and white-label estimating software
- Retail data: BI reporting for a US-market supplier
- B2B SaaS: a Swedish code-analysis company
04
Technologies in the case studies
The list covers every technology named in a case study’s stack, grouped by area. Technologies used in three or more case studies are highlighted. Open one to see which case studies used it.
- Web and frontend
Next.js · Used in 4 case studies
React · Used in 4 case studies
CSS · Used in 2 case studies
JavaScript · Used in 2 case studies
TypeScript · Used in 2 case studies
Fabric.js · Used in 1 case study
HubL · Used in 1 case study
HubSpot CMS · Used in 1 case study
Redux · Used in 1 case study
SCSS · Used in 1 case study
styled-components · Used in 1 case study
Vite · Used in 1 case study
- Mobile and hardware
React Native · Used in 3 case studies
Android · Used in 2 case studies
Expo · Used in 2 case studies
Kotlin · Used in 2 case studies
NFC / ICAO 9303 · Used in 2 case studies
biometrics · Used in 1 case study
Java · Used in 1 case study
offline-first · Used in 1 case study
Swift · Used in 1 case study
Turbo Modules · Used in 1 case study
- Backend
Node.js · Used in 9 case studies
- Four years rebuilding a live US marketplace
- Live analytics with annual reports in under a second
- Event tracking from listing position to phone call
- Scheduled jobs that ran renewals and recurring billing
- One codebase for five kinds of user
- Remote identity verification that holds up in review
- Frozen invoices and offline coupons that pay out once
- An AWS bill eight times larger than it needed to be
- Payment integrations for five products in four markets
WebRTC · Used in 2 case studies
Express · Used in 1 case study
Handlebars · Used in 1 case study
NestJS · Used in 1 case study
WebSockets · Used in 1 case study
- Databases and data
MySQL · Used in 6 case studies
InfluxDB · Used in 3 case studies
PostgreSQL · Used in 3 case studies
Amazon Redshift · Used in 1 case study
materialized views · Used in 1 case study
Neo4j · Used in 1 case study
OpenSearch · Used in 1 case study
Redis · Used in 1 case study
- Cloud
AWS · Used in 5 case studies
S3 · Used in 2 case studies
AWS Lambda · Used in 1 case study
AWS Transcribe · Used in 1 case study
SQS · Used in 1 case study
- Payments and integrations
Apple Pay · Used in 1 case study
DocuSign · Used in 1 case study
Google Pay · Used in 1 case study
national gateways · Used in 1 case study
PayPal · Used in 1 case study
SAP · Used in 1 case study
Stripe · Used in 1 case study
- AI and machine learning
Claude Code · Used in 1 case study
Figma MCP · Used in 1 case study
TensorFlow · Used in 1 case study
- Design and tooling
Figma · Used in 2 case studies
CI · Used in 1 case study
custom ESLint plugin · Used in 1 case study
design tokens · Used in 1 case study
ESLint · Used in 1 case study
npm · Used in 1 case study
pnpm workspaces · Used in 1 case study
pre-commit hooks · Used in 1 case study
Turborepo · Used in 1 case study
05
What we don’t do
- Projects that conflict with our values
- We have turned down projects for this reason.
- Rewrites for their own sake
- We stabilize first and rewrite only when it is worth the cost.
- Estimates presented as measurements
- For example, the ~50% increase in team throughput once standards were checked in CI is marked as an estimate.
- Client names
- We describe engagements by sector and market and never name the client.
06
How to read the evidence
- On the home page and the case study and services indexes, the label on a figure says how we know it: Measured, Counted, Derived or Estimate. Other labels, such as Constraint or Outcome, say what kind of figure it is.
- On the services page, a service that no case study fully backs is marked Partial proof. Its evidence comes from related client work, our own products or our articles.
- Case studies are written by the person who did the work. They say “I” for the author’s own work and “we” where a team worked.
- Every case study except 01 has the same five parts: the summary, the constraint the work had to respect, what was done, the result, and what the author would do differently. Case study 01, on the CDS design system, is built around the five problems the system solves.
07
Contact, profiles and files
- For search engines and AI assistants
- llms.txt: A map of the site for language models
- llms-full.txt: The company facts, every case study and every service in full, in one text file
- sitemap.xml: Every page, in both languages
- feed.xml: New articles, as RSS
Next step
If these facts fit what you need, we should talk.
The first call takes 30 minutes, and you’re under no obligation.