01
Password Leak Checker
FeaturedWEB · LIVE
Checks whether a password or email has appeared in known data breaches, and rates password strength — the lookup never stores what you type.
✓ Privacy by design — nothing you type into this checker is ever stored.
PythonFlaskBreach APIs
Case study — problem, build & outcome
- Problem
- People reuse the same password everywhere and have no quick way to tell whether it has already leaked in a breach.
- Built
- A Flask backend that queries breach data through external APIs and rates password strength — nothing typed into the checker is ever stored.
- Outcome
- Live and public on Vercel — anyone can run a check right now from the Open Website button below.
- Why this stack
- Python + Flask — the job is one focused lookup: take a check, ask the breach data, send the answer back. A small Flask backend does exactly that, with nothing extra in the way.
- Hard part
- The checker asks for the most sensitive thing a person can type, so it had to be useful without keeping any of it. The fix is in the design, not in a setting: nothing typed into the checker is ever stored — the check runs, the answer comes back, and nothing is written down.
- Trade-off
- Storing nothing means there is no history to go back to — every check stands on its own. That is the deliberate price of the privacy design: privacy first, convenience second.
02
Expense Splitter
FeaturedWEB · LIVE
Splits group expenses fairly: create a group, add members and shared costs, and see exactly who owes whom — with 50 currencies to choose from, picked per group.
✓ Verified test — a 900 expense split three ways settles as exactly two transfers of 300.
PythonFlaskSQLiteChart.js
Case study — problem, build & outcome
- Problem
- Group trips and shared flats end in messy who-owes-whom maths that nobody wants to work out by hand.
- Built
- Flask + SQLite behind it: groups, members and shared expenses, a settle-up algorithm that minimises the number of transfers, and a currency picked per group at creation from 50 Asian currencies.
- Outcome
- Live on Vercel and verified end-to-end: a 900 expense split three ways settles as exactly two transfers of 300.
- Why this stack
- Python + Flask with SQLite — groups, members and expenses are structured records, and the balances are worked out on the server, so a lightweight database behind Flask covers the whole job.
- Hard part
- The settle-up algorithm: a group's balances can tangle into many possible payments, and the goal is to clear them all in as few transfers as possible. It sorts who owes against who is owed and matches them off until every balance reaches zero — the split.py snippet in the Skills section above shows the shape of it, and the verified test in the Outcome row above is it working.
- Trade-off
- Minimising transfers means the settlements don't mirror who originally spent what — someone may end up paying a person they never borrowed from directly. The choice was fewer, cleaner settlements over a payment trail that follows every single expense.
03
DoremanAI
ANDROID · SIGNED RELEASE
A Siri-style, voice-controlled personal assistant for Android — talk to it and it acts: calls, messages, answers and everyday tasks, powered by AI gateways.
Current build is a signed release build.
KotlinJetpack ComposeVoiceAI
Case study — problem, build & outcome
- Problem
- Everyday phone tasks — calling, messaging, quick answers — mean tapping through apps; a voice-first assistant can do them hands-free.
- Built
- Kotlin + Jetpack Compose: common voice commands are handled on-device first, and open questions go to AI gateways the user configures with their own keys.
- Outcome
- Distributed as a signed release through the GitHub releases page.
- Why this stack
- Kotlin + Jetpack Compose, native Android — the assistant's jobs are phone jobs, like calls and messages, so it is built as a native app rather than a web page in a wrapper.
- Hard part
- Routing each request to the right place: simple commands should be handled instantly on the phone itself, while open questions need AI. Common voice commands are handled on-device first, and only open questions go out to the AI gateway.
- Trade-off
- Open questions run through a gateway the user configures with their own key — more setup than a built-in account, but the key and the choice of gateway stay the user's.
04
SUST OR DIE
ANDROID · SIGNED RELEASE
My personal study-planner app: a 60-day study plan with syllabus tracking, Focus Mode, custom alarms and deadline countdowns.
Public signed-release APK download — the source code stays private.
KotlinJetpack ComposeStudy planner
Case study — problem, build & outcome
- Problem
- My own study routine needed one place for the plan, the syllabus and the deadlines — scattered notes were not working.
- Built
- Kotlin + Jetpack Compose: a 60-day study plan with syllabus tracking, Focus Mode, custom alarms, deadline countdowns and an offline routine tab.
- Outcome
- Shared as a public signed-release APK download (7.93 MB) — the app is public, the source code stays private.
- Why this stack
- Kotlin + Jetpack Compose, native Android — this is a personal app that lives on my phone all day, with custom alarms and an offline routine tab, so native is the natural fit.
- Hard part
- Fitting a whole study routine into one place without it scattering again: the 60-day plan, syllabus tracking, Focus Mode, custom alarms and deadline countdowns all had to work together as one app built around my own routine.
- Trade-off
- It is built for one person's routine — mine — so it fits my plan exactly instead of trying to fit everyone. It is shared as a public signed-release APK download, and the source code stays private.
05
IELTS Pathway
WEB · LIVE
A 60-day IELTS preparation planner aimed at Band 7 — 10 hours a day with spaced revision built in, in both Bengali and English, with dark and light themes.
Next.jsTypeScriptBN / EN
Case study — problem, build & outcome
- Problem
- IELTS prep is usually a pile of disconnected resources — no day-by-day path that also schedules the revision.
- Built
- Next.js + TypeScript: a 60-day, 10-hour-a-day plan targeting Band 7 with spaced revision built in, in Bengali and English, with dark and light themes.
- Outcome
- Live and public on Vercel — the full 60-day plan is open to anyone from the Open Website button below.
- Why this stack
- Next.js + TypeScript — the plan is 60 days of structured content in two languages; TypeScript keeps that plan data typed and consistent, and Next.js serves it as a web app anyone can open.
- Hard part
- A day-by-day path alone isn't enough — revision has to be scheduled too, or it never happens. Spaced revision is built into the 60-day plan itself rather than bolted on, and the whole plan runs in both Bengali and English.
- Trade-off
- One fixed path — 60 days, 10 hours a day, aimed at Band 7. The structure that makes the plan followable also makes it demanding, and one size has to fit everyone who follows it.
06
Skill DNA
WEB · LIVE
A GitHub skill analyzer that turns a public GitHub profile into clear skill proof a recruiter can read — what you’ve actually built, not just what you claim.
GitHub APIWebAnalyzer
Case study — problem, build & outcome
- Problem
- Recruiters see claimed skills, not proof — a GitHub profile holds the proof, but it is hard to read at a glance.
- Built
- A web analyzer on the GitHub API that turns a public profile into a clear, readable summary of what someone has actually built.
- Outcome
- Live and public on Vercel — open it from the Open Website button below.
- Why this stack
- Built on the GitHub API — the proof of what someone has built already lives in their public profile, so the analyzer reads that public data instead of asking anyone to type in a list of claimed skills.
- Hard part
- A raw GitHub profile is hard to read at a glance. The work was turning it into a clear, readable summary of what someone has actually built — skill proof a recruiter can scan in seconds.
- Trade-off
- It can only show what is public — private work never appears in it, so the picture it gives is only as complete as the public profile behind it.
07
Asmit MCP Server
PYTHON · OPEN SOURCE
A public Python MCP server that gives AI tools a URL-checking tool — with SSRF protection built in, so a fetch can't be redirected onto an internal address.
✓ Version 0.1.0 — main branch CI green: 28 unit tests pass, ruff clean.
PythonMCPSSRF protection
Case study — problem, build & outcome
- Problem
- A tool that fetches URLs on request has to be careful about where those URLs actually lead — a link can redirect somewhere internal that was never meant to be reached.
- Built
- A public Python MCP server (version 0.1.0) that exposes a URL-checking tool, with SSRF protection built in: the IP is pinned and re-verified at every redirect step, so a fetch can't be steered to an internal address.
- Outcome
- Public on GitHub at version 0.1.0 — main branch CI green, with 28 unit tests passing and ruff clean.
- Why this stack
- Python — the server's job is small and focused: take a URL check, guard the fetch, report back. Python keeps that job direct, and the project is held to a checked standard — 28 unit tests and ruff, both green in CI on the main branch.
- Hard part
- SSRF protection that survives redirects: checking an address once is not enough, because a URL can redirect — and each redirect can point somewhere new. The IP is pinned and verified again at every redirect step, so the check holds all the way through the fetch, not just at the start.
- Trade-off
- Pinning and re-verifying the IP at every redirect step is stricter than a single check up front — the protection wins over the shortcut: safety on every hop, even when it means more checking per fetch.
08
TeamForge
WEB · LIVE
Race-proof team formation for hackathons — built for the Hack4Hack Crew Hiring Challenge 2026 (PS1): 50 people can race for the last seat at the same instant, and exactly one gets it.
✓ Submitted 8 Nov 2026 — frontend live on Vercel, backend live on Railway, with a built-in arithmetic CAPTCHA and security headers.
ReactViteNode.jsExpressSocket.io
Case study — problem, build & outcome
- Problem
- When a hackathon team has one seat left and many people grab for it at the same instant, a normal join flow can hand that seat to more than one person.
- Built
- A React + Vite frontend on Vercel and a Node.js (Express) backend on Railway: teams with invite codes, join requests, a live board over Socket.io, a built-in arithmetic CAPTCHA and security headers.
- Outcome
- Submitted 8 Nov 2026 for the Hack4Hack Crew Hiring Challenge 2026 (PS1) — live now from the Open Website button below.
- Why this stack
- Vite + React for the frontend and Node for the backend — the race is decided on the server, so the backend is where the seat claim has to be made safe; the frontend's job is to stay live while it happens.
- Hard part
- The race-proof seat claim: 50 people race for the last seat at the same instant and exactly one gets it — proven by an automated race test, not just expected to work.
- Trade-off
- Build note: the claim is settled on the Railway backend rather than in the browser — every join has to pass through the one place that can decide the winner, instead of each client deciding for itself.
09
Secret Recipe
WEB · LIVE
A whole-brand website for Secret Recipe Bangladesh: 90 dishes across 13 categories with verified prices, a standalone cake menu, offers, news and blogs, and all 15 outlets — built as one self-contained HTML file.
Honest note — 22 of the 42 cakes are still unlisted (real names and prices still needed), and only 12 photos are original; the rest are labelled illustrative.
HTMLCSSJavaScriptSingle file
Case study — problem, build & outcome
- Problem
- The whole Secret Recipe Bangladesh brand needed one website covering the full menu and every outlet — not a page for a single branch.
- Built
- One self-contained HTML file: 90 dishes in 13 categories with verified November 2026 prices, a standalone Cake Menu, Special Dishes, Offers, News, Blogs, Contact, and all 15 outlets, each with its own phone number.
- Outcome
- Live on Vercel — open it from the Open Website button below.
- Why this stack
- A single self-contained HTML file — the whole site ships as one file with no build step and no backend; the reservation form is front-end only.
- Hard part
- Verifying all 90 dishes and their prices, and all 15 outlets with their own phone numbers — every entry had to be checked, because a wrong price or number would be published as the brand's own.
- Trade-off
- 22 of the 42 cakes are still unlisted rather than filled in with guessed names or prices — the cake menu stays incomplete until the real names and prices are known.
10
Board Rank
WEB · LIVE
HSC 2026 Chattogram Board results with full merit ranks: Science 21,436, Commerce 24,477 and Arts 31,890 students — searchable by name, roll or institute, in Bengali and English.
✓ Rank 1 — Tamzeed Tahseen Reza, 1222 marks · 2,107 students scored GPA 5.00 · 213 institutes.
HTMLCSSJavaScriptSingle file
Case study — problem, build & outcome
- Problem
- Board results tell a student their own marks, but not where they stand — there was no ranked list across the whole Chattogram Board.
- Built
- A static single-file site that loads the full lists and ranks them: all three streams, search by name, roll or institute, individual results with subject-wise marks, and top-institute views, with a Bengali / English toggle.
- Outcome
- Live on Vercel — Science 21,436 · Commerce 24,477 · Arts 31,890 students ranked, across 213 institutes.
- Why this stack
- A single static HTML file — once results are published the data is fixed, so the whole ranking can be served from one file with no backend.
- Hard part
- Ranking 77,803 records across three streams accurately — every student's rank has to come from the full list, in the right stream, with marks handled consistently.
- Trade-off
- It is an unofficial ranking made for students' convenience from publicly available result data — the site itself carries a disclaimer to verify results on the official board portal.
11
Shobdo
WEB · HACKATHON
An accessibility reader for people who see less well or struggle to read: paste Bengali or English text and it reads aloud with word-by-word highlighting, large text and high-contrast themes — everything on-device, in a single 24 KB file.
Submitted to the Ctrl+V Hackathon on 10 Nov 2026. The hosted demo link currently opens a Vercel sign-in page, so the demo video below shows it working.
HTMLCSSJavaScriptWeb Speech API
Case study — problem, build & outcome
- Problem
- Reading long text is hard for people with low vision or reading difficulties, and Bengali text-to-speech support is especially thin.
- Built
- A single 24 KB HTML file on the Web Speech API: read-aloud in Bengali (bn-BD) and English (en-US), word-by-word highlighting as it speaks, and speed, font-size and theme controls — all processing stays on the device.
- Outcome
- Submitted to the Ctrl+V Hackathon on 10 Nov 2026, with a public demo video — watch it from the button below.
- Why this stack
- The browser's built-in Web Speech API — Bengali and English voices already live in the browser, so the whole reader fits in one small file with no server and no API key.
- Hard part
- Word-by-word highlighting in two languages: the spoken word has to light up in Bengali (bn-BD) and English (en-US) alike, alongside speed, font and theme controls, with everything running on-device.
- Trade-off
- Build note: because everything runs on-device in the browser, the voices available are the ones the visitor's own browser and device provide — in exchange, the file stays tiny and nothing ever leaves the device.
12
Chattogram Puja
WEB · IN PROGRESS
A Durga Puja mandap and schedule web app for Chattogram, in Bengali: mandaps, a map and the Puja schedule in one place.
In progress — the hosted deployment still shows a setup-pending notice (the Supabase values are not set yet), so there is no live link yet; the source code below is the current state.
Next.jsTypeScriptSupabaseTailwind CSSLeaflet
Case study — problem, build & outcome
- Problem
- During Durga Puja, Chattogram's mandaps and their schedules are scattered — there is no single Bengali guide to which mandap is where and what happens when.
- Built
- A Bengali Next.js + TypeScript app with Supabase behind it and a Leaflet map: mandap listings, map and schedule sections, styled with Tailwind CSS.
- Outcome
- Build note — in progress: the code is public on GitHub; the hosted deployment still shows setup pending until the Supabase environment values are set.
- Why this stack
- Next.js + TypeScript with Supabase — mandaps and schedules are data that has to be managed and updated, so a database-backed app fits better than a static page; Tailwind handles the styling and Leaflet the map.
- Hard part
- Build note: the remaining step is wiring the live data — the deployment is waiting on its Supabase environment values (URL and anon key) before mandaps and schedules can load for real.
- Trade-off
- Build note: the app depends on Supabase being configured before anything shows — that setup step is still pending, so it is presented honestly as in progress rather than live.
