Sonith Manakkat

Software engineering, part 2 of 77 min read12 visuals

How I build small Android apps with AI assistance

A first-person, honest account of designing, building, testing and preparing 24 small offline Android apps with AI tools, what the AI does well and badly, and why a human still reviews everything.

  • One job per app, and the data stays on the phone
  • The AI writes much of the code, a human decides and reviews
  • Tests and review matter more as speed rises

By Sonith Manakkat. Independent personal article, not affiliated with any company mentioned.

Share on LinkedIn

Share
Reading level

In my own time I design and prepare small Android apps for everyday jobs: shops, homes, families and kids. There are 24 so far, prepared end to end and being readied for Google Play. I use AI-assisted development and agents to build them. This is an honest description of how that works, written for curious people and not only engineers. Each section has a picture first and an Expert view with the working details.

The idea: small apps that do one job

Each app does a single, ordinary job: keeping records for a salon, tracking warranties, helping a child practise times tables, planning household chores. Small scope means each app can be finished, tested and explained in plain words. That is the first design decision, and it is mine, not the AI's.

  • 24small Android apps prepared
  • 0ads, accounts or trackers
  • 1job per app
The portfolio at a glance.

Design rule one: the data stays on the phone

Every app stores its data on the phone itself. There is no account to create, no server of mine holding your records, no advertising and no analytics.

data stays hereNo cloud accountAdsNo ads or trackers
Each app keeps its data on the phone. No cloud account, no ads, no trackers.

What you get

  • Privacy by design, nothing to leak from a server
  • Works offline, no sign-up

What you give up

  • No cloud sync across devices
  • You must keep your own backups
A deliberate trade-off.
Expert viewPrivacy as a design constraint

Designing around privacy from the start makes the paperwork honest: each app has a plain privacy policy, and the store's data-safety answers match what the app really does. Practical rules I apply: storage stays in app-private locations, optional features that touch the network are opt-in and explained, text recognition and similar processing runs on the phone, and no analytics or advertising SDKs are included. It also reduces risk: data that is never collected cannot be breached.

My role and the AI's role

What I do

  • Decide what to build and for whom
  • Write the product specification
  • Review every important change
  • Run the release process

What the AI does

  • Write much of the code from my specification
  • Write tests and documentation drafts
  • Make repetitive changes across many files quickly
  • Explain unfamiliar errors
Who does what.
MeThe AI
1MeWrite the briefThe job, the checks, what is out of scope
2The AIDraft code and testsSmall batches against the brief
3MeReview and try itRead the changes, run it on a phone
4The AIFix what I flagRevises with my notes on the page
5MeDecide and releaseOnly a person signs and ships

Takeaway. The AI does the typing, and I keep the decisions.

Who does what in one batch of work. My routine.

The pipeline: from idea to a release-ready app

  1. Idea and scopeOne job, one audience, and what the app will not do
  2. SpecificationScreens, behaviour and edge cases written down before any code
  3. Build with AICode written against the spec, in small batches I review
  4. TestAutomated tests, scripted screen checks and random-input stress tests
  5. Sign and packageBuild the release file and sign it
  6. Store preparationListing text, screenshots, privacy policy and data-safety answers
Six steps for every app.
Expert viewWhy a written specification first

A specification gives the AI something precise to build against and gives me something to review the result against. Without it, an agent fills the gaps with plausible guesses, and plausible guesses are exactly how subtle bugs ship. In practice the spec lists screens, the behaviour of each control, validation rules, empty states and what the app deliberately does not do. Work then proceeds in small batches so a wrong turn is cheap to undo.

  1. 1BriefOne job and a few acceptance checks, written before any code
  2. 2AI draftsA small batch of code and tests, against the brief
  3. 3Tests runAutomated and random-input checks. A failure goes back to the AI
  4. 4Device checkTap through it on a real phone
  5. 5I reviewI read the changes that matter. Anything doubtful goes back
  6. 6ReleaseSign, package and send to a small group first

Takeaway. Every step can send the work back; only a pass moves it forward.

One small batch, from brief to release. This is my own routine, not an industry standard.

Testing is where the quality comes from

AI can write code quickly, and it can write wrong code quickly. So the safety net matters more, not less.

  • Automated unit testsThousands across the apps
  • Scripted screen checksTap-through tests on a phone
  • Random-input stress testsThrow unexpected input at the app to see if it breaks
  • Release verificationA final pass before anything ships
The layers of checking.

The faster code is produced, the more you need tests and review.

Expert viewReading tests, not only running them

An agent asked to make tests pass may find a way that hides a problem, for example by loosening an assertion. So I read the tests as well as the results. Edge cases worth insisting on: empty input, very large values, dates around month ends and time-zone changes, repeated taps, rotating the screen, and restoring from a backup. Stress testing with random input finds crashes that careful hand-written cases miss.

  1. 1Is it too big to read carefully in about ten minutes?Yes Reject it. Ask for smaller pieces.No keep going
  2. 2Did a test get loosened, skipped or deleted to make things pass?Yes Reject it until the reason is clear.No keep going
  3. 3Does it touch something the specification never mentioned?Yes Reject that part, or ask why it is there.No keep going
  4. 4Does it handle money, dates, deletion or stored data?Yes Read every line and test on a real phone before accepting.No keep going
  5. 5OtherwiseAccept it after the tests pass and a quick device check.

Takeaway. Accept what you understood and tested. Send back the rest.

Accept or reject this AI change? My own rules of thumb, asked in this order.

What AI does well, and what it does badly

Well

  • Speed on routine work: screens, forms, repeated patterns
  • Writing many small tests, including edge cases
  • Documentation and store-text first drafts

Badly

  • Confident mistakes, so important claims need checking
  • Judgement about the product: it builds what you ask, even a bad idea
  • Platform rules that change, so I verify them on official pages
An honest ledger.

Tools I use

  • BuildReact Native with Expo and Capacitor, with local Android builds and app signing
  • AutomateGitHub Actions workflows for Android and iOS builds
  • WebA static website on GitHub Pages
  • StoreGoogle Play Console: release tracks, listings, data-safety and content-rating answers
The toolbox.
Expert viewLearning unfamiliar platforms

Much of this was new ground: app stores, signing, release processes. I am comfortable learning unfamiliar platforms, and the AI is a patient guide, but a guide is not a certificate. When it matters, such as a policy or a deadline, I check the official source myself, and I use scripts and the Play developer API to reduce repetitive steps.

Lessons so far

  1. Write the spec firstEverything downstream improves
  2. Work in batchesKeep several tracks moving with honest status
  3. Make privacy a design ruleNot a paragraph in the policy
  4. Invest in tests earlyThey pay for themselves
  5. Review what mattersEven when it looks perfect
Five lessons.

Frequently asked questions

Are the apps on Google Play?

They are being prepared for Google Play. Until a store button appears on the apps page, they are not yet live there.

Do you write any code yourself?

I direct the product, review quality and run the release process. The AI writes much of the code, under my specification and review.

Why no cloud sync?

To keep things simple and private. The trade-off is that you manage your own backups.

Back to all articles