Let’s start with the basics – who is Jukka Jaakkola?
I’m a software architect with a long background in software development and technology consulting. I enjoy understanding how systems work as a whole and helping teams build solutions that are both technically sound and genuinely useful for the business. I’d say curiosity is a big part of who I am – and that shows up both at work and outside of it.

How did you end up in software development in the first place?
It started with hands-on development. I’ve always enjoyed solving practical problems with code and understanding how systems behave under the hood. Over time I became more interested in the bigger picture – how systems fit together, how technology choices affect teams and organizations, and how architecture can support long-term development. That gradually led me into architecture roles.

What attracted you to Teamit specifically?
It was the combination of strong technical expertise and a very human-centric culture. I like working in environments where experts are trusted and where collaboration and knowledge sharing are genuinely valued. Consulting also offers the opportunity to see different organizations and challenges, which keeps the work interesting. No two clients are the same, and that suits me well.

What does your day-to-day work actually look like?
My work typically involves helping teams design and evolve systems, supporting development practices, and making sure the technical solutions align with business goals. But a big part of the work is also discussion and collaboration. Architecture is rarely about drawing diagrams alone – it’s about helping teams move in the same direction.

Is there a customer situation that has stayed with you as particularly rewarding?
One of the most rewarding situations is when a team moves from uncertainty to clarity. In one project, the biggest challenge wasn’t technology – it was understanding the real problem the system needed to solve. Once we aligned the technical design with the business context, development became much smoother and the team gained confidence in their direction. That shift, when people suddenly feel like they know where they’re going, is what I find most meaningful.

What does a good software architect bring to a customer?
Clarity, above all. That means understanding both the technical landscape and the business context, and helping teams make decisions that are sustainable in the long term. Equally important is enabling the team – architecture should support developers, not slow them down.

What’s a mistake you keep seeing again and again?
Starting from technology instead of the problem. It’s easy to get excited about frameworks or platforms, but architecture should always begin with understanding the business needs and the constraints of the environment. And honestly, once you truly understand the business context, you often realize that the best solution is not the most complex one – it’s the one that fits how the organization actually works.

Let’s switch gears a bit. I hear you’re into analog photography – what draws you to it?
It’s a nice contrast to software work. It’s slower and more physical: you load the film, take the photos carefully, develop the film yourself, and finally print the images in a darkroom. I enjoy both the creative side and the technical side of it. There’s something grounding about a process that can’t be rushed.

You also restore old cameras. What do you find interesting about that?
Old cameras are fascinating mechanical devices. When you repair or restore them, you really learn how precise and elegant the engineering can be. It’s a bit like debugging software — you investigate how the system works, find the root cause of the problem, and bring it back to working condition.

Do you see any deeper parallels between photography and software development?
Yes, actually. Both require a balance between technical understanding and creativity. In photography you think about light, exposure, and composition. In software development you think about architecture, structure, and clarity. In both cases the goal is to create something that works well and lasts. I hadn’t fully articulated it until someone asked me, but the connection feels very real.

What advice would you give to a developer who wants to move into architecture or consulting?
Stay curious and try to understand the bigger picture. Architecture is not only about technology – it’s about people, teams, and business goals. The more perspectives you understand, the more useful you can be. Pay attention to technical debt: learn to recognize it, communicate its impact in business terms, and make conscious trade-offs rather than letting it accumulate unnoticed.

What’s exciting you right now in your field?
I’m interested in how new tools – including AI-assisted development – are changing the way we build software. The pace of change is real. But at the same time, many of the core challenges remain the same: building clear, maintainable systems and helping teams work effectively. New tools don’t eliminate the need for good thinking; if anything, they make it more important.

And where would you like to take your career in the coming years?
I’d like to continue growing in roles where technology, architecture, and people leadership meet – helping teams succeed while building systems that stand the test of time. That intersection is where I feel most at home.

Ah yes. The weekly extinction event. Every week something new is declared “dead” or “out”.

Coding agents are out.
UIs are out.
Vibecoding is out.
Vibedesign is out.
SaaS is out.
Writing is out.
Developers are out.
Designers are out.
Clear roles are out.

The tech industry’s favorite headline right now is “X is obsolete.”

Meanwhile, the work keeps changing shape and moving forward.

The real shift is not about tools

The recent SaaS valuation drops are not just market panic. They reflect something deeper.

For decades, we built software around applications. Business logic lived inside tools. Data was fragmented across dozens of interfaces. Humans orchestrated everything by clicking.

Now the center of gravity is moving.

