Verified experience
Front-end experience at HiWeb and Tat Bikeran
Open sourceSoftware Engineer with Deep Frontend Expertise
I combine deep frontend expertise with end-to-end engineering, thoughtful product design, and AI-driven development to create polished, scalable solutions.
Inspectable source
Public portfolio and project source on GitHub
Open sourceBilingual delivery
Portfolio available in Persian and English
Public location
Based in Tehran, Iran
Open source
Selected work
One complete product and two focused examples
Start with the complete product story. Then compare two smaller examples that show different kinds of delivery.
1Real product interface- 1.Real product interface
Flagship case
Quaiz
- Delivered outcome
- Built Quaiz as a Next.js learning application for AI-assisted interactive quizzes and study practice.
- Ownership
- Independent front-end product engineer
Built Quaiz as a Next.js learning application for AI-assisted interactive quizzes and study practice.
OPEN-SOURCE TOOL
create-mohsen-app
Published create-mohsen-app, a CLI for starting Next.js projects with a reusable preferred structure.
Role: Open-source tool author
Inspect create-mohsen-appPRODUCT EXPERIMENT
Thelegroum
Published Thelegroum as a personal web demo with a public repository, live interface, and project screenshot.
Role: Independent web product developer
Inspect Thelegroum
Choose the kind of collaboration you need
Different projects require different levels of ownership, communication, and delivery. Start with the path that best matches your situation.
I want my product built
- Current situation
- The requirement is real, but the first useful scope and implementation path are still unclear.
- Desired outcome
- A working web product with a bounded first outcome and reviewable implementation.
I am hiring for my team
- Current situation
- The team needs a developer who can understand product context and take responsibility for defined web work.
- Desired outcome
- A clear role-fit decision backed by team experience and inspectable work.
I need an implementation partner
- Current situation
- A team or agency has a defined workstream but needs focused implementation capacity.
- Desired outcome
- A bounded implementation contribution that fits the existing repository and review path.
We have an organizational project
Start with the context and one bounded first outcome; fit is assessed after the project is understood.
From a vague portfolio goal to a verifiable product
This portfolio is itself a public case: one real constraint, the options considered, the choice, and its consequence.
- 1Context
The brief was vague: one portfolio had to help business owners, hiring teams, and technical evaluators in two languages.
- 2Constraint
Every public claim must stay inside verified, publishable evidence.
- 3Options
- Duplicate page content
- Publish every database record
- Use a shared evidence contract
- 4Choice
Typed evidence, allowlisted projects, and independent localized narratives.
- 5Consequence
The main message stays concise while technical readers can inspect the implementation policy.
Ownership
What I can own
Three bounded responsibilities, each tied to a concrete deliverable and public evidence.
01
A complete web product
A scoped, usable first release with the core interface, application logic, and an explicit handoff.
Quaiz Next.js build02
A defined feature in an existing product
A reviewable implementation that fits the current codebase, team workflow, and acceptance point.
HiWeb and Tat Bikeran experience03
Focused delivery for a partner team
A bounded implementation stream with visible checkpoints, understandable decisions, and clean handoff.
Inspect this portfolio's source
What collaboration feels like
- 01
A clear boundary
You know the first useful outcome, what is included, and what is still unknown.
- 02
A reviewable version
You see usable progress at agreed checkpoints instead of waiting for a final reveal.
- 03
Understandable decisions
Important choices are explained through their reason, consequence, and trade-off.
- 04
An explicit handoff
You receive the working result plus the context needed to review, continue, or transfer it.
Ways to work together
Choose the path that matches the outcome and responsibility you need.
Defined project
- Best for
- When a product or feature has a clear first outcome.
- What is agreed
- Responsibility, assumptions, and the review point are clarified first.
- What you receive
- A working product surface or feature with an explicit handoff.
Team contract
- Best for
- When an existing product team needs ownership of a defined workstream.
- What is agreed
- Priorities and responsibilities follow the team's active roadmap.
- What you receive
- Consistent delivery inside the existing codebase and team context.
Employment
- Best for
- When you are hiring for a product-focused front-end software engineering role.
- What is agreed
- Role fit is assessed against real responsibilities and product context.
- What you receive
- A clear decision about role fit before the next interview step.
Delivery partnership
- Best for
- When a team or agency needs focused implementation for a defined part of a project.
- What is agreed
- The implementation boundary and decision owner are agreed first.
- What you receive
- A reviewable implementation that can move back into the main delivery stream.
Decision Lab
Make one useful decision before the first call
These tools keep their result in your browser and turn an unclear idea into something concrete enough to discuss.
LAB-01
What is the first useful path for this project?
Build the briefOutput
An editable brief, open questions, and a grounded first step.
LAB-02
Which stack fits this product's constraints?
Compare stack optionsOutput
A provisional comparison with costs, assumptions, and revisit signals.
LAB-03
What should actually make the first release?
Prioritise the MVPOutput
A prioritised feature list you can review and export.
About
Mohsen
I turn a defined product need into a web result you can review. That may be a complete first release, one owned feature in an existing codebase, or focused implementation for a partner team. You can see progress throughout, and the handoff is explicit.
Frequently asked questions
How do I know whether my project is a fit?
A good fit has a real user, a useful first outcome, and someone who can make product decisions. The first brief can still contain unknowns.
Review the product-build fitDo you work on existing codebases?
Yes. We first agree on the feature boundary, review point, and how the change should fit the current team workflow.
See the delivery-partner pathCan we work remotely or across time zones?
Yes. Scope, checkpoints, and reviewable versions keep the work understandable without relying on constant meetings.
Ask about availabilityWhich collaboration models are available?
A defined project, a workstream inside a team, delivery partnership, and employment are all valid paths. Timing and fit are confirmed directly.
Compare ways to workWhat should I send first?
Share the user, current situation, desired outcome, and the part you want me to own. A rough brief is enough to start.
Open the project briefWhat happens at handoff?
The working result is reviewed against the agreed outcome. You also receive the context needed to continue, transfer, or plan the next step.
Review the delivery processDescribe the project or role in a few minutes
A rough brief is enough. Share the current situation and desired outcome; unanswered details can stay unanswered for now.
Free estimate for your project