@barkajs/barka 0.1.0

package/starters/lokatech/config/translations/pl.yaml

@@ -0,0 +1,108 @@
+# Polish UI translations
+# Keys use dot-notation: section.key
+
+# Navigation
+nav.services: "Usługi"
+nav.industries: "Branże"
+nav.case_studies: "Case Studies"
+nav.insights: "Wiedza"
+nav.about: "O nas"
+nav.careers: "Kariera"
+nav.contact: "Kontakt"
+nav.home: "Strona główna"
+nav.view_all_services: "Wszystkie usługi"
+nav.view_all_industries: "Wszystkie branże"
+
+# Language switcher
+lang.label: "Język"
+
+# Footer
+footer.services: "Usługi"
+footer.company: "Firma"
+footer.resources: "Zasoby"
+footer.rights: "Wszelkie prawa zastrzeżone."
+footer.crafted_with: "Stworzone z"
+
+# Mega menu — Services
+mega.services.custom_software: "Tworzenie oprogramowania"
+mega.services.custom_software_desc: "Dedykowane aplikacje w nowoczesnych architekturach"
+mega.services.cloud: "Chmura i infrastruktura"
+mega.services.cloud_desc: "Migracja i zarządzane usługi AWS, Azure, GCP"
+mega.services.data_ai: "Dane i AI"
+mega.services.data_ai_desc: "Pipeliny ML, analityka i platformy danych"
+mega.services.cybersecurity: "Cyberbezpieczeństwo"
+mega.services.cybersecurity_desc: "Audyty, usługi SOC i zgodność z regulacjami"
+mega.services.devops: "DevOps i SRE"
+mega.services.devops_desc: "CI/CD, obserwowalność i niezawodność"
+mega.services.ai_ml: "AI i uczenie maszynowe"
+mega.services.ai_ml_desc: "Inteligentna automatyzacja i modele predykcyjne"
+
+# Mega menu — Industries
+mega.industries.financial: "Usługi finansowe"
+mega.industries.financial_desc: "Płatności, trading i zarządzanie ryzykiem"
+mega.industries.healthcare: "Ochrona zdrowia"
+mega.industries.healthcare_desc: "Platformy zgodne z HIPAA i telemedycyna"
+mega.industries.manufacturing: "Produkcja"
+mega.industries.manufacturing_desc: "IoT, predykcyjne utrzymanie i łańcuch dostaw"
+mega.industries.retail: "Handel i e-commerce"
+mega.industries.retail_desc: "Platformy omnichannel i personalizacja"
+mega.industries.telecom: "Telekomunikacja i media"
+mega.industries.telecom_desc: "Infrastruktura 5G i dostarczanie treści"
+mega.industries.energy: "Energia i utilities"
+mega.industries.energy_desc: "Inteligentne sieci i platformy raportowania ESG"
+
+# Mega menu — Insights
+mega.insights.blog: "Blog"
+mega.insights.ebooks: "E-booki"
+mega.insights.webinars: "Webinary"
+mega.insights.tools: "Checklisty i narzędzia"
+mega.insights.demo: "Demo"
+mega.insights.talks: "Prelekcje"
+mega.insights.opensource: "Open Source"
+
+# Footer links
+footer.cloud_infrastructure: "Infrastruktura chmurowa"
+footer.data_engineering: "Inżynieria danych"
+footer.custom_software: "Oprogramowanie na zamówienie"
+footer.devops_sre: "DevOps i SRE"
+footer.ai_ml: "AI i uczenie maszynowe"
+footer.about_us: "O nas"
+footer.leadership: "Zarząd"
+footer.careers: "Kariera"
+footer.partners: "Partnerzy"
+footer.contact: "Kontakt"
+footer.blog: "Blog"
+footer.case_studies: "Case Studies"
+footer.ebooks: "E-booki"
+footer.webinars: "Webinary"
+footer.opensource: "Open Source"
+
+blog.view_all: "Zobacz wszystkie artykuły"
+
+# Common UI
+ui.read_more: "Czytaj więcej"
+ui.back: "Wróć"
+ui.search: "Szukaj"
+ui.loading: "Ładowanie..."
+ui.page_not_found: "Nie znaleziono strony"
+ui.page_not_found_desc: "Strona, której szukasz, nie istnieje lub została przeniesiona."
+ui.go_home: "Przejdź na stronę główną"
+
+# Services page
+services.hero_label: "Nasze usługi"
+services.stats_areas: "Obszary usług"
+services.stats_engineers: "Inżynierów"
+services.stats_delivered: "Zrealizowanych projektów"
+services.stats_offices: "Biura w Europie"
+services.core_capability: "Kluczowa kompetencja"
+services.all_services: "Wszystkie usługi"
+services.how_we_work: "Jak pracujemy"
+services.lets_talk: "Porozmawiajmy"
+
+# Mobile nav
+mobile.home: "Start"
+mobile.services: "Usługi"
+mobile.case_studies: "Case Studies"
+mobile.articles: "Wiedza"
+mobile.about: "O nas"
+mobile.contact: "Kontakt"

