Build - When something new needs to exist.
New product flows, dashboards, internal tools and web applications where frontend, backend and product decisions have to come together.
ABOUT
Product thinking, hands-on implementation.
I'm Shafin Sadnan, a product engineer and full-stack developer based in Bangladesh. I work remotely with businesses and technical teams to build new digital products, fix production problems, and improve systems that already have users, constraints and history.
I stay close to the implementation: understand the problem, make the trade-offs clear, and then do the work. That can mean a new feature or product flow, a migration or integration, a production bug that needs careful diagnosis, or replacing a dependency without disturbing the system around it.
WHAT I WORK ON
The work usually starts with a real constraint.
Build, fix and improve is useful shorthand for the kinds of problems I take on, but the job is not to force every project into a service box. The job is to understand what the product needs next.
Fix - When something existing is failing.
Production bugs, authentication or integration failures, browser or device issues, and technical debt where adding more code before understanding the cause would make the problem worse.
Improve - When the next change is harder than it should be.
Migrations, dependency replacement, architecture cleanup and focused UX or performance work on products that already have users and operational constraints.
PROOF IN PRACTICE
Real systems come with history.
The engineering work I find most useful is rarely clean-sheet work. Existing products come with dependencies, data, users, business rules and earlier decisions that cannot simply be thrown away. The challenge is often changing the right part without breaking the parts that still work.
01
Tutorliy
Keep the system. Replace the dependency.
For Tutorliy, I replaced an external location-search dependency with a Bangladesh-focused local autocomplete path while preserving the existing MongoDB radius-matching logic underneath.
02
Rifat Academy
Modernize without pretending the legacy system never existed.
For Rifat Academy, the work involved modernizing a legacy WordPress/MariaDB LMS into a custom application while treating data migration, authentication and production architecture as part of the rebuild.
03
DripGym
Turn repeated delivery into a reusable system.
For DripGym, I implemented treatment-specific Shopify pages with reusable Liquid sections, structured-data work and analytics foundations so repeated page delivery did not have to start from scratch.
HOW I WORK
Clarity first. Then the code earns its place.
I want the person I'm working with to understand what is changing, why it is changing, and what trade-offs come with the decision. That matters whether the collaborator is a business owner or another technical team.
- 01Understand the real problem before choosing the implementation.
- 02Keep the solution as small as it can be without making it fragile.
- 03Treat production debugging, migrations and integrations as product work, not side chores.
- 04Communicate trade-offs clearly so the next decision stays easy to make.
I keep learning from official documentation, real project evidence and experienced practitioners, then verify and adapt what is useful to the system in front of me. I would rather test an idea than repeat it because it sounds authoritative.
COLLABORATION
Direct communication, documented decisions, fewer surprises.
I can work directly with an owner who needs a technical problem translated clearly, or alongside an agency, founder or engineering team that already speaks the language. Either way, the useful part is the same: clear scope, visible trade-offs and implementation that can be reviewed. Agencies and consultants can also review the implementation partner page.
I'm based in Bangladesh and work remotely, so communication and handoff need to be explicit rather than assumed.
START A CONVERSATION
Have something that needs to ship, work better, or stop breaking?
Send the problem, current context and what a good outcome looks like. From there, we can figure out the smallest sensible next step.