From app-centric to data-centric.
From human-driven interfaces to AI-driven execution.

Projects like Claude Cowork hint at this shift. Not because they are simply better assistants, but because they bypass the idea that work must happen inside one specific UI.

Instead of humans jumping between dozens of SaaS tools, you get:

A centralized data layer.
Agents that operate across systems.
Workflows executed directly against company data.

When agents interact with data directly, the interface stops being the product. The data layer becomes the product.

That is a massive architectural and economic shift.

So where does that leave designers?

If traditional UIs matter less, does design matter less? Only if you believe design is about screens. In a data-centric, agent-driven world, designers move up a level. We are no longer designing buttons. We are designing behavior.

If agents act on behalf of a company, someone must design what they are allowed to do. When they must ask for confirmation or escalate to a human. How their decisions are made visible and explained. How humans can intervene and guide the system.

That is interaction design at a systemic level.

Design becomes something new.
Designing trust in autonomous systems.
Designing human and AI collaboration.
Designing oversight and accountability.
Designing how data is structured and understood.
Designing competitive advantage through workflow logic.

If everyone has access to similar foundation models, the differentiation shifts to how your data is structured. How your workflows are orchestrated. How your systems behave. This is AI design when interfaces matter less.

These are not engineering-only problems.

These are design problems.

The uncomfortable part

Yes, some traditional UI-heavy work will shrink. If companies rip out dozens of point solutions, there will be fewer dashboards to polish. But the surface area of responsibility grows. We move from:

“How should this modal look?”

to:

“How should autonomous systems behave inside this organization?”

From pixel perfection to system design. That is not the death of design. It is a shift in where design creates value. The real question is not whether designers survive this shift. We just have to ask what is AI design when interfaces matter less.

Everything is not dead. It is just reorganizing.

And if we choose to, we can design the reorganization.

These results reflect a consistently high level of trust and satisfaction. We are proud of our consultants, whose expertise, dedication and everyday professionalism make this possible.

As we do in every survey, in the latest round, we asked the key question: On a scale of 1 to 10

“How likely would you recommend this consultant for similar assignments?”

Average score: 9.7 out of 10
NPS: +92.2

Based on 77 customer responses. Survey conducted between 11/2025–02/2026.

What customers highlighted in their feedback

• Exceptionally strong technical expertise
• Reliability and high quality
• Excellent collaboration and attitude
• A proactive, responsible and solution-oriented way of working

Consultants were described as “a pleasure to work with,” “a gem,” “a valuable part of the team” and “definitely a keeper.”

We are grateful for the trust our customers place in us and proud of the team that earns it every day.

The community is an informal peer group for Teamitians who are enthusiastic about generative AI and want to explore it more deeply together. It provides a space to share experiments, present hobby projects, exchange tools and practical tips, invite guest speakers and collaborate side by side on new ideas.

A peer-driven community like this plays an important role in a rapidly evolving field. Software development is changing quickly with GenAI, and collective exploration helps separate practical value from short-lived hype. By challenging each other and sharing real experiences, we strengthen both individual expertise and our shared capability.

Alongside the community, Teamit continues to offer structured GenAI training for all employees, ensuring that everyone has the opportunity to develop their skills and apply them in client work.

We look forward to seeing what this community builds and learns together.

The idea is simple. During lunchtime sessions, Teamitians share focused insights in short presentations lasting between 5 and 20 minutes. The topics range from client work and practical methodologies to personal areas of expertise and new skills developed along the way.

To kick off the series, Lauri Suomalainen shared how he applied newly acquired facilitation skills to run a strategy workshop for a client. The session offered a concrete example of how continuous learning translates directly into better client outcomes.

Next in line is Patrik Vaskivuori, who will present his approach to testing thousands of API endpoints in a structured and sustainable way. The session focuses on combining scale, quality and practicality in demanding testing environments.

Lightning Lunches are designed to make knowledge sharing lightweight, practical and accessible. By creating space for short, focused exchanges, we aim to strengthen collective expertise and encourage continuous learning across the organization.

Good UX is built on deep understanding. No argument there.

Understanding of the business and its constraints.
Of users, their motivations, habits, and edge cases.
Of the product or service, its history, and its technical realities.
Of the market, competitors, and alternatives people already have.

That kind of knowledge is not optional. It is the raw material of good UX.

And yet, many projects do not start there.

Instead, they start with limited time, partial access to users, unclear data, or an experimental scope that does not justify heavy upfront investment. Sometimes the work is explicitly exploratory: a pilot, a proof of concept, an internal tool, a first step rather than a finished product.