package/starters/lokatech/content/articles/ai-in-enterprise.md

@@ -0,0 +1,51 @@
+---
+title: "AI in the Enterprise: Moving Beyond POCs to Production at Scale"
+type: article
+status: published
+langcode: en
+slug: ai-in-enterprise
+date: 2026-03-21
+fields:
+  category: "AI & Machine Learning"
+  tags:
+    - ai
+    - machine-learning
+    - enterprise
+  author: "Maria Wisniewska"
+  author_role: "Head of AI"
+  author_image: "/static/images/team-maria-wisniewska.png"
+  featured_image: "/static/images/hero-bg.png"
+  excerpt: "Why 87% of enterprise AI projects never reach production — and practical strategies for MLOps, data quality, and responsible AI governance."
+  reading_time: "7 min"
+seo:
+  title: "AI in the Enterprise: Beyond POCs to Production — LokaTech Insights"
+  description: "Why 87% of enterprise AI projects never reach production — and practical strategies for MLOps, data quality, and responsible AI governance."
+---
+
+The enterprise AI landscape in 2026 is defined by a stark paradox: virtually every large organization has an AI strategy, yet industry research consistently shows that 70-87% of AI initiatives never make it past the proof-of-concept stage. The graveyard of impressive Jupyter notebook demos that never saw a production request is vast and growing. The gap between AI ambition and AI reality isn't a technology problem — it's an engineering, organizational, and governance problem.
+
+## The POC Graveyard: Why Promising Models Die
+
+The pattern is painfully consistent. A data science team spends three months building a model that achieves impressive accuracy on historical data. Stakeholders are excited. Then reality hits: the model needs to be integrated with production systems that weren't designed for ML inference. It needs to handle edge cases that didn't exist in the training data. It needs monitoring for drift, retraining pipelines, fallback mechanisms, and explainability for compliance. The data science team that built the model doesn't have these engineering skills. The engineering team that does isn't involved. The project stalls, and the next shiny POC begins.
+
+The solution is structural: treat ML models as software artifacts with the same rigor applied to any production system. That means CI/CD for models, automated testing (including data validation and bias detection), staged rollouts, and rollback capabilities. MLOps isn't optional overhead — it's the bridge between research and value.
+
+## Data Quality: The Unsexy Bottleneck
+
+Every conversation about enterprise AI eventually arrives at the same uncomfortable truth: your models are only as good as your data. Most enterprises have spent years accumulating data without investing in the infrastructure to make it ML-ready. Inconsistent schemas, missing values, stale records, and undocumented transformations mean that data scientists spend 60-80% of their time on data preparation rather than model development.
+
+The organizations making genuine progress have invested in data platforms before AI platforms. Data contracts between teams, automated quality monitoring, data lineage tracking, and governed feature stores transform data from a liability into an asset. It's unglamorous work, but it's the foundation without which every AI project is built on sand.
+
+## Responsible AI: Governance as an Enabler
+
+The EU AI Act is now a regulatory reality, and enterprises that treated AI governance as a future problem are scrambling. But the smartest organizations have recognized that responsible AI practices — bias auditing, explainability, privacy preservation, and human oversight — aren't just compliance checkboxes. They're trust builders that accelerate adoption.
+
+Practical governance starts with an AI registry that catalogs every model in production: what data it uses, who built it, what decisions it influences, and how its performance is monitored. Add automated bias detection in the training pipeline, not as a post-hoc audit. Implement explanation frameworks (SHAP, LIME) as standard model outputs, not optional add-ons. These practices catch problems early and build stakeholder confidence in AI-driven decisions.
+
+## Build vs. Buy: The LLM Question
+
+The explosion of large language models has reshaped the build-vs-buy calculus. Fine-tuning a foundation model is now often faster and cheaper than training a domain-specific model from scratch. But "just add an LLM" is not a strategy. The enterprises getting value from generative AI are those that approach it with clear use cases (document summarization, code generation, customer support automation), robust RAG (Retrieval-Augmented Generation) architectures grounded in their proprietary data, and guardrails that prevent hallucination from reaching end users.
+
+## Practical Recommendations
+
+For enterprises serious about moving AI from POC to production, the path forward is clear: invest in data infrastructure before model infrastructure, hire ML engineers alongside data scientists, implement MLOps from day one rather than bolting it on later, start with high-value use cases where the cost of inaction is measurable, and treat AI governance as an accelerator rather than a brake. The technology has never been more capable. The gap is in the engineering discipline to deploy it responsibly and reliably.

