OpenResearch

Every commit should be potentially deployable. CI/CD makes that possible.

What a solid pipeline includes:

🧪 Automated tests on every push
🔍 Static analysis and linting
🔒 Security scanning
📦 Consistent build artifacts
🚀 Automated deployment to environments

Fast feedback is crucial. If your pipeline takes an hour, developers won't run it often enough.

Jenkins, GitHub Actions, GitLab CI, Azure DevOps - the tool matters less than the practice.

Start simple. Add stages as you need them. A basic pipeline that runs is better than a complex one that doesn't.

The goal: confidence that what you're deploying works. Catch issues before users do.

How fast is your pipeline?

We're halfway through the year. How are you really doing?

Time for some honest reflection.

Questions worth asking right now:

📊 Are your key projects on track?
🎯 Did Q1 and Q2 deliver what you expected?
👥 How is your team's morale and capacity?
💡 What did you learn that should shape H2?
🚧 What's blocking your biggest priorities?

At OpenResearch, we do regular retrospectives - not just on projects, but on how we work. Small adjustments now prevent big problems later.

The best time to course-correct is before you're too far down the wrong path.

What's the most important lesson your team learned in the first half of this year?

We've just published the recording of our Mobile Meetup talk on The Composable Architecture (TCA).

A big thank you to Andreas for sharing a practical introduction to TCA.

The talk was originally presented at our Mobile Meetup on the 10th.

🎥 Watch here: https://www.youtube.com/watch?v=QCvmKfC2oHI

AI is everywhere. But running it in production is different from demos.

What practical AI deployment looks like:

🎯 Clear problem definition - AI isn't magic
📊 Data quality matters more than model complexity
🔄 Continuous monitoring for model drift
⚡ Inference optimization for latency and cost
🔧 MLOps for reproducibility and deployment

The gap between Jupyter notebook and production is enormous. Versioning, monitoring, scaling, updating - these are engineering problems.

Open source tools help: MLflow for tracking, Kubeflow for orchestration, ONNX for interoperability.

Start with simpler models. Understand the problem deeply. Complex models aren't always better.

AI augments human decisions. It rarely replaces them entirely. Set realistic expectations.

Where are you using AI in production?

Go doesn't try to be everything. It tries to be excellent at a few things.

And for backend services? It absolutely excels.

Why Go has become a staple in our toolkit:

⚡ Fast compilation, fast ex*****on
🧵 Concurrency that makes sense (goroutines)
📦 Single binary deployment: no dependency hell
🔧 Opinionated simplicity that scales with team size
🛡️ Strong typing without verbosity

We use Go for high-performance services, CLI tools, and anything where operational simplicity matters.

It's not the right choice for everything. Sometimes Java's ecosystem matters more, sometimes Python's libraries win. But when Go fits, it really fits.

Has your team adopted Go? What's been your experience?

Docker packages applications. Kubernetes runs them at scale.

What Kubernetes handles:

🔄 Automatic scaling based on demand
🔁 Self-healing: restart failed containers
🚀 Rolling deployments with zero downtime
🔧 Service discovery and load balancing
📋 Declarative configuration - desired state, not procedures

The learning curve is steep. Concepts multiply: pods, services, deployments, ingress, configmaps, secrets.

But for systems that need reliability at scale, Kubernetes delivers. The ecosystem is vast. The community is active.

Use managed Kubernetes (EKS, AKS, GKE) unless you have strong reasons not to. Running your own control plane is a job in itself.

Not every application needs Kubernetes. But for complex distributed systems, it's the standard.

Where are you on your Kubernetes journey?

Every codebase accumulates cruft. The question isn't whether it will happen. It's what you do about it when it does.

Refactoring is often postponed because it feels risky. "If it works, don't touch it." But that technical debt compounds over time.

How we approach refactoring safely:

🧪 Tests first: you can't refactor without a safety net
📦 Small, incremental changes over big rewrites
🔍 Understand before changing
📊 Measure the impact
🤝 Code review everything

The goal isn't perfect code. It's code that's easier to work with tomorrow than it was today.

We've helped companies modernize decade-old systems without losing functionality or customers. It's methodical work, but it's worth it.

What's the oldest code your team is still maintaining?

🚀 Join us for the next OpenResearch Meetup: Mobile Development
📍 OR Office, Prishtina
📅 June 10th
⏰ Door open from 18:00

We’re bringing together mobile developers, iOS enthusiasts, and tech professionals for an evening of practical insights, modern Apple ecosystem discussions, and networking over pizza & drinks.

🎤 Talks

18:30 TCA – The Composable Architecture by Andreas: An alternative approach for building clean, scalable, and modern native iOS applications using The Composable Architecture.

19:00 Beyond the Apps by Ermal: Widgets. Live Activities. Dynamic Island. Notifications. App Intents. A deep dive into the iOS surfaces most apps ignore - and how they turn your app into something users see, glance at, and use without ever tapping the icon.

19:30 Apple Intelligence – The Next Era of Smart Apps by Armend: On-device AI. Writing Tools. App Intents. Siri evolution. A practical look at how Apple Intelligence is reshaping app experiences, developer possibilities, and the future of the Apple ecosystem.

🍕 20:00 – 21:00 Networking, Pizza & Drinks

Whether you’re an experienced mobile engineer or just curious about where the Apple ecosystem is heading, this meetup is a great opportunity to learn, connect, and exchange ideas with the local tech community.

Please register with Armend under ✉️ [email protected].

Looking forward to seeing you there! 🙌

If you haven't looked at .NET recently, you're missing out.

What modern .NET delivers:

⚡ Performance that competes with Go and Rust
🌍 True cross-platform: Linux containers, ARM, everywhere
📦 Minimal APIs - less ceremony, more productivity
🔥 Hot reload during development
☁️ Cloud-native by design
NET 8+ brought native AOT compilation. Startup times dropped dramatically. Memory footprint shrank.

ASP.NET Core handles millions of requests per second. Benchmarks put it near the top.

The tooling matured. The ecosystem grew. The community expanded beyond Windows shops.

For new projects, modern .NET deserves consideration regardless of your current stack.

What's your impression of .NET today?

A well-designed API is invisible. Developers just use it and it works.

A poorly designed API? That's where the complaints, workarounds, and technical debt begin.

Principles we follow for API design:

📝 Consistency above all else
🎯 Clear naming that explains itself
🔍 Predictable error handling
📖 Documentation that stays current
🔄 Versioning strategy from the start

Whether it's REST, GraphQL, or gRPC, the principles remain the same. Make it easy for consumers. Make it hard to use wrong.

We've built APIs that power mobile apps, connect enterprise systems, and enable third-party integrations. The investment in good design always pays off.

What makes an API great in your experience?