So the question becomes uncomfortable, but unavoidable: Can there be good UX when the foundations are incomplete?

The short answer is yes. But not by pretending the situation is something it is not.

The trap of “doing less UX”

When resources are limited, teams often frame the situation as a trade-off: we’ll do less UX for now.

That framing is misleading.

The problem is rarely the amount of UX work. It is where the effort goes, and what assumptions it quietly bakes in. A rushed project can still spend (or should we say waste) weeks polishing screens that rest on untested decisions. A short experiment can still force users into flows that assume too much certainty.

This requires a shift in mindset. Away from completeness. Away from polish. Towards discernment.

One of the most damaging habits under pressure is acting as if there is a single correct path, simply because ambiguity feels uncomfortable.

When knowledge is limited, pretending to know more than you do often creates more friction later. Rigid flows break when real cases do not fit. Confident outputs invite over-trust. Early decisions harden into “the way it works” long before they deserve that status.

A more honest approach is to design for interpretation instead of certainty.

That does not mean pushing responsibility onto users. It means helping them understand what is known, what is unclear, and what choices they have. It means allowing alternative paths when the situation calls for it. It means using language and structure that reflect confidence levels, not false precision.

This is as true for traditional services as it is for newer, more automated tools. The medium changes, but the risk is the same: oversimplifying reality just to make the design feel cleaner.

Where assumptions hide, and why that matters

Every product or service is built on assumptions. About who it is for. About what information is available. About how people will behave. About what happens when something goes wrong.

With plenty of time and research, many of these assumptions can be tested. Under constraints, they often cannot. That does not make them disappear.

Instead, they surface later as surprises:
rejections that feel arbitrary,
results that look precise but are based on partial input,
behaviour that makes sense to the team but not to the user.

Good UX under constraints does not try to eliminate assumptions. It tries to make them visible enough that they can be questioned, revisited, or worked around.

Sometimes that means stating limits clearly. Sometimes it means narrowing scope rather than broadening it. Sometimes it means designing for reversibility, so early decisions do not trap users or teams.

None of these choices are glamorous. All of them matter.

HOW TO: Decide what failure looks like before you design

• Write a “must-not-break” list
  Not goals, but failure conditions. What would make this experiment unacceptable if it shipped?
• Define a kill-criterion before you start
  “If X is true after five user sessions or one month, we stop.” This is how you avoid sunk-cost UX and endless pilots. This is how you design without pretending you know the answer.
• Use an assumption ledger
  Make a simple list: Our assumption → how we’ll notice it’s wrong → what we’ll change. Cheap, boring, extremely effective. It’s the cheapest form of risk management.

Why the “nice path” is rarely the important one

Time pressure has a predictable effect: teams focus on the ideal flow. The version where everything goes as planned.

But trust is rarely built there.

Trust is built when something is missing. When a request cannot be fulfilled. When the outcome is uncertain or disappointing. When the user hesitates, disagrees, or needs to change course.

In constrained projects, these moments are often dismissed as edge cases. In reality, they are where the quality of the experience becomes visible. Not because the design is perfect, but because it behaves responsibly when things do not go smoothly.

Designing these moments does not require a lot of extra work. It requires deciding that they matter.

HOW TO: Focus effort where learning is fastest

• Do a 30-minute journey map before ideating
  One whiteboard map of the critical path is often worth more than 10 loosely aligned screens.
• Prototype the riskiest moment, not the whole flow
  If the risk is commitment, prototype commitment. If the risk is interpretation, prototype the output and its framing. If the risky moment is “user commits money,” prototype only that. If it’s “AI suggestion shown,” prototype only that output + actions around it. (Sprint logic: prototype only enough to learn.)

Accepting that you don’t know yet. On purpose.

Perhaps the hardest part of working under constraints is accepting that not everything can be resolved upfront.

Good UX in these situations is not about having all the answers. It is about setting up the work so that answers can emerge without causing unnecessary harm along the way.

That might mean defining what would count as failure early.
It might mean choosing a narrow slice of the experience and making it truly usable.
It might mean building something deliberately provisional, knowing it will change.

The right approach often depends on the client, the context, and the risks involved. There is no universal formula. That is not a weakness. It is the nature of the work.

What matters is that the uncertainty is acknowledged, not ignored.

HOW TO: Learn before you invest hard

This is where small teams punch above their weight.