package/starters/lokatech/content/articles/api-gateway-patterns-enterprise.md

@@ -0,0 +1,35 @@
+---
+title: "API Gateways in the Enterprise: Routing, Policy, and the Boundaries We Enforce"
+type: article
+status: published
+langcode: en
+slug: api-gateway-patterns-enterprise
+date: 2026-02-14
+fields:
+  category: "Software Architecture"
+  author: "Tomasz Lewandowski"
+  author_role: "Head of Cloud at LokaTech"
+  author_image: "/static/images/team-tomasz-lewandowski.png"
+  featured_image: "/static/images/hero-bg.png"
+  featured: false
+  excerpt: "Edge gateways versus mesh ingress: authentication, rate limiting, transformation, and when to keep business logic out of the gateway."
+  tags:
+    - api-gateway
+    - apis
+    - integration
+seo:
+  title: "Enterprise API Gateway Patterns | LokaTech Solutions"
+  description: "API gateway design for enterprises: authN/Z, throttling, versioning, observability, BFF vs edge gateway, and avoiding an integration monolith."
+---
+
+An API gateway is the front door to your services: TLS termination, routing, and cross-cutting policies like authentication, rate limiting, and request validation. Done well, it standardizes how clients reach the platform; done poorly, it becomes an **integration monolith** where every new rule requires a risky deployment.
+
+We separate concerns between **edge gateways**—public exposure, WAF, bot mitigation—and internal ingress layers that handle service-to-service routing inside a cluster. The policies differ; mixing them blurs accountability.
+
+Authentication and authorization belong in a coherent model. The gateway can validate tokens and enforce coarse scopes, while services enforce domain-specific rules. When everything is pushed into the gateway “for speed,” teams lose autonomy and debugging becomes opaque.
+
+Rate limiting protects upstreams from abuse and noisy neighbors. We implement limits at multiple layers: per-client keys, per-route budgets, and global protections during incidents. Good limits are observable—teams should see when they are throttled and why.
+
+Transformation at the edge—JSON/XML conversion, legacy header quirks—should be **temporary scaffolding**. Permanent transformation debt hides incompatibilities and slows evolution.
+
+Observability is part of the contract: correlation IDs, structured access logs, and RED metrics per route. If the gateway is a shared dependency, its outages are everyone’s outage—so we run it like a Tier-0 service.

package/starters/lokatech/content/articles/design-system-enterprise-scale.md

@@ -0,0 +1,35 @@
+---
+title: "Design Systems at Enterprise Scale: Governance, Contribution, and Product Velocity"
+type: article
+status: published
+langcode: en
+slug: design-system-enterprise-scale
+date: 2026-01-28
+fields:
+  category: "CMS & Content"
+  author: "Katarzyna Kaminska"
+  author_role: "Head of Design at LokaTech"
+  author_image: "/static/images/team-katarzyna-kaminska.png"
+  featured_image: "/static/images/hero-bg.png"
+  featured: false
+  excerpt: "Tokens, components, and processes that keep dozens of squads aligned—without turning design into a bottleneck or a free-for-all."
+  tags:
+    - design-systems
+    - ux
+    - frontend
+seo:
+  title: "Enterprise Design Systems & Governance | LokaTech Solutions"
+  description: "Scaling design systems: design tokens, component libraries, accessibility, contribution models, and alignment between design and engineering orgs."
+---
+
+A design system is more than a Figma kit. At enterprise scale, it is the **shared contract** between brand, product design, and engineering on how interfaces behave, look, and evolve—across regions, brands, and accessibility requirements.
+
+We ground systems in **design tokens**: color, spacing, typography, and motion expressed as data that can flow to web, mobile, and even email templates. Tokens make rebrands and theme variations mechanical instead of heroic.
+
+Components must be accessible by default: keyboard flows, contrast, labels, and focus management baked into primitives. Accessibility treated as an afterthought becomes expensive rework when auditors arrive—or when users churn silently.
+
+Governance is the uncomfortable part. Without rules, the system fragments; with heavy gates, teams route around it. We use a **contribution model**: clear criteria for core versus team-specific patterns, RFCs for breaking changes, and versioning that communicates impact.
+
+Documentation is part of the product: live examples, do/don’t guidance, and migration notes when APIs change. A component nobody can use correctly is technical debt wearing a design badge.
+
+The payoff is velocity: fewer one-off dialogs, fewer inconsistent forms, faster onboarding for engineers and designers alike. A mature design system does not slow teams down—it removes repeated decisions so teams can spend time on the problems that differentiate the business.

