The Problems Companies Admit They Have

I found Itewiki because I wanted to understand what kind of Finnish technology companies were there. It looks like the sort of website I would normally open, scan for five minutes and forget: a directory of software companies, consultants, agencies, technologies, references and job listings.

At first I treated it exactly like that. I searched for AI companies, interface design, public-sector work and anything that might be relevant to HAAM. I wanted names. Which companies are doing unusual work? Which organisations might need help? Is there an Estonia-Finland connection hidden somewhere in the profiles?

Then I realised the company list was probably the least interesting part of the site.

The more useful data was the problems.

Every reference page begins with a supplier trying to prove that it is competent. This is marketing material. The structure is usually familiar: a client had a problem, the supplier understood it, a solution was built, the client was satisfied. The uncertainty, internal disagreement and failed attempts have mostly been removed by the time the story is published.

But even after the story has been cleaned up, the original problem is still visible.

A festival needed an application that would continue working when the mobile network became unreliable under the load of more than 200,000 visitors. A road-maintenance company needed to turn images and field data into a usable view of road conditions. A business was still receiving orders through email, PDFs, Word documents, spreadsheets and images, then moving the information into an ERP system. A city needed better pedestrian and traffic data without continuing to count everything manually. These are not abstract digital-transformation ambitions. They are specific moments where an organisation's existing way of working stopped being good enough.

That changed how I read the site.

Instead of asking which Finnish companies do AI, I started asking what Finnish organisations are currently willing to describe as an AI problem. The difference is surprisingly large. The company category produces a list of suppliers using roughly the same language. The reference category produces a list of broken handoffs, expensive routines, inaccessible services, missing data, overloaded networks and people copying information between systems.

The suppliers describe capabilities. The references describe friction.

This may be obvious to anyone who works in sales or procurement, but I had not really thought about a public case-study directory as a dataset before. One case study is a piece of promotional writing. Hundreds of case studies begin to form a partial map of the economy. They show which kinds of work receive budgets, which technologies have moved from demonstration to operations, which organisations buy outside help and which problems are legible enough to be turned into projects.

The word partial matters. Itewiki is not a neutral observatory. Companies submit much of the information themselves. Paid profiles can receive more visibility in the normal search results, although the site also provides an independent-search option that removes the paid-profile boost. Successful projects are much more likely to be published than failures. Some industries document their software work constantly while others remain nearly invisible. The resulting map is distorted.

But distorted maps can still reveal things.

The Pori Jazz case is a good example. Read as a supplier reference, it says that Moods built a progressive web app using Svelte. Read as a problem, it says something more interesting about festivals. A large cultural event briefly becomes a city. Tens or hundreds of thousands of people arrive, schedules change, infrastructure is stressed and the ordinary assumption of continuous connectivity stops being safe. The product is not merely a programme guide. It becomes temporary public information infrastructure.

That is a different way of understanding cultural technology. Festival websites and applications are often treated as marketing surfaces around the real event. The case suggests that the digital layer is part of the event's operational resilience. It has to remain understandable and available precisely when the physical gathering makes the network less dependable.

The ScanwAi reference works in a similar way. On the surface, it is an AI success story about automating road-network analysis. Underneath it is a problem of translation between a physical environment and institutional action. Roads deteriorate continuously, but maintenance decisions are made through budgets, inspections, reports, priorities and interfaces. The interesting system is not only the computer vision model. It is the chain that turns a damaged road into data, the data into a shared assessment, and the assessment into a decision that someone can fund and carry out.

This is where a lot of supposedly digital work becomes much larger than the interface. A screen may be the visible surface, but behind it are regulations, data quality, procurement, old software, internal responsibilities and people who have learned to compensate for systems that do not quite connect.

The Odoo order-processing case makes the same point from another direction. An AI agent reads orders arriving through several document formats and transfers them into an ERP system. It sounds like a small automation. It also reveals how much of the economy still runs through semi-structured messages and attachments. The polished ERP is not the whole operating system of the company. The real operating system includes email, documents, customer habits, exceptions and employees interpreting what someone meant.

The agent enters at the seam between those worlds.