• Use Lightning Demos to steal patterns, not ideas
  Focus explicitly on errors, edge cases, handovers, and unclear states. 6–8 minutes each: “How do others handle errors, eligibility, uncertainty, handover, status?” A lot of good design already exists. This upgrades quality fast.
• Use discount usability methods early
  Expert heuristic review catches obvious issues fast, and 3–5 think-aloud sessions with the team catches the rest.
• Do RITE-style testing
  Fix obvious issues between sessions instead of reporting them later. Don’t wait for a perfect report. If you see a clear problem + fix, change it immediately and continue testing.
• Use a fake-door test before building
  Add the button/menu item for a new thing, measure clicks + intent, but give the users a message “This new thing coming soon!” This saves months of building the wrong thing.
• Measure before you polish
  Run the pilot before polishing the UI. Decide 2–3 signals (drop-off point, retries, edits, “ask for help”) that tell you whether people are confused, stuck, or retrying. You can’t improve what you can’t see.

So, can there be good UX under these conditions?

Yes. But it looks different.

It looks less like a finished product and more like a set of careful decisions.
Less like confidence and more like honesty.
Less like optimisation and more like responsibility.

Good UX under constraints is not about heroics or clever tricks.
It is about making choices you are willing to stand behind. Even when you know they are temporary.

And sometimes, that is exactly what allows the work to move forward.

The discussion moved beyond buzzwords and into practice. What does this shift require from strategy, capabilities and leadership? How do design choices and everyday decisions shape whether AI creates impact or just noise? The emphasis was on experience over theory.

What stood out was the level of engagement. Leaders shared concrete examples, challenged each other’s thinking and built on different perspectives. The conversation surfaced insights that rarely fit neatly into a single session.

Thank you to Software Finland ry and Johtoryhmä-klubi for the collaboration, and to everyone who contributed to the discussion.

Thank you also to the organising and presenting team featured in the photo: Johanna Railio-Hilverink, Ritva Elo, Lauri Suomalainen, Andreas Granqvist, Jaakko Sipari (SOK), Nette Leppänen and Pille Tammejõe.

Generative AI is transforming how we work faster than any technology before it.

Teamit has responded to this shift by developing Ailandai – a technology-agnostic platform that brings agentic AI solutions securely within reach of businesses.

Why Do You Need Your Own Platform?

Many organizations experiment with public AI services like ChatGPT or various Copilot versions. However, these come with challenges: sensitive business data flows through third-party servers, and the solutions don’t understand your organization’s context or processes.

Ailandai solves these challenges. The platform is a containerized solution that can run in your own data center, in a local cloud provider like UpCloud, or in any other cloud environment. This means your data stays exactly where it belongs.

Two Options For Every Need

Ailandai offers two versions for different organizational needs:

Open Vault is an open solution where you can select the best-suited model for each AI agent from over 400 options. This enables optimal cost-performance ratio across different use cases.

Local Vault is a fully local solution where both your company’s data and the AI models run entirely in your own environment. Local Vault was born from our customers’ needs – particularly from defense industry, healthcare, and banking and insurance sector clients with especially strict security and regulatory requirements.

The Power of Agents in Daily Work

AI agents are the heart of Ailandai. They’re not passive chatbots but active tools that integrate with existing systems: SharePoint, Slack, CRM, ERP systems, and many more.

Agents can, for example:

• Search and analyze information from multiple sources simultaneously
• Automate document processing and proposal calculations
• Assist in planning and decision-making
• Serve as an intelligent interface to your company’s knowledge base

Teamit – People Powered by AI

Adopting AI is more about change management than technology. That’s why Teamit has trained its entire staff in using generative AI solutions. Every Teamit consultant knows how to use AI in their daily work – always within the framework of the client’s AI strategy and security policies.

Ailandai’s training program covers four levels from beginner to expert:

1. Associate – Fundamentals for all employees
2. Advanced – Agent design
3. Pro – Implementation mastery, complex applications, performance optimization
4. Expert – Domain expertise, enterprise solution design, mentoring capabilities

Experience Across Multiple Industries

Teamit has implemented agentic solutions in demanding environments: defense industry, manufacturing, construction, and the financial sector. Every implementation is tailored to the customer’s needs. We don’t sell off-the-shelf packages, we build solutions that deliver real business value.

Want to Learn More?

If you’re interested in generative AI and want to discuss how it could benefit your organization, get in touch. We help from strategy to implementation.

Contact:

• [email protected]
• [email protected]

Teamit is an employee-owned IT consultancy founded in 2013. Our team of 60 professionals helps clients with business challenges from strategic planning to implementation. Our customer satisfaction NPS is +96.

