From WAP to AI: 20+ Years of Building Software

ibrahim Kılıç — Thu, 20 Aug 2026 14:46:38 +0000

When I started working as a software developer in 2003, the technology world was very different from what it is today.

There were no smartphones like the ones we use every day. Android didn't exist yet. There was no App Store, no Google Play, and most of the things we now consider normal in software development simply weren't part of our daily lives.

I started with desktop software, but it didn't take long before I found myself working on some very different kinds of projects.

Looking back now, one thing surprises me.

The technology has changed almost completely, but many of the problems we try to solve with software haven't changed that much.

Before Smartphones

One of the interesting projects I worked on in the early years was a driving school simulator.

The project involved a simulated driving environment, and I was responsible for the 3D drawings used in the simulator.

Today, creating 3D content is much more accessible. There are powerful tools, engines, tutorials and huge communities around them.

Back then, things were not quite that easy.

You often had to learn by experimenting, searching for whatever information you could find, and sometimes simply trying something until it worked.

That period taught me something that I still find useful today:

You don't always need the newest technology. You need to understand the problem well enough to build a solution.

A few years later, mobile development became a much bigger part of my work.

And this was before the smartphone era we know today.

WAP, Symbian and Windows Mobile

I worked on a WAP-based ordering application at a time when accessing a business application from a mobile device was still a fairly unusual idea.

Later, I worked with platforms such as Symbian and Microsoft's Windows Mobile.

I also developed applications for mobile devices with barcode capabilities.

The devices were limited.

The screens were small.

Connections were slow.

The user experience was nowhere near what we expect from a mobile application today.

But companies already wanted their employees to be able to do their jobs away from a desk.

That was the interesting part.

The technology was primitive by today's standards, but the business need was already very familiar:

Give people the information and tools they need wherever they are.

That idea eventually became a major part of my career.

Then Android Arrived

When Android started becoming a serious mobile platform, things changed quickly.

I began working on mobile sales applications for field teams.

But the mobile application itself wasn't the difficult part.

The difficult part was everything behind it.

The application had to communicate with enterprise systems. In particular, I worked on integrations with ERP systems such as Logo and Netsis.

A salesperson could create an order from a mobile device, but that was only the beginning.

The customer had to be correct.

The product had to be correct.

The price had to be correct.

The order had to reach the ERP system.

And the information coming back from the ERP system had to make sense on the mobile device.

There were APIs, data synchronization, business rules and plenty of edge cases.

That experience changed the way I think about enterprise software.

The mobile application is only one part of the product. The real product is the business process behind it.

Working on Enterprise Software

Over the years, I also worked on software for larger enterprise and industrial projects.

Some of these projects were related to companies such as Erikli, Unilever and Toyota.

One of the systems I worked on was used to manage processes related to vehicle seat production.

Projects like these are very different from building a small application.

When software becomes part of a production or operational process, reliability matters enormously.

You have to understand what people actually do, not just what the requirements document says they do.

You need to understand the exceptions.

You need to understand what happens when something goes wrong.

And most importantly, you need to understand why the process exists in the first place.

This is probably one of the biggest lessons I have taken from my career:

Good software development starts with understanding the business, not choosing a programming language.

Starting Ekmob

In 2015, I founded Ekmob together with my business partner.

The idea wasn't completely new to me. I had already spent many years working with mobile applications, sales processes, ERP systems and software used by people working outside the office.

We wanted to build something focused on field teams and sales organizations.

At that point, cloud software and SaaS were becoming increasingly important, and mobile devices were becoming a normal part of business life.

But the fundamental problem was still the same.

Salespeople needed information while they were in the field.

Managers needed visibility into what was happening.

Companies needed their sales processes, customer information and other systems to work together.

We started building around those problems.

And, as with most software products, the product changed considerably over time.

Customers change your roadmap.

Technology changes your architecture.

The market changes your priorities.

You have to keep adapting.

Now We Are Talking About AI

And this brings me to where we are today.

AI is probably the biggest change in software development that I have seen since I started working in this industry.

But I think there is an easy mistake to make with AI.

We tend to ask:

Where can we add AI?

The better question is:

Which business processes should become intelligent?

For example, imagine a field sales platform.

Today, it can tell you which customers a salesperson visited, what orders were created and what activities were completed.

But what if the system could also understand the data and help answer a more useful question?

What should the salesperson do next?

Which customer is most likely to need attention?

Which opportunity is becoming more important?

Which customer hasn't been contacted for too long?

What should the salesperson prepare before the next meeting?

This is much more interesting to me than simply putting an AI chatbot inside an existing application.

The real opportunity is to make the software understand the workflow and help people make better decisions.

Looking Back

When I think about the technologies I've worked with, the list feels almost strange now.

WAP.

Symbian.

Windows Mobile.

Android.

ERP integrations.

Mobile applications.

Cloud.

SaaS.

And now AI.

Some of those technologies have almost completely disappeared.

Others have evolved into something very different from what they were when I first used them.

But there is one thing that hasn't changed.

People still want software that makes their work easier.

Companies still want their systems to work together.

And developers still have to understand what the customer is actually trying to accomplish.

That's probably why I still enjoy building software after more than 20 years.

The technology keeps changing.

There is always something new to learn.

But the basic question remains surprisingly simple:

How can we use technology to help people and businesses work better?

That's the question I started with in 2003.

And it's still the question I'm asking today.

SoftwareDevelopment #AI #Technology #SaaS #MobileDevelopment

DEV Community: ibrahim Kılıç