DEV Community: Anzer Ayoob

I Didn’t Want AI to Build My App. I Wanted to Learn How to Build It Myself.

Anzer Ayoob — Thu, 22 Oct 2026 17:03:10 +0000

I was in Class 7 when I first properly touched a computer. My first lesson was simple: how to turn it on and how to turn it off.

After that, the computer was handed over to me.

My friend Tahir Bilal had almost the same experience. We had a teacher, and we still respect that teacher for introducing us to the computer. But what happened afterwards was something neither of us had planned. From the very next day, we started teaching other students what we had learned.

We were not experts. We barely knew the basics. Yet, somehow, we had started teaching ourselves and others without anyone formally teaching us how to learn.

Looking back, I think that was the beginning of something that would take more than a decade to find its direction.

What made us self-learners was not a sophisticated computer laboratory, an expensive course, or access to professional trainers. It was curiosity. We wanted to know what else a computer could do, and every little discovery made us want to explore further.

We waited years for that curiosity to find the right opportunity.

When the ambition was bigger than the resources

By Class 10, I had started imagining that I could write code and build applications of my own. The problem was that there were no accessible coding courses around us, and the Chenab Valley offered very few opportunities for someone with that kind of ambition.

If you lived in a major city, you might have found an institute, a mentor, or someone who could introduce you to programming. For us, the internet was the classroom, and even that classroom was painfully slow.

We were using 2G internet. YouTube was not the learning platform it would later become for millions of people. Finding a useful tutorial, opening a webpage, and understanding a piece of code could take considerable patience.

Around 2009, I began experimenting with websites on Wapka.mobi, a mobile website-building platform that gave beginners like me an opportunity to work with HTML. It allowed me to create websites, experiment with layouts, and gradually understand how the web worked.

I was convinced I was coding.

Then I came across JavaScript tutorials.

Suddenly, what I thought I understood seemed much more complicated. Looking at the code made my head ache. I wondered how anyone could learn to write something that complicated. I had the desire, but I lacked the guidance to cross that gap.

This is an important distinction that people often overlook when discussing talent. A person can have the curiosity and determination to learn something but still struggle because the right resources, explanations, and support are missing.

I did not stop because I had lost interest. I simply did not know how to proceed.

When Wapka eventually shut down its services around 2014–2015, I moved towards Blogger, Google's blogging platform. By then, journalism and activism had also begun to occupy an important place in my life.

In 2014, while I was in Class 11, I was writing press releases about protests we organised over basic public demands, including roads and school buses. Our concerns were local, but we understood that documenting them and communicating them to the outside world mattered.

My journey into journalism and local activism is discussed in my booklet Power of Local Journalism. But the desire to build things independently never disappeared. I wanted my own website, my own platform, and eventually my own applications.

The illusion of being a developer

For years, I tried different platforms that promised to turn ideas into mobile applications without requiring much programming knowledge.

At one point, I got access to a friend's Google Play Console account and uploaded an application I had created using AppsGeyser. I thought I had become an app developer.

Within months, the app or its publishing arrangement was blocked. I never established whether the problem was related to the platform, my application, or something else. What I learned was that creating an application through a website and understanding how an application is built are two different things.

I also tried Android Studio. Repeatedly.

Each attempt ended in frustration. I could not understand the code well enough to make meaningful progress. I would start learning, get stuck, and eventually move on to something else. GitHub confused me, too. I could see that developers were using it, but I could not understand what purpose it served or how it fitted into the process of building software.

I asked friends to develop applications for me. Some agreed, but their commitments and professional lives meant they could not always find the time. That was understandable. They had their own responsibilities, and I could not expect them to put their lives on hold for my ideas.

Hiring a professional developer was not a realistic option either. I did not have the budget.

Meanwhile, the ideas kept accumulating.

I had learned enough about the internet to imagine what I wanted to build, but not enough to build it independently. For years, that gap between imagination and execution remained one of my biggest frustrations.

The turning point came when I stopped waiting

In 2025, some friends introduced me to PowerShell and GitHub and demonstrated some basic operations. I began experimenting with them myself. I used these tools for drafting Right to Information applications and other practical work before gradually moving towards software development.

One decision proved particularly important: I asked a friend who had begun working on an application for The Chenab Times to send me the project files so I could continue the work myself.

My friend Farhat Usman, who is exceptionally capable with technology, had also faced resource constraints. He did not have consistent access to a stable laptop or PC. That made it difficult for him to work continuously on the project.

Another friend, Mohsin Hassan, who is currently at Jammu University, discussed various tools and possibilities with me.

