AWS User Group Kosova, powered by Polymath Services, took the stage at KosICT Tech Festival on 10 October with a session called “Building for Global Scale with Amazon Web Services.” The room was full of students, developers and DevOps engineers, and it didn’t take long for the slides to take second place.
Victor had slides ready, but he opened the floor to questions before showing a single one.
“I think your questions are way more interesting than the slides.”
For most of the session, he was right.
Solve a real problem, and don’t optimize too early
Asked for the biggest mistake he sees in early-stage teams, Victor named two. The first is building something nobody wants to buy, which is easy when you’re an engineer who enjoys building. The second is optimizing too early. “It’s completely fine to put something on a single server and just run it,” he said. The optimizing can come later.
On where good ideas come from, he pointed to combinations: putting together two things that haven’t been combined before, or adding AI to industries that have worked the same way for decades, such as law.
AI changes the job, but judgment still matters
Most of the questions were about AI. Victor said solution architects used to be the human lookup for how a service works (“we were the LLM, so to say”). Today anyone can ask an AI that, so the value moves to judgment: weighing several answers using experience, which AI is weaker at than simply producing an answer. AI has also made architects more hands-on. Rather than only recommending a service, they can now build it and prove it, and AWS expects its solution architects to write more code than before.
For engineers using AI every day, the practical advice was:
- Write down how your project works. Skills files, rules and architecture notes help the AI make fewer mistakes.
- Let agents propose, and let people decide. A bug ticket can trigger an agent that opens a pull request, but a human should review it.
- Keep the setup simple, and keep reading. It is easy to get lazy. As Victor put it, “eventually you stop reading what it writes.”
- Invest in tests. Teams with good tests move extremely fast with AI. Just tell it not to rewrite the tests to make them pass.
- Keep teams small. Beyond roughly 8–10 people, complexity eats the speed AI gives you.
On who is responsible when AI gets something wrong, his view was that it will be shared: the company using the tool for how it is deployed, and the toolmaker for the tool itself, with regulation still catching up. The EU is moving fastest.
Why global scale starts with regions and availability zones
The second half of the session covered the infrastructure beneath the services. Victor explained that AWS talks about regions rather than data centers. A region is a geographic area such as Frankfurt or London, and each one contains several availability zones: groups of data centers with separate power, separate network connections and separate risk profiles. They are linked by redundant private connections, with roughly a millisecond between them, so traffic doesn’t cross the public internet.
Three takeaways stood out:
- Distance is physics. A round trip between Kosovo and Australia takes around 200 milliseconds at best, and up to 300–400 in practice. If you serve customers worldwide, you need to be close to them. You don’t need to host in Kosovo, but you do need to be near your users.
- Redundancy is a judgment call. It costs money. If downtime really matters, build it in. If speed or price matters more, a simpler setup can be the right answer. You can even go down to a dedicated physical host for the lowest latency.
- Not every cloud is the same cloud. AWS runs fully isolated environments, including the AWS European Sovereign Cloud in Germany, for customers whose legal or regulatory needs go beyond a standard region. It also extends outside the data center with on-premises and edge options.
Victor also pointed to AWS’s partner community as one of its strengths. Partners like Polymath Services, he said, use AWS to build solutions for companies, alongside software and hardware companies that build their products on top of it.
Getting started with AWS
AWS has around 300 services, and Victor’s advice to newcomers was not to try to learn them all. Learn the primitives, such as a virtual machine, a load balancer and storage, because those are the same on every cloud. Then build up from there. System-design interview videos on YouTube are a good way to practice.
He was also open about the alternatives. Simpler platforms are easier to start with, he said, but the “easy and cheap” option can become expensive at scale, and many teams eventually come to AWS to help them move. For architecture sense-checks, he pointed the room to AWS Startup Advisor, a set of AI skills you can connect to tools like Claude or Cursor, with the warning that it uses a lot of tokens.
What’s next
The user group now has over 800 members on Meetup, and the goal is to turn that number into an active community. Everything we run is posted on Meetup and in our LinkedIn group.
The next workshop, also powered by Polymath Services, will be hands-on: a speaker from Berlin will show how to build an agentic AI game master on AWS. It runs on Monday, 16 November, at 17:00 CET at the Polymath Services office in Prishtina. Sign up on Meetup. The number of sign-ups helps us decide how big to make the event, so sign up and bring a friend.
Victor also mentioned AWS Days Adria, the Balkan user-group event that brings together close to 1,000 people each year and is heading to Slovenia next. The hope, he said, is to bring it to Kosovo someday.
A big thank-you to Victor for coming to Prishtina, to the organizers for making it happen, and to everyone who showed up with questions. Next time, we’ll need a bigger room.
Join AWS User Group Kosova on Meetup or LinkedIn to hear about the next session first.
