Hey there
I'm Porosh Islam Tarek
DEV.OS // FULL-SPECTRUM BUILDER // BANGLADESH · UTC+6
Many tools. One responsibility: choose the right ones and build something that lasts.
I'm a Software Developer from Bangladesh, and honestly, I don't like putting myself in a single box. I work across mobile, web, backend, tools, libraries, and whatever the problem demands. If there's a system to build or a complex thing to untangle, I'm interested.
I have a thing for math and logic—not because it sounds cool, but because I genuinely enjoy sitting with a hard problem, breaking it into a clean sequence, and solving it layer by layer. That's probably why I gravitate toward systems that have real structure underneath.
Over time, I've shipped projects across a lot of domains—hotel management, government platforms, academic systems, country-map tools, eBook apps, trade apps, and tracking systems—and helped actual clients get their businesses running from scratch. That ground-level experience taught me more than any tutorial ever could.
Right now, I work with everything from Flutter & Dart on mobile to React, Next.js, and Node.js on the web, and I'm comfortable going deep into Python, Django, databases, cloud, or DevOps when the project needs it. I care a lot about clean architecture, readable code, and solutions that actually scale.
I'm not chasing stacks. I'm chasing well-built things.
Note
The banner above is not a checklist of logos. It represents how I see software: a wide ecosystem of possibilities where engineering judgment matters more than collecting tools.
| 📱 MOBILE Flutter-first product engineering |
🌐 WEB Frontend to full-stack delivery |
⚙️ SYSTEMS APIs, data, architecture & cloud |
🧠 MINDSET Math, logic & structured thinking |
| Base | Chattogram, Bangladesh · UTC+6 | Mode | Builder · Problem Solver · System Thinker |
| Focus | Mobile, Web, Backend, Tools & Libraries | Standard | Clean, readable, maintainable, scalable |
| Comfort zone | Complexity that needs structure | Open to | Products, client builds & collaboration |
| 📱 ACTIVE |
A Flutter-based mobile trading app focused on clean UI, real-time data flow, and a smooth trading experience on mobile.
What I am engineering around: Flutter architecture · Dart · predictable state · real-time screens · clear feedback · mobile performance · polished interaction
Explore Showcase ↗ · Showcase Source ↗ · Release Builds ↗ |
The goal is not merely to make trading screens look good. The goal is to make dense, time-sensitive information feel clear, responsive, and trustworthy on a small screen.
|
🌐 Portfolio: tanz-lake.vercel.app |
🐦 Twitter / X: @taaaanzzzzz |
💡 Most of these were built for real clients—helping them launch and scale their businesses from the ground up. Some client code remains private because professionalism also means respecting ownership and confidentiality
| PRODUCT Turning an idea into useful flows |
ENGINEERING Building the system behind the screens |
DELIVERY Taking work from local code to real use |
OWNERSHIP Caring about the result, not only the task |
╭──────────────────────────╮
│ COMPLEX PROBLEM │
╰────────────┬─────────────╯
▼
╭──────────────────────────╮
│ Understand the full scope│
╰────────────┬─────────────╯
▼
╭──────────────────────────╮
│ Break it into clean │
│ sequences │
╰────────────┬─────────────╯
▼
╭──────────────────────────╮
│ Solve it layer by layer │
╰────────────┬─────────────╯
▼
╭──────────────────────────╮
│ Build something that │
│ lasts │
╰──────────────────────────╯
I love math. I love systems. I love when something complex finally clicks into a clean, elegant solution.
01 / LISTEN Understand the users, business goal, constraints, and actual pain.
02 / MODEL Map the flows, data, responsibilities, integrations, and failure paths.
03 / REDUCE Turn vague requirements into small, testable, buildable decisions.
04 / ARCHITECT Give UI, state, business rules, data, and infrastructure clear boundaries.
05 / BUILD Deliver complete slices—not disconnected screens and unfinished layers.
06 / HARDEN Handle loading, empty, offline, invalid, unauthorized, and error states.
07 / SHIP Deploy responsibly, observe the result, learn, and improve without chaos.
| Principle | What it looks like when I work |
|---|---|
| Clarity before cleverness | I would rather write code another developer can trust than code that only looks impressive in isolation. |
| The problem chooses the stack | I do not force Flutter, React, Django, or Node.js onto work that needs something else. |
| Architecture should earn its complexity | Patterns and abstractions are useful only when they reduce real future cost. |
| Failure is part of the product | Empty, slow, offline, invalid, and failed states deserve the same attention as the happy path. |
| Build in complete slices | A small working flow gives more truth than a large collection of unfinished layers. |
| Leave the system understandable | Naming, structure, commits, and documentation should make the next change safer. |
THE FULL TOOLBOX — VISIBLE, ORGANIZED, AND READY FOR THE PROBLEM
Tools change. The deeper skill is learning a system quickly, choosing deliberately, and staying responsible for the result.
PUBLIC ACTIVITY // BUILD SIGNAL // CONSISTENCY OVER NOISE
|
|
|
|
|
|
|
|
|
|
Stats are generated from public GitHub activity. Language cards describe repository composition—not the limits of my engineering ability.
Good. Those are usually the interesting ones.
BUILD WITH CLARITY · SHIP WITH RESPONSIBILITY · IMPROVE WITH EVIDENCE
Hand-built with Markdown, system thinking, and probably too much care about alignment.