Eventually, I reached a point where I had to make a choice. I could keep waiting for someone to build my ideas, or I could take responsibility for learning how to build them.

There is a saying in our local language that captures this perfectly:

Yo'tam Na Paan Ka'rekh, To'tam Bani Na Ke'in.

In Hindi, the meaning is straightforward: Jab tak khud nahi karoge, tab tak kuch nahi banne wala.

Until you try to do it yourself, nothing is going to happen.

I began coding through PowerShell, working with the project files, and using ChatGPT as a guide. The experience was far from smooth. Early AI-generated code often contained errors, and I did not always know how to identify or correct them.

There were times when a suggested solution introduced another problem. A feature that seemed simple in conversation could become complicated when I tried to implement it in an actual project.

But this time, I had something I had not possessed during my earlier attempts: a way to ask questions continuously, examine alternatives, and work through problems one at a time.

I also had years of experience with website development, prompting, and experimenting with digital tools. Some programming concepts were not entirely unfamiliar to me. I had encountered C++ basics, and Dart and Flutter gradually became more understandable as I worked with them.

I was no longer trying to learn everything before building anything. I was learning by building, and the project itself was becoming my classroom.

AI did not replace my learning. It made learning possible.

I use ChatGPT, Claude, Codex, Replit, and other AI-powered tools. But there is a significant difference between how I approached them and how people sometimes assume AI-assisted development works.

I did not simply ask an AI to build my application and accept whatever it produced.

I wanted to understand how to do things myself.

I would ask how a particular feature worked, where a change needed to be made, why an error was appearing, or how one part of the application communicated with another. For a single feature in The Chenab Times application, discussions could continue for hours.

Sometimes the AI's explanation was wrong. Sometimes its proposed code did not fit the existing project. Sometimes a fix worked in one place but broke something elsewhere. I had to learn to question the answers rather than treat them as instructions that could never fail.

That is one of the most important lessons I have learned from AI-assisted development: the ability to generate code is not the same as the ability to build reliable software.

An application is not just a collection of screens. Its components must work together. Authentication must be handled correctly. Data must be stored and retrieved reliably. Errors must be investigated. Existing features must continue to work after new ones are introduced.

As my projects grew, I realised that I needed to understand not only how to write or modify code but also how to test applications, inspect project structures, work with databases, use version control, review changes, and investigate failures.

GitHub, which once seemed incomprehensible, gradually became a practical part of my workflow. Branches, commits, migrations, testing, and reviewing changes became things I could discuss and work with rather than mysterious terminology.

I also learned that AI tools can confidently suggest the wrong solution. A developer who blindly copies their output is vulnerable to mistakes. A learner who asks why the solution should work, tests it, and investigates when it fails has an opportunity to develop genuine technical judgment.

AI did not remove the need to learn. It gave me a way to keep learning when a human teacher was not available.

Two months, one application, and years of preparation

My determination was particularly evident when I developed ScanPatra V1 in approximately two months.

ScanPatra is a document productivity application built with Flutter. It brings document scanning, OCR, PDF creation, and related utilities into a single workflow, with an emphasis on offline use and local document handling.

Developing it was not simply a matter of generating a few screens. It involved bringing multiple features together, testing how they behaved, identifying problems, and working through technical limitations.

There were difficult moments, but the experience changed how I viewed my own capabilities. Something I had imagined for years was finally becoming a real product that other people could install and use.

ScanPatra eventually reached the Google Play Store. Another application also made it to the store, while Journoist remains under development as I continue building and refining its features.

These are not just three separate projects. They represent different stages of the same journey: from experimenting with simple websites, to struggling with Android Studio, to taking responsibility for real applications.

My work can also be explored through my personal website, "AnzerAyoob.com".

The most important change was not that I suddenly became capable of writing perfect code. I did not. It was that I stopped treating my lack of formal training as a permanent barrier.

Journoist: building for a purpose

Journoist is particularly important to me because it brings my experience in journalism and activism into software development.

The application is intended to provide tools for journalists and activists, including verification and research features and a civic campaign system. Its planned features include campaigns, petitions, and a social publishing format called Drops.

Building such a platform presents challenges that go beyond the visible interface. A campaign system needs appropriate data structures, moderation workflows, and reliable handling of signatures. A social publishing feature needs its own rules for visibility, links, interactions, and moderation. Accounts, permissions, and user roles must behave consistently.

These are the kinds of problems that force a learner to go beyond superficial coding.

I have had to work with Flutter and Dart on the application side, PHP and MariaDB on the backend, Firebase authentication, database migrations, and GitHub-based development workflows. I have also learned the importance of protecting existing functionality while introducing new features.