package/starters/lokatech/content/articles/domain-driven-design-bounded-contexts.md

@@ -0,0 +1,35 @@
+---
+title: "Domain-Driven Design: Bounded Contexts as the Antidote to Accidental Complexity"
+type: article
+status: published
+langcode: en
+slug: domain-driven-design-bounded-contexts
+date: 2026-02-26
+fields:
+  category: "Software Architecture"
+  author: "Katarzyna Kaminska"
+  author_role: "Head of Design at LokaTech"
+  author_image: "/static/images/team-katarzyna-kaminska.png"
+  featured_image: "/static/images/hero-bg.png"
+  featured: false
+  excerpt: "How bounded contexts clarify language across product and engineering, where integration patterns fit, and why ubiquitous language is a team sport."
+  tags:
+    - ddd
+    - bounded-contexts
+    - software-design
+seo:
+  title: "DDD & Bounded Contexts in Practice | LokaTech Solutions"
+  description: "Practical domain-driven design: bounded contexts, context maps, anti-corruption layers, and collaboration patterns for complex enterprise software."
+---
+
+Domain-driven design is often introduced with aggregates and entities, but the idea that saves projects is simpler: **the same word can mean different things in different parts of the business**. “Customer,” “order,” and “contract” are not universal concepts—they are contextual, and software breaks when we pretend otherwise.
+
+A bounded context is a linguistic boundary where a model is consistent. Inside it, teams can move fast because terms map cleanly to code. Across contexts, integration must be explicit: translated DTOs, events with versioned schemas, or APIs that do not leak internal invariants.
+
+We use **context maps** as a planning tool—not pretty diagrams for slides, but agreements about upstream/downstream relationships and whether a team is a partner, customer, or conformist to another’s model. Mislabeled power dynamics show up later as production incidents.
+
+Anti-corruption layers sound like overhead until you integrate with a third-party system whose notion of “address” predates Unicode normalization. Translation at the boundary keeps your core model clean and makes replacements possible.
+
+Ubiquitous language is not documentation—it is **behavior**. Product, design, and engineering should refine terms in working sessions and reflect them in tests, UI copy, and API names. When language drifts, the codebase becomes a bilingual mess nobody can refactor safely.
+
+DDD is not an excuse for endless modeling workshops. We timebox discovery, ship thin slices, and revisit boundaries when we learn new constraints. The goal is **clarity under change**, not perfection on day one.

package/starters/lokatech/content/articles/engineering-team-scaling-50-to-200.md

@@ -0,0 +1,33 @@
+---
+title: "Scaling Engineering from 50 to 200: Structure, Communication, and Technical Debt"
+type: article
+status: published
+langcode: en
+slug: engineering-team-scaling-50-to-200
+date: 2026-03-10
+fields:
+  category: "Engineering Culture"
+  author: "Katarzyna Kaminska"
+  author_role: "Head of Design at LokaTech"
+  author_image: "/static/images/team-katarzyna-kaminska.png"
+  featured_image: "/static/images/hero-bg.png"
+  featured: false
+  excerpt: "What changes when informal alignment stops working: team topology, decision rights, design–dev partnership, and keeping quality predictable."
+  tags:
+    - engineering-culture
+    - leadership
+    - scaling
+seo:
+  title: "Scaling Engineering Teams: 50 to 200 Engineers | LokaTech Solutions"
+  description: "Lessons on org design, communication overhead, technical debt trade-offs, and design ops when engineering organizations grow past Dunbar-scale limits."
+---
+
+Growing an engineering organization from fifty to two hundred people is less about hiring velocity and more about **communication physics**. Informal alignment works until it does not; then every recurring misunderstanding becomes a tax paid in rework, meetings, and slow decisions.
+
+We encourage **team topologies** that match business streams: stream-aligned teams with enabling teams for platform and design systems, and complicated-subsystem teams only where deep expertise is truly scarce. The anti-pattern is a matrix where every initiative requires a bespoke coalition.
+
+Design and engineering partnership needs explicit rituals at this scale. Pairing on discovery, shared definition-of-done for UX quality, and **design ops**—tokens, components, and contribution models—prevent “pixel-perfect in Figma, inconsistent in production.”
+
+Technical debt is not a moral failure; it is a portfolio problem. We make trade-offs visible: interest payments (slow delivery), principal (refactors), and risk (outages, security). Leadership’s job is to ensure debt is **owned**, not accidentally compounded by incentives that reward only feature throughput.
+
+Finally, managers and principal engineers must invest in **writing**: architecture decision records, engineering guides, and crisp RFCs. Oral tradition does not scale; neither does Slack archaeology. The organizations that scale well treat internal documentation as part of the product.

