# Brigada.dev, full content > IT outsourcing and software development studio in Prishtina, Kosovo. This file contains the full text of our service pages and author profiles, for AI assistants that prefer one document over crawling. Short version: https://brigada.dev/llms.txt Sitemap: https://brigada.dev/sitemap.xml All content below is written by named people at Brigada. Author and source URL are given for each page. You are welcome to quote and cite this material. ======================================================================== # AI Development Services URL: https://brigada.dev/services/ai-development Author: Endrit Saiti, Co-Founder and CTO (https://brigada.dev/about/endrit-saiti) Last updated: 2026-08-03 Most AI projects die somewhere between the demo and the first real user. We build the unglamorous parts that decide whether yours survives. A notebook that answers ten questions correctly is not a product. We learned that the slow way, on systems where being wrong has consequences: a police report that goes to a prosecutor, a revenue decision across a hotel portfolio, a voice assistant people talk to every morning. We came to AI work sideways. We were already running production Laravel and Python for clients with uptime commitments and regulators to answer to. When those clients started asking for AI features, the interesting question was never whether a model could do the task. It was what happens when the model is confidently wrong at two in the morning on a Sunday, and who finds out first, you or your customer. ## What we build We work on four shapes of problem. Most projects are a mix of two or three of them. - LLM pipelines that take messy input (field notes, transcripts, documents, form data) and produce structured output a downstream system can trust. - Retrieval augmented generation over your own content, with retrieval treated as a search problem first and a prompt problem second. - Agents that take actions in real systems: booking, routing, updating records, escalating to a human when confidence drops. - Evaluation harnesses, because the only way to change a prompt safely is to know what broke. ## The part most teams skip Evaluation. Almost nobody builds it up front, and it is the reason AI projects stall at eighty percent good enough. Without an eval suite every prompt change is a guess. Someone tweaks a system prompt to fix one customer complaint, ships it, and quietly regresses four behaviours nobody was watching. Six weeks later the team has stopped touching the prompt at all, because they cannot predict what will happen. We build a graded corpus early, usually a few hundred real cases with known good answers, and wire it into CI. After that, changing the prompt becomes an ordinary engineering task with a pass rate attached. It is dull work and it is the difference between an AI feature you can improve and one you are afraid of. ## Cost and latency are product decisions Model choice gets framed as a quality question. In production it is mostly a cost and latency question, and those are product decisions rather than engineering ones. A two stage pipeline where a small fast model handles the easy ninety percent and a larger one handles the rest will often beat a single expensive model on every axis that matters. Cheaper, faster, and easier to debug because you can see which stage failed. We default to that shape and only reach for the big model where it earns its place. ## Where it runs Not every client can send data to a third party API, and for some that is a legal position rather than a preference. We have shipped into a CJIS compliant environment for US law enforcement, onto Swiss hosting with a self hosted text to speech stack for a client who wanted nothing leaving the country, and onto ordinary EU infrastructure for everyone else. If your constraint is regulatory, say so early, because it changes the architecture rather than the deployment script. ## Related work Four of these are live right now. You can go and look at them. ### Police Reports AI (AI / Law Enforcement) A patent pending pipeline that turns an officer's field notes into a complete, regulator compliant report. Officers get back roughly two and a half hours per shift. Running in departments across six US states, hosted in a CJIS compliant environment. Stack: Laravel, React, Python, LLM pipeline, PostgreSQL, AWS Case study: https://brigada.dev/work/police-reports-ai ### Vector Guest (Hospitality / AI) Harold OS, the AI layer running aparthotel portfolios: revenue, demand, guest journey and ground team coordination. Agents plus RAG over a vector database, with LangFuse for tracing. A dedicated Brigada team ships weekly alongside the founding operator. Stack: Laravel, LLM agents, RAG, Vector DB, LangFuse Case study: https://brigada.dev/work/vector-guest ### Prime Tech Group (AI / Consumer Apps) Oxodin, a voice first agentic assistant for a Swiss AI company, live on the App Store and Google Play. Self hosted text to speech, Swiss hosting, and an agent layer that has to feel instant because people speak to it. Stack: React Native, Expo, Laravel, LLM agents, Self-hosted TTS Case study: https://brigada.dev/work/prime-tech-group ### Walter (Sustainability / Web) A US IT asset disposal business where the AI work is quieter: an assisted content pipeline feeding a Statamic CMS, aimed at lead generation rather than headlines. Stack: Laravel 12, Statamic 6, AI content pipeline Case study: https://brigada.dev/work/walter ## Frequently asked questions Q: Do you fine tune models or use APIs? A: Usually APIs, with strong retrieval and evaluation around them. Fine tuning earns its place when you have a large volume of consistent labelled examples and a narrow task. Most clients who ask for fine tuning actually need better retrieval, and we will tell you that before taking the work. Q: How do you stop the model hallucinating? A: You constrain what it can say and you check what it said. In practice that means structured output rather than free text wherever possible, retrieval that grounds answers in your own documents, and a validation layer that rejects or escalates responses failing a rule. Then an eval suite tells you the actual rate rather than your impression of it. Q: Can you run models on our own infrastructure? A: Yes. We have shipped into CJIS compliant hosting for US law enforcement and onto Swiss infrastructure with a self hosted speech stack. Self hosting costs more in engineering time and usually more in compute, so it is worth doing when you have a regulatory or contractual reason rather than a general preference. Q: How long until something is in production? A: Our typical gap between kickoff and first deploy is under two weeks, though that first deploy is deliberately small. A useful AI feature in front of real users is more often six to twelve weeks, and most of that goes into evaluation, edge cases and the fallback path rather than the model call itself. Q: What does an AI project cost to run? A: It depends far more on your traffic shape than on the model price list. We model token cost per request early, because the difference between a naive single model design and a staged one is often five to ten times on the monthly bill at the same output quality. ======================================================================== # Web Development Services URL: https://brigada.dev/services/web-development Author: Endrit Saiti, Co-Founder and CTO (https://brigada.dev/about/endrit-saiti) Last updated: 2026-08-03 Most of what we do is web platforms. Laravel on the back, React or Vue on the front, and a lot of opinions about what happens in between. We build the kind of software a business runs on rather than the kind it markets with. Credentialing and payroll for a healthcare staffing company. A salary exchange engine that has to satisfy HMRC. A nationwide property data platform refreshing lead data daily. Products where being wrong is expensive and being slow is worse. The stack is deliberately boring. Laravel, PostgreSQL or MySQL, Inertia with React or Vue, Tailwind, hosted on AWS or Laravel Cloud. Boring means we can hire for it, hand it over, and debug it at speed two years later. Every hour not spent fighting an exotic framework is an hour spent on the thing you actually asked for. ## What we build Four recurring shapes, and most engagements are one of them. - SaaS products, from the first paying customer through to multi tenant billing and role based access. - Internal platforms that replace a stack of spreadsheets and disconnected tools with one system people will actually use. - Marketplaces and two sided platforms, including payments, payouts and the operational tooling nobody scopes at the start. - Content driven sites where editors need to change everything without opening a ticket. ## We start with the data model The schema is the part you cannot cheaply change later. Interfaces get redesigned constantly and nobody minds. Get the data model wrong and you will be writing migrations against production for the next two years, apologising to your own team. So the first week of a build is usually not visual. It is us asking uncomfortable questions about edge cases you were hoping to defer. What happens when a shift is cancelled after payroll runs. What a refund does to a payout that already left. Whether two records can genuinely be identical. That conversation is cheap now and enormously expensive in month nine. ## Shipping beats staging We deploy early and often, and we would rather put something small in front of real users than perfect something in a staging environment nobody visits. The typical gap between kickoff and first production deploy on our projects is under two weeks. That deploy is usually unimpressive on purpose. It exists so the pipeline, the environment, the monitoring and the rollback path all get exercised while the stakes are low, instead of on launch night. ## Handover is a feature Some clients keep us for years. Avilog has had us running their engineering for six. Others want to build an internal team and take the code back, and that is a legitimate outcome we plan for rather than resist. In practice that means readable code over clever code, tests where they earn their keep, documented decisions, and no bus factor of one. If handing the project over would be painful for you, that is also a sign the codebase is worse than it should be. ## Related work A sample of web platforms we have shipped and still run. ### Oly Care (Healthcare / SaaS) End to end healthcare staffing: credentialing, shift operations and integrated payroll in one product. Launched in ten weeks and replaced a six tool stack for every pilot agency. We are the engineering team of record on a multi year retainer. Stack: Laravel, Vue 3, Inertia, PostgreSQL, Stripe, AWS Case study: https://brigada.dev/work/oly-care ### Niche Data (Real Estate / Data) A nationwide US property lead platform with daily updated distress data, foreclosures, probates and skiptracing, plus CRM automation. Search runs through Algolia because the data volume made ordinary querying too slow to be useful. Stack: Laravel, Inertia, Vue, PostgreSQL, Algolia Case study: https://brigada.dev/work/niche ### Kinsail (HR / Fintech) A UK workplace nursery scheme built from scratch: salary exchange, an employer dashboard and HMRC compliant reporting. Sign ups convert without support calls, which for a product this regulated was the actual goal. Stack: Laravel, Livewire, Tailwind, MySQL, Stripe, AWS Case study: https://brigada.dev/work/kinsail ### SEOMag Links (Growth / SEO) A premium link building marketplace for agencies, with sponsored placements and an automated order flow. Stripe Connect handles payouts to portal owners, which is the part that quietly makes or breaks a marketplace. Stack: Laravel, Inertia, React, PostgreSQL, Stripe Connect Case study: https://brigada.dev/work/seomag-links ### Evergreen Valleys (Real Estate) A bilingual marketing platform for a sustainable residential development, with 3D rendered house models. Every model and page is editable by the sales team without a developer, which was the entire brief. Stack: Laravel 11, Filament v3, Tailwind, Vite Case study: https://brigada.dev/work/evergreen-valleys ### Walter (Sustainability / Web) The web platform for a US IT asset disposal and e-waste business: CMS, AI assisted content operations and lead generation, on a retainer. Stack: Laravel 12, Statamic 6, Tailwind v4, Forge Case study: https://brigada.dev/work/walter ## Frequently asked questions Q: Why Laravel rather than Node or Rails? A: Because we are genuinely fast in it and the ecosystem covers most of what a business application needs without bolting together five libraries. If you already run Node or Python and want to stay there, we work in those too. Helix Flag is Python and FastAPI. We would rather match your team than win an argument. Q: Do you work with our existing codebase? A: Often, yes. Several engagements started as a rescue or a hardening pass on someone else's code. We will usually ask for a paid discovery week first so we can give you an honest assessment rather than an optimistic one. Q: Can you take over a project that has stalled? A: Yes, and it is more common than greenfield work. The first thing we do is get it deploying reliably, because a project you cannot ship is not a code problem yet, it is a process problem. Q: Who owns the code? A: You do, from the first commit. It sits in your repository under your organisation and we work in it. There is no scenario where ending the relationship means losing access to your own software. ======================================================================== # Mobile App Development Services URL: https://brigada.dev/services/mobile-development Author: Endrit Saiti, Co-Founder and CTO (https://brigada.dev/about/endrit-saiti) Last updated: 2026-08-03 Getting an app built is the easy half. Getting it through review, keeping it working without signal, and shipping updates without breaking anyone is the rest of it. We build mobile products where the phone is the primary way people use the thing, not a companion to a website. That changes the engineering. Connectivity is not guaranteed, the update cycle is controlled by two companies who are not you, and a crash rate that would be tolerable on the web will get you uninstalled. Most of our work is React Native with Expo, sharing a codebase across iOS and Android and dropping into native modules where it genuinely matters. We are not religious about it. When a feature needs native performance or a platform API the bridge handles badly, we write native. ## Offline is a design constraint, not a feature If your users are pilots, drivers, field engineers or market traders, they will be offline regularly and they will not accept a spinner as an answer. Building for that means deciding early what the phone is allowed to be the source of truth for, how conflicts resolve when two devices edited the same record, and what the user sees while a sync is pending. Retrofitting offline support into an app that assumed connectivity is close to a rewrite, which is why we ask about it in the first conversation. ## Store review is part of the schedule App Store and Play Store review is not a formality and it is not predictable. We plan for it. Builds go through TestFlight and internal tracks early, so the first submission is not also the first time anyone has seen a release build. Payments, subscriptions, account deletion, privacy labels and permission prompts are the usual rejection reasons. All of them are cheaper to handle correctly at build time than during a rejected release with a launch date already announced. ## The backend is usually the real project A mobile app is a client. Almost every mobile engagement we take on is really a backend and API project with a mobile client attached, and pricing it any other way sets everyone up for disappointment. We build both sides, usually Laravel behind the app, which means the API is designed for the screens that exist rather than reverse engineered from a generic REST layer that fits nothing well. ## Related work Mobile work that is live in the stores or in daily field use. ### Prime Tech Group (AI / Consumer Apps) Oxodin, a voice first agentic personal assistant for a Swiss AI company, live on both the App Store and Google Play. React Native and Expo on the client, Laravel and an agent layer behind it, with self hosted text to speech on Swiss infrastructure. We continue as the engineering team. Stack: React Native, Expo, Laravel, LLM agents, Self-hosted TTS Case study: https://brigada.dev/work/prime-tech-group ### Avilog (Aviation / SaaS) An aviation logbook used by thousands of pilots, six years in production. Offline first by necessity, because pilots log flights where there is no signal, then export regulator ready reports for EASA, FAA and CAA once they are back on the ground. Stack: Laravel, Nuxt, PostgreSQL, Redis, AWS, Offline-first mobile Case study: https://brigada.dev/work/avilog ### Street Wallet (Fintech / Payments) Cashless QR payments for traders, small businesses and corporate programmes across South Africa, pulling Apple Pay, Samsung Pay, SnapScan and Zapper into one wallet with next day settlement. We have been the embedded engineering partner since early 2026. Stack: QR payments, Wallet integrations, Merchant onboarding Case study: https://brigada.dev/work/street-wallet ## Frequently asked questions Q: React Native or fully native? A: React Native for most products, because one codebase across two platforms is a real cost saving and the performance ceiling is higher than its reputation suggests. Fully native when the app is graphics heavy, deeply tied to platform APIs, or when you already have native teams to maintain it. Q: Do you handle App Store and Play Store submission? A: Yes, including the parts nobody enjoys: privacy labels, data safety forms, review responses and staged rollouts. We have shipped to both stores and would rather own that process than hand you a build and wish you luck. Q: Can you take over an existing app? A: Usually. The honest answer depends on how the state management and API layer were built. We do a paid audit first and tell you plainly whether continuing or rewriting is cheaper, including when the answer is not the one that earns us more work. Q: How long does a first version take? A: A focused first release is typically three to four months including backend, store submission and a real beta. Anything promising six weeks is either very small or is not counting review, payments and the offline path. ======================================================================== # DevOps and Cloud Services URL: https://brigada.dev/services/devops-cloud Author: Endrit Saiti, Co-Founder and CTO (https://brigada.dev/about/endrit-saiti) Last updated: 2026-08-03 We run infrastructure for products where downtime has a phone number attached to it. That tends to make you conservative in useful ways. A lot of DevOps work sold to small and mid sized companies is architecture theatre: a Kubernetes cluster for an application that would be happier on two servers and a managed database. We have inherited several of those and the pattern is consistent. The cluster is impressive, nobody understands it, and the person who built it has left. Our bias is towards the smallest infrastructure that meets your actual availability requirement, with complexity introduced only when something forces it. Sometimes that is genuinely Kubernetes, as it is for Oly Care. Sometimes it is Forge and a well configured server, and admitting that is worth more to you than a diagram. ## What we take on - AWS architecture and migration, including the unglamorous cost review that usually pays for the engagement. - CI/CD pipelines that run tests, build assets and deploy without a human holding a runbook. - Containerisation with Docker, and Kubernetes only where the workload justifies it. - Observability: logs, metrics, traces and error tracking wired up so an incident starts with evidence rather than guesswork. - Hardening and compliance driven hosting, including CJIS compliant environments and single country requirements. - On-call, with a rota and an escalation path rather than a hopeful Slack message. ## Incidents are a process problem Most outages we get called into are not caused by exotic failures. They are caused by nobody knowing who is responsible, no alerting on the thing that broke, and a deploy process risky enough that the team avoids shipping the fix. So we start with the boring layer. Alerts that fire on symptoms users feel rather than on CPU graphs. A deploy that can be rolled back by one person under pressure without reading documentation. A written escalation path with names on it. None of this is interesting to talk about and it removes most of the three in the morning phone calls. ## Security work we do by default Databases and caches bound to localhost rather than every network interface. Firewalls actually verified rather than assumed. SSH keys audited and rotated when people leave. Security updates applied on a schedule instead of during an incident. None of that is advanced. It is just the set of things that turns up in every audit we run on infrastructure we did not build, including our own when we go looking honestly. ## Related work Infrastructure we currently run or have hardened. ### Oly Care (Healthcare / SaaS) AWS with Kubernetes behind a healthcare staffing platform handling credentialing, shift operations and payroll. Multi year retainer, which means we live with our own architectural decisions rather than handing them over and leaving. Stack: AWS, Kubernetes, PostgreSQL, Laravel Case study: https://brigada.dev/work/oly-care ### Police Reports AI (AI / Law Enforcement) A CJIS compliant hosting environment on AWS for a platform used by US law enforcement across six states, where the compliance boundary shapes the architecture rather than sitting on top of it. We carry the on-call. Stack: AWS, CJIS-hosted, PostgreSQL, Python Case study: https://brigada.dev/work/police-reports-ai ### Avilog (Aviation / SaaS) Six years of continuous production on AWS with Redis and PostgreSQL, serving thousands of pilots. Long enough that we have migrated it, upgraded it and been paged by it, which is the only honest way to learn what an architecture costs. Stack: AWS, PostgreSQL, Redis, Laravel Case study: https://brigada.dev/work/avilog ### Helix Flag (Fintech / Risk) Platform hardening for a collaborative B2B risk intelligence product on Python and FastAPI, with Sentry for error tracking, as the system moved from working to scaling. Stack: Python, FastAPI, Sentry, Stripe Case study: https://brigada.dev/work/helix-flag ## Frequently asked questions Q: Do we need Kubernetes? A: Probably not. Most products under serious load are still fine on managed services and a small number of well configured servers. Kubernetes earns its complexity when you have many services, real elasticity requirements or a platform team to own it. We will say so when the answer is no. Q: Can you take over infrastructure nobody currently understands? A: Yes, and it is a large share of what we get asked to do. We start with an audit: what exists, what is exposed, what is costing money for nothing, and what would happen if the one person who set it up were unavailable. You get that document whether or not you continue with us. Q: Do you provide on-call? A: For clients where we run the platform, yes, with a rota and a defined escalation path. We do not offer on-call for systems we have not been allowed to fix, because being paged for a problem you are not permitted to solve helps nobody. Q: Can you host inside a specific country or compliance regime? A: We have delivered CJIS compliant hosting for US law enforcement and Swiss only hosting including a self hosted speech stack. Tell us the constraint at the start, because it changes the design rather than the deployment. ======================================================================== # IT Outsourcing in Kosovo URL: https://brigada.dev/it-outsourcing-kosovo Author: Ardit Xhaferi, Co-Founder and CEO (https://brigada.dev/about/ardit-xhaferi) Last updated: 2026-08-03 We are eleven people in Prishtina building software for companies in twelve countries. Here is honestly how that works, including the parts harder than the sales pitch suggests. Outsourcing has a reputation problem and most of it is earned. The common story goes like this. You hire an agency, you get a good team for the first month, then the strong engineers rotate onto a newer account and you are left with whoever is available. Communication degrades into status reports. Nobody on the vendor side actually cares whether the product works. We started Brigada in 2024 partly because we had watched that happen from the inside. The way we operate is a reaction to it. Small team, people stay on their projects, and the founders are in the code and in the client calls rather than only on the contract. ## Why Kosovo, specifically Kosovo is in Central European Time, which puts us in the same working day as all of Europe and gives us a solid overlap with the US East Coast in our afternoons. For UK and EU clients that means an ordinary working relationship with no asynchronous handoff ritual. For US clients it means your morning is our afternoon, and standups actually happen live. The talent pool is younger than Western Europe and it is genuinely good. Kosovo has a large population under thirty, English is widely spoken to a professional standard, and the engineers we work with have been building for international clients from the start rather than adapting to it later. The cost difference is real, and we would rather be plain about it than pretend it is not part of the reason you are reading this page. Rates here are meaningfully below London, Zurich or San Francisco. That is not because the work is worth less. It is because the cost of living in Prishtina is different. ## How engagements are structured Three models, and we will tell you which one fits rather than selling you the most expensive one. - Dedicated team. A named group working only on your product, joining your standups and your tooling. This is what Vector Guest and Oly Care have, and it works best for anything long running. - Project build. A defined scope with a start and an end, which suits a first version or a specific platform. Kinsail and Evergreen Valleys were built this way. - Embedded engineers. One or two of our people inside your existing team, reporting into your leads. Street Wallet works like that. ## What we ask from you This is the part most outsourcing pages leave out, and it is the biggest predictor of whether an engagement goes well. We need one person on your side who can make decisions, and we need them reachable. Not a committee, not a weekly sync where questions queue up for six days. Projects that struggle almost always struggle because the answer to a blocking question took four days to arrive, not because the engineering was hard. We also need honesty about constraints early. Regulatory requirements, an existing system nobody wants to touch, a launch date already promised to a board. None of those are problems on day one. All of them are problems in month four. ## The team you get Eleven people. Two founders who are still hands on, engineers across Laravel, React, Vue, Python, React Native and AWS, plus DevOps and QA. Everyone works on a small number of projects rather than being spread across eight. You will know their names. They will be in your Slack. When someone goes on holiday you will hear about it in advance from them, rather than discovering it through silence. ## Related work Twelve clients across twelve countries. A few of the longer relationships: ### Avilog (Sweden) Six years in production and we still run the engineering team. The best evidence we can offer that people stay on projects here, because the same relationship has outlasted most agency contracts several times over. Stack: Long-running engineering partner Case study: https://brigada.dev/work/avilog ### Oly Care (United Kingdom) Engineering team of record on a multi year retainer for a UK healthcare staffing platform. Launched the first version in ten weeks and have been the backbone of the product since. Stack: Dedicated team, Multi-year retainer Case study: https://brigada.dev/work/oly-care ### Vector Guest (United Kingdom) A dedicated full time Brigada team shipping weekly with the founding operator, who opened their entire stack to us. That level of access only happens when the working relationship is genuinely close. Stack: Dedicated product team Case study: https://brigada.dev/work/vector-guest ### Police Reports AI (United States) Product, design, engineering and on-call for a platform used by US law enforcement in six states. A US client working with a Kosovo team on software with a compliance boundary, which is the case people assume cannot work. Stack: Product, Engineering, On-call Case study: https://brigada.dev/work/police-reports-ai ## Frequently asked questions Q: What timezone do you work in? A: Central European Time. We overlap the full working day with the UK and EU, and roughly 14:00 to 18:00 CET with the US East Coast. Several of our engineers shift later deliberately for US accounts. Q: Is the whole team in Kosovo? A: Yes, based in Prishtina. That is deliberate. It means the team knows each other, reviews each other's code, and can solve something in a room when it matters. Q: How do you handle contracts and intellectual property? A: You own the intellectual property and the code from the first commit, held in your own repository. Contracts are straightforward and we are used to working under NDAs and client paper rather than insisting on our own. Q: What happens if we want to stop? A: You keep everything and we help with handover. We would rather end an engagement cleanly and be recommended than lock someone into a relationship they have outgrown. Q: Do you work with startups or only established companies? A: Both. Kinsail and Oly Care were early stage when we started. Avilog and Walter are established businesses. What matters more than stage is whether there is someone who can make decisions quickly. Q: How quickly can you start? A: Our typical gap from kickoff to first production deploy is under two weeks. Actually starting depends on current capacity, and if we cannot staff you properly we will say so instead of taking the work and figuring it out later. ======================================================================== # Nearshore Software Development for Europe URL: https://brigada.dev/nearshore-software-development-europe Author: Ardit Xhaferi, Co-Founder and CEO (https://brigada.dev/about/ardit-xhaferi) Last updated: 2026-08-03 Nearshore only means anything if the overlap is real. Ours is the entire working day, from Prishtina, in Central European Time. Offshore development to a timezone eight hours away produces a specific kind of failure. Every question costs a day. Your team writes long clarifying documents instead of asking. Work arrives that answers the question you asked rather than the one you meant, and by the time you see it there is another day of work stacked on top. Nearshore fixes that by removing the delay, not by improving the documentation. We are in Central European Time. If a Berlin, Amsterdam, Stockholm or London team has a question at eleven in the morning, they have an answer at eleven in the morning. ## What the overlap actually buys Live standups instead of written status. Pair debugging when something is genuinely hard. A code review that comes back within the hour rather than tomorrow. Decisions made in a fifteen minute call instead of a thread that runs for three days. It sounds minor written down. Over a six month engagement it is the difference between a team that feels like part of your company and a supplier you send requirements to. ## Data protection and hosting For EU and UK clients the data questions come up early and they should. We work to GDPR expectations by default: data minimisation in the schema rather than in a policy document, access controls that match roles, retention and deletion built in rather than promised. On hosting we go where the requirement points. EU regions on AWS for most clients. Single country hosting where that is contractual, which we have done for a Swiss client who wanted nothing leaving Switzerland, including running a self hosted speech stack rather than calling an American API. We are not a law firm and will not pretend to give you a compliance opinion. What we do is build so that satisfying your compliance people is a matter of showing them the system rather than apologising for it. ## How this compares to hiring locally Honestly, if you can hire two strong senior engineers in your own city and keep them for three years, do that. It is the best outcome and no agency should tell you otherwise. Nearshore makes sense when hiring is slow, when you need a capable team in weeks rather than quarters, when the work has a defined arc, or when you want capacity without permanent headcount. It also makes sense when you need a mix of skills, a backend specialist plus a mobile developer plus someone who knows AWS properly, that you cannot justify hiring individually. ## Related work European clients we work with from Prishtina. ### Kinsail (United Kingdom) A UK workplace nursery scheme with salary exchange and HMRC compliant reporting. Regulated UK payroll logic built end to end by a team in Kosovo, on UK working hours. Stack: Laravel, Livewire, MySQL, Stripe Case study: https://brigada.dev/work/kinsail ### Oly Care (United Kingdom) UK healthcare staffing platform handling credentialing, shifts and payroll. Launched in ten weeks, now on a multi year retainer with a dedicated team. Stack: Laravel, Vue 3, AWS, Kubernetes Case study: https://brigada.dev/work/oly-care ### Prime Tech Group (Switzerland) A Swiss AI company where the hosting requirement was absolute. Swiss infrastructure, self hosted text to speech, nothing leaving the country. Live on both app stores. Stack: React Native, Laravel, Swiss hosting Case study: https://brigada.dev/work/prime-tech-group ### Avilog (Sweden) A Swedish aviation platform we have run for six years, serving thousands of pilots with EASA, FAA and CAA compliant exports. Stack: Laravel, Nuxt, PostgreSQL, AWS Case study: https://brigada.dev/work/avilog ### SEOMag Links (Poland) A marketplace for SEO agencies with sponsored placements, automated order flow and Stripe Connect payouts to portal owners. Stack: Laravel, React, Stripe Connect Case study: https://brigada.dev/work/seomag-links ## Frequently asked questions Q: Is Kosovo in the EU? A: No. Kosovo is not an EU member state, though it is in Central European Time and geographically in the Balkans. For most clients this is a contractual detail rather than an operational one, and we host client data in EU regions or wherever your requirement specifies. Q: How do you handle GDPR? A: By building for it rather than documenting around it: minimal personal data in the schema, role based access, retention and deletion paths that exist in code. We sign data processing agreements and work under client contracts. For a formal compliance opinion you want your own counsel, not us. Q: Can you host everything inside the EU? A: Yes, and inside a single country where that is the requirement. We have done Swiss only hosting including self hosted speech synthesis for a client who could not use US APIs. Q: What languages does the team speak? A: English throughout, to a professional working standard. All code, documentation and communication is in English by default. Albanian is our first language and several of the team speak German. Q: How is this different from offshore development? A: Timezone, mostly, and what that does to how a team behaves. With a full working day of overlap you get live conversation and same hour code review. With an eight hour gap you get documents and delay, and quality suffers in ways that are hard to attribute at the time. ======================================================================== # Endrit Saiti, Co-Founder and CTO URL: https://brigada.dev/about/endrit-saiti Profiles: https://www.linkedin.com/in/endrit-saiti/ | https://github.com/endritvs Focus: Software architecture, Laravel, PHP, React, AWS, Kubernetes, Large language model systems, Retrieval augmented generation, DevOps Co-founder and CTO of Brigada.dev in Prishtina, Kosovo. Works on system architecture, Laravel, AWS infrastructure and production LLM systems for clients in the US, UK and Europe. I co-founded Brigada in 2024 with Ardit Xhaferi and I run engineering. In practice that means I am still in the code most days, which is deliberate. The moment a CTO stops reading the codebase they start making architecture decisions from memory, and memory is usually about two years out of date. Most of my work sits in three places. System architecture, where the decisions are expensive to reverse and worth arguing about. Infrastructure, mainly AWS, including the CJIS compliant environment we run for a US law enforcement client and the Kubernetes setup behind a UK healthcare platform. And production AI, which is the newest of the three and the one where the industry has the least settled practice. On AI I have a narrow opinion: the model is rarely the hard part, evaluation is. We have shipped LLM pipelines into environments where a wrong answer reaches a prosecutor, and the only thing that makes that survivable is a graded corpus you can run before every change. We build that first now, on every AI project, because we learned what happens when you do not. The longest running thing on my desk is Avilog, an aviation platform we have run for six years. Six years is long enough to be wrong about something and then have to live in it. That shapes how I scope work more than anything else I could put on a slide. ======================================================================== # Ardit Xhaferi, Co-Founder and CEO URL: https://brigada.dev/about/ardit-xhaferi Profiles: https://www.linkedin.com/in/ardit-xhaferi/ | https://github.com/ArditXhaferi Focus: IT outsourcing, Nearshore software development, Product strategy, Engineering team structure, Client partnership, Software delivery Co-founder and CEO of Brigada.dev in Prishtina, Kosovo. Works on product strategy, client partnerships and how outsourced engineering teams are structured for companies in the US, UK and Europe. I co-founded Brigada in 2024 with Endrit Saiti. He runs engineering, I run the company, and the line between those two is thinner than an org chart would suggest. My job is mostly the gap between what a client needs and what a team can actually deliver. That sounds soft until you have watched a project fail. Almost none of them fail for technical reasons. They fail because a decision took two weeks, because the scope quietly changed and nobody said so, or because the person paying for the work and the person using it wanted different things and never met. So I spend my time on the unglamorous side of delivery. Who the decision maker is. What is genuinely fixed and what is negotiable. Whether the team has enough context to make good calls without asking. Whether the client is hearing the truth from us when a date is at risk, which is the single thing that most determines whether they stay. On outsourcing I have a strong view, having been on both sides of it. The model works when the same people stay on your product long enough to care about it, and it fails when they are treated as fungible capacity. That is why we stayed small on purpose, and why we would rather turn work down than staff it badly. ======================================================================== # Contact Email: admin@brigada.dev Location: Prishtina, Kosovo (Europe/Pristina, CET) Website: https://brigada.dev