Journoist is still a work in progress, and I do not consider it finished simply because parts of it run on a phone. A functioning prototype and a dependable public application are not the same thing. It still needs careful testing, security reviews, and continued refinement.

That distinction matters. AI can accelerate development, but it cannot make the responsibility for a product disappear. If people depend on an application, its creator must take its reliability, privacy, and security seriously.

The digital divide is also a learning divide

My experience has made me question the way we discuss technological opportunity in places such as the Chenab Valley.

We often speak about the digital divide as a problem of internet connectivity. Connectivity matters, but the divide goes deeper.

It includes the absence of mentors, affordable training, reliable devices, practical learning environments, and opportunities to experiment without fear of failure. It also includes the difficulty of finding someone who can explain a technical concept in a way a beginner can understand.

For years, I had internet access of a kind, but that did not mean I had meaningful access to programming education.

Artificial intelligence can help reduce some of these barriers. Someone who cannot afford a private coding tutor can now ask questions, request explanations, compare approaches, and receive guidance while working on a real project.

But we should not exaggerate what this means. AI does not provide everyone with a computer, reliable electricity, affordable internet, or the time to learn. Nor does it guarantee that the answers are correct. People still need foundational knowledge, critical thinking, patience, and opportunities to practise.

The promise lies in making technical guidance more accessible, not in pretending that every barrier has disappeared.

Our educational institutions should take this opportunity seriously. Students should not be taught merely to use AI to complete assignments. They should learn to use it to understand difficult concepts, build projects, question answers, test hypotheses, and solve real problems.

A student in a remote village should have a genuine opportunity to learn software development even if there is no coding institute nearby.

That should not be an extraordinary privilege.

The real question is what we do with the tools

There is a growing argument that AI will make programming knowledge unnecessary because anyone can describe an idea and obtain an application.

I disagree with that conclusion.

AI may make some aspects of development easier, but building a useful, secure, maintainable application requires much more than describing an idea. Someone must understand the problem, make architectural decisions, assess the generated code, test the result, and take responsibility when something fails.

At the same time, I reject the opposite argument that AI-assisted development is not real development.

If someone uses AI to learn a programming language, understand an unfamiliar codebase, implement features, debug errors, test changes, and gradually become more capable, dismissing that work merely because AI was involved makes little sense.

The relevant question is not whether every line was typed without assistance. It is whether the person understands the system well enough to make informed decisions and is willing to take responsibility for the outcome.

My own experience is proof that the process can be imperfect and still productive. I began with HTML, struggled with JavaScript, failed to understand Android Studio, became confused by GitHub, and spent years waiting for the right circumstances. Eventually, I found tools that allowed me to continue learning through practical work.

I am still learning. I expect to make mistakes, encounter problems I cannot immediately solve, and discover gaps in my knowledge. That is part of software development, not evidence that the journey has failed.

From a computer in Class 7 to building my own applications

When I think about that first computer in Class 7, I remember how little I knew. I could turn it on and off. Yet that small introduction opened a door that I kept trying to walk through for years.

Tahir Bilal and I began teaching other students the very next day. We did not know where that spirit would lead us. We had no elaborate plan, no roadmap, and no idea how much the technology around us would change.

In the years that followed, I moved between websites, journalism, activism, failed attempts at app development, and long periods of frustration. I did not follow a conventional route into software engineering. I had no formal coding education that could take me from beginner to professional developer in a structured sequence.

What I had was a persistent desire to build something of my own.

Today, AI tools have become guides in a journey that began long before they existed. They have helped me turn curiosity into practical skills and ideas into working applications. But they did not create the curiosity, and they cannot replace the judgment I must continue to develop.

My journey also carries a lesson for anyone who believes that a lack of formal opportunities automatically disqualifies them from learning something difficult. The barriers are real, and determination alone does not solve every problem. Yet the absence of a perfect environment does not mean there is nothing you can do.

Start with what is available. Build something small. Ask questions. Read the code. Test it. Break things. Fix them. Learn enough to recognise when a tool is giving you a bad answer. Then move on to something more ambitious.

Do not spend your entire life waiting for somebody else to build what you have imagined.

I once thought that coding was beyond my reach because I could not understand JavaScript tutorials. Years later, I was working on applications involving mobile interfaces, databases, authentication, and backend systems. The distance between those two points was covered by years of curiosity, repeated failures, self-learning, and eventually the assistance of AI.

I did not need AI to give me a dream. I already had one.

I needed the opportunity to learn how to pursue it.