package/starters/lokatech/content/articles/event-driven-architecture-microservices.md

@@ -0,0 +1,35 @@
+---
+title: "Event-Driven Microservices: Patterns We Reach For—and the Coupling We Avoid"
+type: article
+status: published
+langcode: en
+slug: event-driven-architecture-microservices
+date: 2026-03-15
+fields:
+  category: "Software Architecture"
+  author: "Tomasz Lewandowski"
+  author_role: "Head of Cloud at LokaTech"
+  author_image: "/static/images/team-tomasz-lewandowski.png"
+  featured_image: "/static/images/hero-bg.png"
+  featured: false
+  excerpt: "From outbox and idempotent consumers to saga trade-offs: how we design event-driven systems that stay understandable as they grow."
+  tags:
+    - microservices
+    - event-driven
+    - architecture
+seo:
+  title: "Event-Driven Architecture for Microservices | LokaTech Solutions"
+  description: "Event-driven microservices at scale: reliable messaging, idempotency, sagas, schema evolution, and observability practices we use with clients."
+---
+
+Event-driven architecture buys you decoupling in time: producers do not need to know which services react, only that the event is meaningful and well-versioned. The cost is **distributed state**—harder reasoning, trickier debugging, and a higher bar for contract discipline.
+
+We default to **outbox patterns** when a business action must be atomic with publishing. Writing to the database and emitting to a broker in one “best effort” step fails under partial outages; the outbox makes publication a durable, retryable step that operations can observe.
+
+Consumers must be **idempotent**. Duplicate delivery is normal, not exceptional. We design handlers around natural keys and deduplication stores where needed, and we avoid implicit ordering guarantees unless the topic contract explicitly provides them.
+
+For long-running workflows, we choose between **choreography** and **orchestration** deliberately. Choreography scales team autonomy until the flow becomes a maze; orchestration centralizes control at the expense of a single failure domain. In practice, hybrid models work best: orchestrate the business saga, choreograph notifications and analytics.
+
+Schema evolution is where teams pay interest on early shortcuts. We treat event payloads as **versioned contracts** with compatibility tests in CI, and we document upgrade paths for consumers that lag behind producers.
+
+Observability closes the loop: trace IDs propagated across async boundaries, metrics on consumer lag, and structured logs that explain *why* a handler skipped work. Without that, event-driven systems feel fast until they become impossible to operate.

package/starters/lokatech/content/articles/future-of-cloud-native.md

