How I work

We start with a structured async conversation — you share the problem, I ask the right questions. I map out scope, constraints, risks, and unknowns before any code is written.

• Requirements document (async-friendly)
• Stack and architecture recommendation
• Risk and dependency map
• Timeline and milestone estimate

A working, minimal slice of the product — enough to validate the core idea and de-risk the main technical bets. No polish, just proof.

• Thin vertical slice (end-to-end working flow)
• Architecture locked in early
• Early feedback loop — iterate before full build
• Clear go/no-go checkpoint

QA is not a phase at the end — it runs the whole time. 13+ years in QA means I write tests as I build, catch edge cases before they ship, and maintain a living test plan throughout.

• Unit and integration tests per feature
• Manual exploratory testing on real devices
• Release quality gate before every build
• Bug triage and severity classification

Production-ready code with full history on GitHub. No zip files, no hand-waving. Play Store submissions handled. Release notes written. Everything documented.

• GitHub repo with full commit history
• Play Store submission (AAB + listing copy)
• Release notes and changelog
• Handover documentation

Post-delivery bug fixes are included for 2 weeks. After that, ongoing support or retainer arrangements available for the right projects.

• 2 weeks post-delivery bug fixes included
• Async response within 24 hours (GMT+7)
• Retainer available for maintained projects
• Clear handover if engagement ends