GenAI has not changed what good design is. It has changed how quickly bad design is exposed.

Over the past years, we have seen many AI-powered features look great in demos and then fall apart in real use. Usually this has little to do with the quality of the language models. The bigger issue is everything around them.

When AI tools fail, the reason is usually not the AI itself. Real users behave differently than expected. Real organisations have handovers, limits, and unclear ownership. Once AI is introduced, assumptions pile up quickly. What users want, what they trust, what data is available, who maintains the system, and what happens over time all start to matter at once. If those assumptions are weak, AI does not hide the problem. It brings it to the surface.

This is why GenAI raises the bar for design.

AI success is often framed as a technical challenge, but it rarely is just that. Technology sits at the core of AI solutions, but so does design. Design is what decides whether an AI tool is actually useful, whether it saves time, and whether it can grow beyond a small experiment. Without those answers, even the most advanced models struggle to make an impact.

Design that survives reality starts before AI is even part of the conversation. It starts by deciding what we are actually trying to improve. Which process, which situation, and which problem is worth solving first. Only after that does it make sense to ask whether AI can help. Not the other way around.

This leads to some very practical questions. Who benefits from this change? When and how will it be used? What happens when the system is wrong, slow, or unavailable? How does the user understand what the system is doing and why? These questions have always mattered. With AI, you don’t get to skip them. The system will not always behave the same way, and the design needs to take that into account.

Trust is a design problem

Trust becomes a design problem before it becomes a technical one. Users do not trust “AI” by default. They trust systems that are understandable, clear about what they can and can’t do, and honest about their limits. Overpromising intelligence or autonomy is one of the fastest ways to lose that trust.

Unrealistic expectations are another way to quietly kill trust and good ideas. If an AI system is expected to be perfect from day one, with no mistakes and no learning curve, it rarely gets the chance to improve. Most useful AI systems evolve through use, feedback, and iteration.

Good AI design does not try to hide uncertainty, but it does not dump it on the user either. A simple example is how results are presented. Instead of acting as if the answer is always correct, the system can show when it is unsure, offer alternatives, or explain why a suggestion was made. The user does not need to know how the model works, only what they can rely on. When uncertainty is handled in a consistent way, confidence grows over time.

Some problems stay invisible

Not all design problems are loud or obvious. Accessibility and inclusion often fail quietly. AI-generated content can amplify bias, exclude users, or create uneven experiences if accessibility and inclusion are treated as an afterthought.

When interfaces adapt dynamically, accessibility can no longer be handled at the end of the process. It has to be part of the core interaction model. Language choices, tone, user interface, feedback, and error handling all play a role.

Designing for reality, not demos

AI has a way of exposing how an organisation actually works. You cannot add GenAI to a broken service and expect it to fix underlying problems. If the core purpose is unclear, workflows are fragmented, or ownership is vague, AI will only make those issues more visible. In this context, design is not about polishing interfaces. It is about aligning user needs, business goals, and technical realities into something that can be built, tested, adopted, and improved over time.

Practical limits matter more than ever. Token limits, response times, data availability, legal boundaries, and operating costs all shape what is possible. Treating these as part of the design leads to solutions that hold up beyond early demos. The AI-powered services that work best tend to be focused and intentional, because they are designed to function in everyday conditions.

Design that survives reality does not chase tools or trends. It focuses on outcomes, makes conscious choices, and handles edge cases and uncertainty. Getting AI into everyday use is ultimately a human process, not a technical one. As AI becomes commonplace, the real differentiator will not be who uses the latest model, but who designs systems that continue to work once the excitement fades.

The move was a true team effort. We rolled up our sleeves to unpack boxes, organize cabinets and assemble furniture. Pizza helped keep the energy levels up throughout the day. Thank you to all the volunteers who made the transition smooth and efficient.

We celebrated the new office in Lauttasaari with a moving-in party focused on teamwork, friendly competition and getting to know the space. During the evening, we also selected the new Teamit “Spede” and crowned a winning team.

The programme included Speden Spelit-inspired mini-games played in small teams, testing speed, accuracy and coordination. In the kitchen, a DIY cocktail and mocktail station proved popular. Thanks to a bartender-led training session last autumn, the skills were already in place.

Congratulations to Jenni Pajukoski, Katja Onkamo, Jussi Heikkilä and Andreas Granqvist, who were crowned the Spedes of our new office.

You are warmly welcome to visit us in Lauttasaari!