@@ -0,0 +1,47 @@
+---
+title: "The Future of Cloud-Native Architecture in Enterprise IT"
+type: article
+status: published
+langcode: en
+slug: future-of-cloud-native
+date: 2026-03-21
+fields:
+  category: "Cloud & DevOps"
+  tags:
+    - cloud
+    - kubernetes
+    - microservices
+  author: "Jan Nowak"
+  author_role: "CTO"
+  author_image: "/static/images/team-jan-nowak.png"
+  featured_image: "/static/images/hero-bg.png"
+  excerpt: "Service mesh evolution, WebAssembly at the edge, platform engineering, FinOps maturity — the trends shaping cloud-native in 2026 and beyond."
+  reading_time: "8 min"
+seo:
+  title: "The Future of Cloud-Native Architecture in Enterprise IT — LokaTech Insights"
+  description: "Service mesh evolution, WebAssembly at the edge, platform engineering, FinOps maturity — the trends shaping cloud-native in 2026 and beyond."
+---
+
+The cloud-native landscape has matured dramatically since the early days of "just put it in containers." In 2026, enterprises are no longer debating whether to adopt Kubernetes — they're grappling with a far more nuanced set of challenges: how to manage sprawling service meshes, when to bet on WebAssembly, and how to make platform engineering a genuine force multiplier rather than another layer of bureaucracy.
+
+## Service Mesh Evolution: Simplification Wins
+
+The service mesh space has undergone a necessary correction. After years of complexity creep — where Istio configurations rivaled the applications they served — the industry is converging on sidecar-less architectures. Ambient mesh implementations that operate at the kernel level using eBPF have reduced the resource overhead and operational complexity that gave service meshes a reputation for being more trouble than they're worth. For enterprises running thousands of microservices, this shift is material: we're seeing 30-40% reductions in mesh-related infrastructure costs and dramatically simpler debugging workflows.
+
+## WebAssembly at the Edge: Beyond the Browser
+
+WebAssembly (Wasm) has broken free from the browser and is reshaping edge computing. The combination of near-native performance, language-agnostic compilation, and microsecond cold starts makes Wasm an ideal runtime for edge workloads that previously required full container infrastructure. We're deploying Wasm-based data transformation and validation logic at the edge for clients in financial services and IoT — processing that happens in 50ms instead of the 500ms round-trip to a regional data center. The WASI (WebAssembly System Interface) standard has matured enough that production workloads are no longer experimental.
+
+## Platform Engineering: The Internal Developer Platform
+
+The most significant organizational shift we're observing is the rise of platform engineering as a discipline. The best engineering organizations are building Internal Developer Platforms (IDPs) that abstract infrastructure complexity while preserving developer autonomy. Done well, an IDP reduces cognitive load — developers ship features instead of wrestling with YAML. Done poorly, it becomes a bottleneck that's slower than the ad-hoc scripts it replaced. The key insight from our work with large enterprises: start with golden paths (opinionated defaults) rather than golden cages (forced workflows). Developers adopt platforms that make the right thing the easy thing.
+
+## FinOps Maturity: From Cost Reporting to Cost Engineering
+
+Cloud cost management has evolved from reactive cost reporting to proactive cost engineering. Mature FinOps practices now integrate cost awareness directly into the development lifecycle — unit cost per transaction, cost per customer, cost per deployment. We're embedding cost metrics alongside latency and error rates in engineering dashboards, making cost a first-class engineering concern rather than a monthly surprise from finance. The organizations getting this right treat cloud spend as an engineering metric, not an accounting exercise.
+
+## Multi-Cloud Standardization: Pragmatism Over Ideology
+
+The multi-cloud debate has settled into pragmatism. Pure multi-cloud portability — write once, run anywhere — remains largely aspirational for stateful workloads. What we see working in practice is strategic multi-cloud: primary workloads on one provider, specific services (like AI/ML on GCP or data analytics on Snowflake) on others, with Terraform and Crossplane providing a consistent provisioning layer. The goal isn't portability for its own sake; it's leveraging each provider's genuine strengths while maintaining enough abstraction to avoid lock-in at the application layer.
+
+The enterprises that will thrive in the next wave of cloud-native are those that resist the temptation to adopt every new tool and instead focus on fundamentals: developer experience, operational excellence, and cost discipline. The technology is mature. The competitive advantage now lies in how well you wield it.

package/starters/lokatech/content/articles/getting-started.md

@@ -0,0 +1,83 @@
+---
+uuid: b2c3d4e5-f6a7-8901-bcde-f12345678901
+title: Getting Started with Barka
+status: draft
+langcode: en
+date: '2026-03-20'
+slug: getting-started
+fields:
+  summary: A step-by-step guide to building your first Barka site.
+  category: technology
+seo:
+  description: Step-by-step guide to getting started with Barka CMS.
+updated: '2026-03-21T16:11:33.000Z'
+---
+
+# Getting Started with Barka
+
+This guide walks you through setting up a Barka project from scratch.
+
+## Prerequisites
+
+- Node.js 20 or later
+- A text editor (VS Code recommended)
+
+## Installation
+
+Create a new project using the CLI:
+
+```bash
+npx create-barka-app my-site
+cd my-site
+```
+
+## Project Structure
+
+A fresh Barka project looks like this:
+
+```
+my-site/
+├── config/
+│   ├── settings.yaml
+│   ├── content-types.yaml
+│   └── section-types.yaml
+├── content/
+│   ├── articles/
+│   └── pages/
+├── themes/
+│   └── starter/
+└── package.json
+```
+
+## Creating Content
+
+Add a new Markdown file to `content/articles/`:
+
+```markdown
+---
+title: "My First Post"
+status: published
+---
+
+Hello from Barka!
+```
+
+## Running the Dev Server
+
+Start the development server:
+
+```bash
+barka dev
+```
+
+Open `http://localhost:3000` and see your content rendered live.
+
+## Building for Production
+
+When you're ready to deploy:
+
+```bash
+barka build
+```
+
+This generates a static `dist/` folder you can deploy to any hosting provider.

package/starters/lokatech/content/articles/headless-cms-composable-architecture.md