This may be why case studies are more useful than capability pages when trying to understand AI. A capability page has to speak broadly. It says that AI can improve efficiency, support decisions or create better customer experiences. A case study has to contain enough specificity to be believable. It accidentally tells you where the organisation's structure is loose enough for an agent to enter.

Sometimes the agent enters where a person repeatedly copies information. Sometimes it watches security feeds. Sometimes it prepares data for a future system that does not yet exist. Sometimes the supposed AI project is mostly a data-governance project, an integration project or an organisational-change project with AI added near the end.

Seen this way, the directory becomes a record of what companies admit they cannot currently do smoothly.

The word admit is slightly unfair. These organisations are often presented as progressive for recognising the problem and paying to improve it. The problem is also carefully framed so that the supplier's solution appears inevitable. Still, public references expose more operational detail than most organisations would ever publish in an annual report. They tell us that orders arrive in incompatible formats, roads are not inspected efficiently, networks may fail during events, metadata is not ready, internal systems do not communicate and employees spend time repairing the gaps.

Marketing requires a problem before it can present a solution. That requirement produces data.

There is another layer in the named recommenders. A case study sometimes includes the person who publicly endorses the supplier, along with a role and organisation. This turns a technical reference into a relationship graph. It shows not only who bought what, but who was close enough to the work to attach their name to it. For someone doing sales research, that may be more valuable than a generic list of executives scraped from LinkedIn.

It also makes the site feel slightly like an archaeological layer of procurement. Projects leave traces. A buyer, a supplier, a technology, a date, a problem and sometimes a person remain connected on a public page after the project team has moved on. If enough of those traces are collected, you can begin to see recurring patterns: public organisations struggling with accessibility, industrial companies trying to make maintenance data usable, cultural institutions building temporary infrastructure, and businesses placing AI agents between messy incoming information and rigid internal systems.

The obvious commercial use would be to turn this into lead generation. Find an organisation that has already bought one digital system, inspect what was built and approach it with another service. That is probably already happening. The more interesting use might be to build a problem index rather than a company index.

A company index begins with categories such as AI, React, UX, ERP or cybersecurity. A problem index might begin with sentences: information has to survive a network failure; field observations do not reach decision-makers quickly enough; regulation has created a reporting burden; customers send the same business object in five incompatible formats; staff cannot tell whether an automated process actually completed; a public service technically exists but remains difficult to use.

Those descriptions cut across industries and technologies. The same underlying problem may appear in a festival, a hospital, a factory and a city department, even when the purchased solutions have different names.

This is close to how I have been trying to think about HAAM. Not as a company that begins with a predefined deliverable, but as something that looks for important problems falling between design, technology and operations. Itewiki is interesting because its references are full of exactly those boundaries. The suppliers usually present the work as a completed category: an AI system, a mobile application, an integration or a website. The underlying problem often refuses to stay inside the category.

I am not sure whether scraping the whole directory would be useful. More data could easily produce a larger list without producing more understanding. The valuable part may be the slower work of reading cases, rewriting each one as a problem statement and noticing which problems recur under different technologies.

There is also a legal and ethical distinction between information being publicly visible and being open data. Itewiki has built and maintained the structure that makes these relationships searchable. Public access does not automatically mean that someone should copy the entire database and republish it as a competing product. A personal research tool or a derived analysis is not the same as cloning the directory.

The more interesting question is probably not how much of the data can be extracted, but what changes when it is read from the opposite direction.

I arrived looking for companies. I found a catalogue of things that were not working.

Even that catalogue is selective. It contains problems that received budgets, found suppliers and ended well enough to become marketing. The failures that never became projects are missing. So are the problems that organisations have normalised so completely that nobody thinks to name them.

Those may still be the more important problems.

I do not yet know whether the strongest signal is what companies admit they had to fix, or what never becomes a case study at all.

Connected reading

• The Interface as an Archaeological Site
• The World Runs on Companies You Have Never Heard Of
• The Smart City Breaks Between the Systems
• Every Interface Contains a Business Model
• The Product Is Becoming an Organization

AI authorship note

This essay began with Kris Haamer exploring what free data could be found on Itewiki and asking what might be interesting for his work. AI supported the live source research, identification of case-study patterns, drafting, editing and implementation. Kris selected the Raw Drafts angle, connected it to HAAM's interest in problems between design, technology and operations, and approved the article for publication.