|
I'm a Mobile Application Developer with ~1.8 years of hands-on experience building production-ready apps in Flutter. I care less about writing code that just works and more about writing code that survives contact with real users, real edge cases, and the next developer who reads it — which is usually future me. I'm currently working at Alabtechnology, building and shipping Flutter applications end-to-end — from architecture decisions to the pixel-level polish that makes an app feel finished. me:
role: Mobile Application Developer
focus: Flutter · Dart · Clean Architecture
experience: 1.8+ years
currently_at: Alabtechnology
based_in: Chennai, India
mindset: "ship it clean, or don't ship it"
|
|
This is the part most profiles skip — but it's the part that actually matters when you work with someone.
graph LR
A[🧭 Understand<br/>the problem] --> B[🏗️ Design the<br/>architecture]
B --> C[🧩 Break into<br/>small tasks]
C --> D[⚙️ Build with<br/>tests in mind]
D --> E[🔁 Handle the<br/>unhappy paths]
E --> F[👀 Self-review<br/>& refactor]
F --> G[🚀 Ship &<br/>communicate]
G -.feedback.-> A
style A fill:#8A2BE2,color:#fff,stroke:none
style B fill:#6A0DAD,color:#fff,stroke:none
style C fill:#4B0082,color:#fff,stroke:none
style D fill:#483D8B,color:#fff,stroke:none
style E fill:#2C5364,color:#fff,stroke:none
style F fill:#203A43,color:#fff,stroke:none
style G fill:#0F2027,color:#fff,stroke:none
|
Before writing a single widget, I map the architecture — usually Clean Architecture with clear data/domain/presentation layers. Costs more time on day one, saves days later. |
Every feature gets decomposed into small, testable commits. I'd rather ship five focused PRs than one 800-line "trust me, it works." |
|
Offline states, error states, empty states — designed from day one, not patched in after QA finds them. |
I don't call something "done" until I've actively tried to break it myself — not just run the happy path once. |
|
Clear commit messages and comments so the why survives — for teammates, and for future me. |
I'd rather raise a risk on day one of a sprint than surprise everyone on the last day. |
|
If I touch a file and see a clear improvement, I make it — small deliberate cleanups over a "someday" rewrite. |
A feature that looks great in a demo but breaks on a slow network or old device isn't finished yet. |
"Code is read far more often than it's written — so I write for the reader, not just the compiler."
|
Do-it — a fast, lightweight, beautifully designed Todo app.
|
A feature-rich Recipe Book app built with Clean Architecture.
|
⚙️ This animates automatically once the snake GitHub Action is set up (instructions below) — it eats your contribution graph.
I'm always open to interesting Flutter projects, collaborations, or just talking shop about clean architecture and mobile UX.