@@ -0,0 +1,35 @@
+---
+title: "Headless CMS and Composable DXP: Building Experiences Without Locking the Stack"
+type: article
+status: published
+langcode: en
+slug: headless-cms-composable-architecture
+date: 2026-03-05
+fields:
+  category: "CMS & Content"
+  author: "Anna Kowalska"
+  author_role: "VP of Engineering at LokaTech"
+  author_image: "/static/images/team-anna-kowalska.png"
+  featured_image: "/static/images/hero-bg.png"
+  featured: true
+  excerpt: "Why enterprises adopt headless content platforms, how composable DXPs assemble best-of-breed services, and what to standardize so teams move fast safely."
+  tags:
+    - headless-cms
+    - composable
+    - dxp
+seo:
+  title: "Headless CMS & Composable DXP Architecture | LokaTech Solutions"
+  description: "Enterprise headless CMS and composable DXP: content modeling, APIs, personalization, governance, and integration patterns for multi-channel delivery."
+---
+
+Headless content management separates **content from presentation**: editors work in a structured repository, and channels—web, mobile, kiosks, email—consume content through APIs. That separation is not academic; it is how large organizations ship omnichannel experiences without duplicating workflows in every codebase.
+
+A composable digital experience platform (DXP) goes further: instead of a single vendor suite, teams assemble **specialized services**—search, personalization, DAM, experimentation—connected by APIs and shared identity. The promise is flexibility; the risk is integration sprawl if you do not govern boundaries.
+
+We advise clients to invest early in **content modeling** and workflow: taxonomies, validation rules, preview environments, and roles that match how legal and marketing actually collaborate. A headless CMS with weak modeling becomes a JSON junk drawer; a strong model accelerates both editors and developers.
+
+On the engineering side, caching and **CDN strategy** matter as much as the CMS choice. GraphQL can reduce round-trips; REST can be simpler to cache at the edge. We document SLAs, pagination, and webhook semantics so frontend teams know how to build resilient UIs.
+
+Composable stacks need a **platform layer**: design tokens, component libraries, observability, and security reviews for third-party connectors. Without that, every team reinvents authentication hooks and audit trails differently.
+
+The goal is not maximal vendor count—it is **replaceability**. When a service underperforms, you should swap it without rewriting your entire experience layer. Done well, composable architecture feels boring in operations and exciting in delivery.

package/starters/lokatech/content/articles/kubernetes-cost-optimization-finops.md

@@ -0,0 +1,33 @@
+---
+title: "Kubernetes Cost Optimization: FinOps Practices That Survive Real Clusters"
+type: article
+status: published
+langcode: en
+slug: kubernetes-cost-optimization-finops
+date: 2026-03-03
+fields:
+  category: "Cloud & DevOps"
+  author: "Tomasz Lewandowski"
+  author_role: "Head of Cloud at LokaTech"
+  author_image: "/static/images/team-tomasz-lewandowski.png"
+  featured_image: "/static/images/hero-bg.png"
+  featured: false
+  excerpt: "Rightsizing, autoscaling, spot strategy, and chargeback models—how we align engineering decisions with cloud spend without slowing delivery."
+  tags:
+    - kubernetes
+    - finops
+    - cost-optimization
+seo:
+  title: "Kubernetes Cost Optimization & FinOps | LokaTech Solutions"
+  description: "Practical FinOps for Kubernetes: resource requests and limits, cluster autoscaling, spot instances, observability for waste, and accountable chargeback."
+---
+
+Kubernetes makes it easy to schedule work; it also makes it easy to **pay for idle capacity** disguised as “buffer.” FinOps on Kubernetes starts with honest measurement: per-namespace cost, per-workload efficiency, and trends—not a single monthly invoice nobody owns.
+
+We begin with the basics that still trip teams: **requests and limits** aligned to real usage, vertical rightsizing informed by metrics, and horizontal pod autoscaling driven by meaningful signals—not CPU spikes from JVM warm-up alone.
+
+Node pools and purchasing strategy matter. **Spot or preemptible instances** fit fault-tolerant batch and stateless tiers when interruptions are handled gracefully; mixed pools reduce risk while preserving savings. Cluster autoscaling should be tuned so scale-down is safe and predictable, not a game of whack-a-node.
+
+Chargeback or showback changes behavior. When product teams see cost alongside latency and error budgets, trade-offs become explicit. We avoid punitive models that incentivize hiding workloads; we aim for **shared accountability** with guardrails.
+
+Finally, cost optimization is continuous. New features add sidecars, new regions add egress, new dependencies add data transfer. We bake cost review into architecture checkpoints the same way we review security—because “cheap until it isn’t” is expensive at enterprise scale.

package/starters/lokatech/content/articles/legacy-modernization-strangler-fig.md