And that, perhaps, is the greatest promise of these tools: not that they will build everything for us, but that they may help more of us learn to build things for ourselves.

Building an Offline-First Document Scanner in Flutter: Lessons from Creating ScanPatra

Anzer Ayoob — Tue, 04 Aug 2026 17:43:10 +0000

When I started building ScanPatra, I wasn't trying to build another document scanner.

There are already dozens of scanner apps on the Play Store. Many of them do a good job of scanning documents, generating PDFs, and extracting text. So building another scanner app didn't make much sense unless I could solve problems that I personally experienced.

As a journalist, I frequently deal with documents—identity cards, government orders, receipts, handwritten notes, press releases, and contracts. Over time, I realized that I needed a scanner that was fast, organized, privacy-friendly, and didn't stop working just because I lost my internet connection.

That simple idea eventually became ScanPatra.

Why I Chose an Offline-First Approach

One of the earliest decisions I made was that the app should work offline whenever possible.

Scanning a document doesn't really require the cloud. Capturing images, cropping pages, applying filters, rotating pages, generating PDFs, and organizing files can all happen directly on the device.

Keeping these features offline provides several benefits:

Faster performance
Better privacy
Lower server costs
Reliable experience without internet
Instant access to saved documents

Cloud services are useful, but they shouldn't be mandatory for everyday tasks.

The Technology Stack

I chose Flutter because I wanted to build a smooth Android experience while keeping the project maintainable.

The current stack includes:

Flutter
Dart
PHP backend
Firebase Authentication
Google Vision API for OCR
Local document storage
PDF generation
AI-powered document extraction for supported workflows

Some features require internet access, but the core scanning experience continues to work without it.

That separation was intentional.

The Hardest Problem Wasn't the Camera

Initially, I thought document detection would be the biggest challenge.

I was wrong.

The real challenge turned out to be image handling.

Modern smartphone cameras produce extremely large images. Loading multiple full-resolution images into memory quickly increases RAM usage and can lead to slow performance or crashes on lower-end devices.

I spent far more time optimizing image processing than I expected.

Things like resizing images before processing, releasing memory at the right time, and avoiding unnecessary decoding made a noticeable difference.

Users never notice these optimizations directly, but they immediately notice when an app feels slow.

OCR Is More Complicated Than It Looks

Adding OCR sounds easy.

Take a picture.

Extract the text.

Done.

Reality is different.

OCR accuracy depends on many factors:

Lighting
Shadows
Perspective
Blur
Handwriting
Language support

Extracting text is only the first step.

Once OCR finishes, the extracted text needs to be stored efficiently so users can instantly search their scanned documents later.

That searchable experience adds much more value than simply displaying recognized text.

Offline First Doesn't Mean Offline Only

People often assume that offline-first apps avoid cloud services completely.

That wasn't my goal.

Instead, I wanted the app to perform all essential tasks locally while using online services only when they genuinely improve the experience.

Examples include:

AI-assisted document extraction
Advanced OCR workflows
Future cloud synchronization

If the internet disappears, users should still be able to scan documents, organize them, and generate PDFs without interruption.

Performance Matters More Than Fancy Animations

While developing ScanPatra, I realized something interesting.

Users rarely praise beautiful animations.

They do notice speed.

Opening a document instantly creates a better experience than adding elaborate transitions.

Generating a PDF in two seconds is far more satisfying than generating it in six seconds with an attractive loading animation.

Many of the improvements users appreciate are invisible in the interface.

What I Learned

Building ScanPatra taught me several lessons that I'll carry into future projects.

Plan your architecture before adding features.
Keep the core experience simple.
Optimize memory usage early.
Build offline whenever possible.
Solve real user problems before adding new features.

These decisions save a surprising amount of development time later.

What's Next?

ScanPatra continues to evolve.

I'm currently working on improving document organization, enhancing AI-assisted extraction, refining OCR workflows, and adding new productivity features while keeping the app lightweight and privacy-focused.

Every new feature is evaluated with the same question:

Does this genuinely help users, or does it simply add complexity?

That question has guided the project from the beginning.

Final Thoughts

Building a document scanner turned out to be much more than connecting a camera to a PDF generator.

Image processing, OCR, local storage, search, memory optimization, and thoughtful architecture all play an equally important role in creating a good user experience.

Users only see a Scan button.

Behind that button is a surprising amount of engineering.

This is only the beginning of my journey with Flutter, and I'm looking forward to learning from other developers building productivity apps.

If you've worked on similar projects, I'd love to hear about the engineering challenges you faced and how you solved them.