@@ -0,0 +1,35 @@
+---
+title: "Legacy Modernization with the Strangler Fig Pattern: A Field-Tested Playbook"
+type: article
+status: published
+langcode: en
+slug: legacy-modernization-strangler-fig
+date: 2026-03-07
+fields:
+  category: "Digital Transformation"
+  author: "Jan Nowak"
+  author_role: "CTO at LokaTech"
+  author_image: "/static/images/team-jan-nowak.png"
+  featured_image: "/static/images/hero-bg.png"
+  featured: false
+  excerpt: "How we incrementally replace monoliths by routing traffic through a façade, carving bounded contexts, and de-risking cutovers with observability."
+  tags:
+    - modernization
+    - strangler-fig
+    - legacy
+seo:
+  title: "Strangler Fig Pattern for Legacy Modernization | LokaTech Solutions"
+  description: "Incremental legacy replacement: routing layers, bounded contexts, data migration strategies, and risk reduction for enterprise modernization programs."
+---
+
+The strangler fig pattern is named after the plant that grows around a host tree: new capabilities wrap the old system until the legacy core can be retired safely. It is the antidote to “big bang” rewrites that stall for years while the business still needs daily changes.
+
+We start by identifying **seams**: customer journeys, APIs, or batch jobs that can be redirected without rewriting the entire domain model. A routing layer—often an API gateway or BFF—lets us send traffic to new services while the monolith continues to serve what remains.
+
+Data is the hard part. We prefer **incremental synchronization** and clear ownership boundaries over dual-writes that silently diverge. Event streams, change data capture, and reconciliation jobs are boring tools that prevent expensive surprises at cutover.
+
+Each slice should deliver user or operator value on its own. If a migration only pays off after the final module moves, teams lose faith and funding evaporates. We ship thin vertical increments: authenticate here, price there, render this read model—each with monitoring and rollback.
+
+Observability is non-negotiable. When two systems answer the same question, we compare outcomes, measure latency budgets, and alert on divergence. Modernization without metrics is hope; with metrics, it is engineering.
+
+The end state is not “microservices everywhere”—it is **a maintainable architecture** aligned to how the business changes. Sometimes that means a smaller, well-factored modular monolith. The pattern is about risk-managed evolution, not fashion.

package/starters/lokatech/content/articles/llm-fine-tuning-enterprise-data.md

@@ -0,0 +1,33 @@
+---
+title: "Fine-Tuning LLMs on Enterprise Data: When It Helps—and When It Hurts"
+type: article
+status: published
+langcode: en
+slug: llm-fine-tuning-enterprise-data
+date: 2026-03-18
+fields:
+  category: "AI & Machine Learning"
+  author: "Anna Kowalska"
+  author_role: "VP of Engineering at LokaTech"
+  author_image: "/static/images/team-anna-kowalska.png"
+  featured_image: "/static/images/hero-bg.png"
+  featured: false
+  excerpt: "A practical look at supervised fine-tuning for domain language, data governance constraints, and the baseline you should beat with retrieval before you train."
+  tags:
+    - llm
+    - fine-tuning
+    - mlops
+seo:
+  title: "Fine-Tuning LLMs on Enterprise Data | LokaTech Solutions"
+  description: "Guidance on when to fine-tune LLMs on proprietary data: evaluation baselines, governance, drift, and how RAG compares for many enterprise use cases."
+---
+
+Fine-tuning large language models on enterprise data can sharpen tone, vocabulary, and task format—but it is not a substitute for **data quality**, **evaluation discipline**, or **access control**. Before we allocate GPU weeks, we insist on a crisp hypothesis: which failure mode does fine-tuning remove that prompt engineering and retrieval cannot?
+
+In regulated environments, the training corpus is rarely “all internal documents.” Legal, privacy, and security teams need **lineage and purpose limitation**: what may enter a training set, how it is de-identified, and how we prove that sensitive payloads never leak into weights or logs. That often pushes teams toward smaller, curated datasets and frequent re-validation.
+
+Technically, supervised fine-tuning shines when you need **consistent structure**—classification labels, JSON-shaped outputs, or domain phrasing that general models mishandle. We pair it with held-out evaluation suites that include adversarial cases and regression checks against prior model versions, not just aggregate accuracy on a static benchmark.
+
+Operationalizing fine-tuned models introduces **MLOps** concerns: versioning datasets and checkpoints, canarying releases, monitoring data drift in inputs, and defining rollback when quality regresses. We treat the model artifact like any other service dependency with an owner, an SLO, and an incident playbook.
+
+In many client programs, we still start with **retrieval-augmented generation** and strong prompting because it is easier to update knowledge without retraining. Fine-tuning becomes attractive once the retrieval stack is mature and the remaining gap is behavior, not facts. Choosing the right layer to optimize saves months of rework.