This is a very viable marketplace idea, but I would not position it simply as “Uber for TV repair.” The difficult part is not building the Laravel + Flutter software. The difficult part is building the operational, trust, logistics, pricing, payment, technician-quality, and dispute infrastructure around it.
The client already has a strong starting advantage: 5 shops + 35 technicians + existing repair demand. That gives you the seed supply for the marketplace, which is usually the hardest part of this kind of business.
Think of it as a managed repair marketplace.
Customer opens the app:
-
Selects device:
- TV
- Refrigerator
- AC
- Washing machine
- Microwave
- etc. — potentially later
-
Selects problem:
- Doesn't turn on
- No display
- Sound problem
- Broken panel
- Remote problem
- Water leakage
- etc.
-
Enters location.
-
Chooses:
- Home service
- Pickup/drop-off
- Shop service
-
Uploads photos/video if useful.
-
Gets an estimated price/range or requests diagnosis.
-
Nearby registered technicians receive the job.
-
Technician accepts.
-
Customer can see technician information and ETA.
-
Technician diagnoses/repairs.
-
Customer approves additional cost if required.
-
Customer pays through the platform.
-
Platform deducts commission.
-
Technician receives balance.
-
Customer rates technician/service.
Don't make the initial system purely:
Customer → nearest technician → job
Instead:
Customer → job request → technician matching → acceptance → diagnosis → quote → approval → repair → payment → warranty → settlement
That distinction is extremely important.
A customer saying:
"My Samsung 55-inch TV isn't working"
does not mean the technician knows the repair price.
The technician needs to diagnose it first.
So your marketplace needs to support two commercial stages:
Example:
Diagnosis/home visit: ৳300
Then:
Estimated repair: ৳2,500–৳4,000
Customer approves.
Technician performs the repair.
Final invoice:
| Item | Amount |
|---|---|
| Visit/diagnosis | ৳300 |
| Parts | ৳2,200 |
| Labor | ৳1,000 |
| Total | ৳3,500 |
Platform takes, say, 15%.
Technician gets:
৳2,975
Platform:
৳525
This makes the business much more manageable.
The client's existing 35 technicians are incredibly valuable.
Don't immediately try to recruit 5,000 technicians.
Launch in one city / selected zones using their existing technicians.
For example:
Dhaka:
- 35 existing technicians
- 5 existing shops
- TV repair only
- home service + shop service
- controlled service area
Then expand:
Dhaka:
- 100–200 technicians
- TV + refrigerator + AC + washing machine
Major cities:
- Chattogram
- Sylhet
- Rajshahi
- Khulna
- etc.
Nationwide marketplace.
Your proposal should probably describe the system as:
Flutter.
Customer can:
- Register/login
- OTP
- Manage addresses
- GPS location
- Create repair request
- Select appliance
- Describe problem
- Upload images/videos
- Request service
- See technician offers
- Accept technician
- Chat
- Call
- Track technician
- Approve quotation
- Pay
- View invoice
- View repair history
- Warranty information
- Rate/review
- Raise dispute
- Get notifications
Flutter.
This is arguably more important than the customer app.
Technician needs:
- Registration
- KYC
- NID verification
- Profile
- Skills
- Appliance categories
- Brands
- Experience
- Service zones
- Current availability
- Online/offline status
- Job notifications
- Job details
- Customer location
- Navigation
- Accept/reject
- Arrival confirmation
- Diagnosis
- Quotation
- Parts
- Labor
- Before/after photos
- Customer approval
- Job completion
- Payment status
- Earnings
- Wallet
- Withdrawal request
- Job history
- Ratings
- Performance metrics
- Warranty claims
- Dispute handling
Laravel admin panel.
This becomes the control tower.
- Customers
- Accounts
- Addresses
- Jobs
- Payments
- Complaints
- Reviews
- Technician registration
- KYC
- NID
- Certificates
- Skills
- Brands
- Service areas
- Documents
- Approval/rejection
- Suspension
- Performance
Admin sees:
Job #10432
Customer → Samsung TV → Mirpur → Technician A → accepted → diagnosis → quotation → repair → paid.
You need a proper job state machine.
For example:
REQUESTED
↓
MATCHING
↓
TECHNICIAN_ASSIGNED
↓
TECHNICIAN_ACCEPTED
↓
ON_THE_WAY
↓
ARRIVED
↓
DIAGNOSING
↓
QUOTE_SUBMITTED
↓
CUSTOMER_APPROVED
↓
REPAIRING
↓
COMPLETED
↓
PAYMENT_PENDING
↓
PAID
↓
SETTLED
With alternative paths:
CANCELLED
REJECTED
DISPUTED
REFUNDED
WARRANTY_CLAIM
This is one of the most important parts of the architecture.
"Nearest technician" sounds simple but actually isn't.
You don't want:
Nearest technician = best technician.
You want:
Best available technician for this particular job.
Example scoring:
Distance 30%
Skill match 25%
Brand experience 15%
Rating 10%
Successful jobs 10%
Response rate 5%
Cancellation rate 5%
Suppose:
2 km away Rating: 4.2 Samsung TV specialist
4 km away Rating: 4.9 Mostly refrigerator repair
Technician A should probably receive the job first.
Don't broadcast every job to every technician.
For example:
Top 5 technicians within 3 km.
Give them 60 seconds.
If nobody accepts:
Top 10 within 5 km.
Then:
10 km radius.
This prevents:
- Notification spam
- Technicians fighting over jobs
- Poor UX
- Excessive cancellations
This is a major component.
You'll need:
GPS coordinates.
Technician periodically updates:
latitude
longitude
last_seen_at
availability
You don't necessarily need continuous GPS tracking when technicians aren't working.
Once a job is assigned, you can enable more frequent location updates.
You'll need map infrastructure for:
- Geocoding
- Reverse geocoding
- Distance calculation
- Routing
- ETA
- Technician tracking
You need to decide between Google Maps and alternatives based on Bangladesh pricing/coverage.
Don't hard-code the map provider deeply into the application.
Create something like:
MapService
├── geocode()
├── reverseGeocode()
├── distance()
└── route()
Then you can change providers later.
This is one of the biggest challenges.
You aren't simply accepting money.
You are running a marketplace payment flow.
Customer pays:
৳3,500
Platform:
৳525 commission
Technician:
৳2,975
You need:
- Payment initiation
- Payment verification
- Webhooks
- Transaction ledger
- Refund
- Partial refund
- Cancellation
- Commission calculation
- Technician balance
- Withdrawal
- Settlement
- Reconciliation
Don't implement this as:
technician_balance += 2975
You need a proper ledger.
Example:
Transaction
TXN-1001
Customer payment +3500
Platform commission -525
Technician earning +2975
Technician withdrawal -2000
Technician balance 975
Every financial operation should be auditable.
You will likely want to support things such as:
- bKash
- Nagad
- cards
- bank payments
- potentially cash
But cash creates serious marketplace problems.
Suppose customer pays technician directly:
৳3,500 cash
Now your platform has lost control over:
- Commission
- Transaction verification
- Revenue
- Fraud
- Refund
- Customer protection
So I would strongly recommend:
Platform-controlled digital payment.
Then potentially:
Only under controlled circumstances, with the platform recording the transaction and deducting commission from technician wallet/settlement.
Each technician gets:
Available balance
Pending balance
Withdrawn
Total earnings
Commission
Refunds
Adjustments
Example:
Completed jobs ৳45,000
Platform commission ৳6,750
Refund adjustment ৳1,000
Available ৳37,250
Withdraw:
৳10,000
Remaining:
৳27,250
You need proper accounting records behind this.
Imagine a customer sees:
Technician: Rahim Rating: 4.8 153 jobs
But is Rahim actually competent?
You need technician verification.
Collect:
- Name
- Phone
- NID
- Photograph
- Address
- Emergency/contact details
- Experience
- Skills
- Appliance categories
- Brands
- Previous work
- References
- Bank/mobile wallet details
Potentially:
- Police verification/background checks
- Trade certificates
- Shop affiliation
depending on the business model and legal requirements.
This is another massive challenge.
One bad technician can damage the platform's reputation.
You should create a technician score.
For example:
Rating
Completion rate
Cancellation rate
Complaint rate
Repeat repair rate
Warranty claim rate
Response time
On-time arrival
Customer complaints
Technicians can have tiers:
New technician
Good history
Highly rated
Top performers
This can influence matching.
This is a huge opportunity.
After repair:
30-day repair warranty
Customer gets:
Warranty expires: 3 October 2026
If the same problem returns:
Customer opens:
Warranty claim
Platform investigates.
Possible outcomes:
- Technician returns free
- Technician pays/absorbs cost
- Customer pays new diagnosis
- Platform refunds
Without a warranty mechanism, customers may not trust marketplace technicians.
TV repair isn't just labor.
Parts can be:
- Original
- OEM
- refurbished
- aftermarket
- used
Customer needs transparency.
The quotation should say:
Main board — OEM — ৳4,500
rather than:
Parts — ৳4,500
Eventually you can create:
Technicians order parts through your ecosystem.
That's potentially a second business model.
This is where I'd make the proposal interesting.
The five existing shops could become:
Technicians can:
- Collect difficult repairs
- Receive parts
- Store devices
- Perform workshop repairs
- Escalate complicated cases
Customer has two service options:
Technician visits customer.
Technician collects TV → takes it to nearest hub → repairs → returns it.
This solves a major problem:
Not every TV can be repaired at home.
For large TVs, transporting them is risky.
You therefore need a logistics model.
Technician handles pickup.
Dedicated delivery riders.
Third-party logistics.
For MVP, I'd use:
Technician pickup/drop.
Later:
Dedicated logistics network.
You need:
- Pickup OTP
- Device photos
- Device condition report
- Serial number
- Accessories list
- Pickup receipt
- Handover confirmation
- Delivery confirmation
Otherwise customers can say:
"My TV was perfectly fine when you took it."
And the technician can say:
"It was already damaged."
This is especially important.
When collecting a TV:
Device:
Samsung 55"
Model:
Serial:
Screen condition:
Body condition:
Accessories:
Remote:
Stand:
Existing scratches:
Existing cracks:
Take photos.
Customer confirms.
This becomes evidence for disputes.
Eventually you'll get:
"Technician damaged my TV."
"Technician charged me more than agreed."
"Repair didn't work."
"Technician took my money."
"Customer refused to pay."
"Customer claims we replaced an original part."
The platform needs a dispute center.
Admin sees:
- Job
- Chat
- Photos
- Quote
- Customer approval
- Payment
- Technician history
- Device intake photos
- Warranty
- Previous disputes
Then admin can decide:
- Refund customer
- Pay technician
- Partial refund
- Technician penalty
- Warning
- Suspension
You mentioned:
"technician will be contacted through the app"
I'd implement:
Customer ↔ technician
With:
- Text
- Images
- Job-related attachments
- System messages
But I'd be careful with direct phone numbers.
If you allow unrestricted phone numbers, customers and technicians can easily move off-platform.
That destroys your commission model.
You can initially use:
- In-app chat
- Masked calling, if available
- System-generated communication
This is a fundamental marketplace challenge.
Customer:
"Brother, next time call me directly. Don't use the app."
Technician:
"Okay, I'll charge you less."
Platform loses future revenue.
You need incentives.
- More jobs
- Better ranking
- Faster settlements
- Loyalty bonuses
- Verified badge
- Insurance/warranty support
- Warranty
- Payment protection
- Dispute resolution
- Verified technicians
- Repair history
- Receipts
- Customer support
The platform should be more valuable than bypassing it.
You could have:
Good for simple repairs:
TV wall mounting — ৳X
Visit fee — ৳X
For actual repairs.
Night/weekend.
Beyond X km.
Eventually.
Your pricing engine should therefore be configurable.
Having an app doesn't automatically create demand.
The client already has an advantage:
Existing repair customers.
You can convert them into app users.
But you'll eventually need:
- TikTok
- Local SEO
- Call center
- SMS
- Referral program
- Technician referrals
- Brand partnerships
Bangladesh has a huge behavioral challenge.
A customer may simply call:
"ভাই, টিভি নষ্ট হয়েছে, লোক পাঠান।"
So I'd build a:
Customer calls.
Operator enters:
Customer
Phone
Address
TV
Problem
Preferred time
Then platform matching starts.
This lets the business migrate existing offline demand into the digital system.
I wouldn't build only a mobile app.
Minimum:
Flutter Android/iOS.
Flutter Android.
Laravel web.
Laravel/Blade or frontend.
SEO pages such as:
TV Repair in Dhaka Samsung TV Repair LG TV Repair Sony TV Repair
This can eventually generate organic leads.
You'll need:
Firebase Cloud Messaging.
For:
- OTP
- Important job updates
- Payment confirmation
Less important for customers but useful for admin/business.
For:
- New job
- Technician accepted
- Technician arrived
- Quote
- Payment
- Warranty
AI can speed up development, but more importantly it can become part of the actual product.
Customer writes:
"TV চালু হয় কিন্তু screen কালো থাকে"
AI categorizes:
Device: TV
Issue: No display
Potential category: Backlight / panel / board
Eventually AI can learn:
Samsung TV + no display + Mirpur
and identify technicians most likely to successfully repair it.
Technician enters diagnosis.
AI suggests:
Likely parts Estimated labor Typical price range
But don't let AI independently determine final pricing initially.
AI handles:
"Technician কখন আসবে?"
"আমার warranty কতদিন?"
"Payment ফেরত পাব?"
Detect:
- suspicious repeated refunds
- fake jobs
- abnormal pricing
- technician/customer collusion
- excessive cancellation
- off-platform communication patterns
I'd explicitly put these in your proposal because they show the client that you're thinking beyond coding.
- Not enough technicians in certain areas
- Too many technicians in others
- Technicians going offline
- Technician churn
- Irregular demand
- Seasonal demand
- Low demand zones
- Bad repairs
- Repeat failures
- Fake parts
- Overcharging
- Large TV transportation
- Damage
- Lost accessories
- Pickup delays
- Payment failure
- Refunds
- Chargebacks
- Technician settlement
- Commission disputes
- Fake bookings
- Fake reviews
- Customer-technician collusion
- Off-platform transactions
- Fake completion
- Consumer protection
- Tax/VAT considerations
- Technician agreements
- Payment-provider requirements
- Privacy/data protection
- Warranty obligations
The client should obtain appropriate local legal/accounting advice before launch.
Given your team:
Laravel
Modular architecture:
Auth
Users
Customers
Technicians
Technician Skills
Locations
Service Requests
Matching
Jobs
Quotes
Repairs
Parts
Payments
Wallet
Commission
Settlements
Reviews
Warranty
Disputes
Notifications
Support
Reports
PostgreSQL or MySQL.
For location-heavy functionality, PostgreSQL + PostGIS would be attractive.
If the team's Laravel stack is already MySQL-oriented, MySQL can work for MVP with an appropriate geo strategy.
Redis + Laravel Queue.
Critical for:
- Matching
- Notifications
- payment processing
- SMS
- reports
- background jobs
WebSockets for:
- technician location
- chat
- job updates
- admin monitoring
S3-compatible object storage for:
- NID documents
- repair photos
- device photos
- invoices
- attachments
Firebase Cloud Messaging.
Flutter.
Conceptually:
CUSTOMER APP
│
▼
┌─────────────┐
│ Laravel │
│ API │
└──────┬──────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Matching Jobs Payments
│ │ │
▼ ▼ ▼
Location Quotes Wallet
Service Repair Settlement
│ │ │
└─────────────────┼─────────────────┘
│
▼
PostgreSQL
│
┌───────────┼───────────┐
▼ ▼ ▼
Redis Storage Maps
│
▼
Notifications
│
┌─────┴─────┐
▼ ▼
Technician Customer
App App
The business owner should wake up and see:
New Requests 127
Assigned 98
Completed 76
Cancelled 14
Active Technicians 31
Revenue ৳182,000
Platform Revenue ৳27,300
Average response time
Average technician arrival
Acceptance rate
Completion rate
Cancellation rate
Average rating
Repeat repair rate
Warranty claim rate
Average order value
Revenue per technician
This is where the Laravel admin becomes a genuine business operating system, rather than just CRUD.
There are several possibilities.
Example:
15% platform fee.
Probably the simplest.
Customer pays:
Repair: ৳3,500 Platform fee: ৳200
Technician gets their agreed repair amount.
Technician pays:
৳X/month
and gets leads.
Commission + premium technician membership.
Platform earns from parts.
Extended warranty becomes another revenue source.
I'd start with commission + controlled service fees, then expand.
This is where I would protect your team from scope explosion.
- OTP authentication
- Profile
- Address
- GPS
- Appliance selection
- Repair request
- Image upload
- Job tracking
- Technician details
- Chat
- Quote approval
- Payment
- Invoice
- Rating
- Job history
- Notifications
- Registration
- KYC
- Skills
- Availability
- Location
- Job notifications
- Accept/reject
- Navigation
- Job status
- Diagnosis
- Quote
- Repair completion
- Photos
- Earnings
- Wallet
- Withdrawal
- Ratings
- Dashboard
- Customers
- Technicians
- KYC
- Service categories
- Jobs
- Matching override
- Payments
- Commission
- Wallet
- Settlements
- Reviews
- Disputes
- Reports
- Notifications
- CMS/settings
- REST APIs
- Authentication
- Matching
- Geolocation
- Notifications
- Payment integration
- Wallet
- Commission
- Audit logs
- Queue system
This is important.
Don't start with:
❌ AI diagnosis ❌ Complex dynamic pricing ❌ Parts marketplace ❌ Multiple logistics partners ❌ 20 appliance categories ❌ Advanced loyalty program ❌ Subscription plans ❌ Insurance ❌ sophisticated recommendation engine ❌ nationwide launch ❌ sophisticated technician bidding
First prove:
Can customers successfully get a trustworthy technician and complete a repair through the platform?
Assuming you have:
- Laravel developer(s)
- Flutter developer(s)
- UI/UX
- QA
- DevOps
- PM
- AI coding assistants
I'd estimate:
1–2 weeks
Requirements, workflows, database, API architecture, UX flows.
2–3 weeks
Can overlap with backend development.
7–10 weeks
Including:
- authentication
- users
- technician system
- jobs
- matching
- quotes
- payments
- wallet
- commissions
- notifications
- admin
- reporting
5–7 weeks
6–8 weeks
Technician app is more complicated.
4–6 weeks
Much can overlap with backend.
2–4 weeks
Payments, SMS, maps, push notifications, storage, etc.
3–4 weeks
Particularly important because this is a transaction marketplace.
2 weeks
Launch with the client's existing 35 technicians.
With a competent team and AI-assisted development:
10–12 weeks
Possible if:
- requirements are frozen
- UI is straightforward
- payment provider is cooperative
- team is strong
- 3–5 developers work in parallel
- MVP scope is disciplined
14–18 weeks
This is the number I would put in a client proposal.
18–24 weeks
If you include robust:
- payment reconciliation
- dispute system
- warranty
- logistics
- analytics
- monitoring
- security
- extensive QA
AI can substantially reduce coding time, but it doesn't reduce business/QA/integration time proportionally.
For a 14–18 week delivery:
1
1
2
2
1–2
0.5 / shared
0.5–1
So roughly:
6–8 people, with some roles overlapping.
If you're a smaller team, I'd plan for 18–22 weeks rather than promising 12.
If your developers are comfortable with AI coding tools, I'd expect productivity improvements especially in:
- CRUD/API development
- Laravel models/controllers
- Flutter boilerplate
- validation
- tests
- migrations
- admin interfaces
- documentation
- refactoring
- unit-test generation
But don't sell to the client:
"AI means we can finish in half the time."
That's dangerous.
Instead:
AI-assisted engineering allows us to accelerate implementation while retaining dedicated QA, security review, integration testing, and production hardening.
Because the hard problems here aren't typing code.
40. The biggest hidden issue: marketplace liquidity
This is probably the #1 business risk.
Imagine:
Customer in Uttara requests:
Sony TV repair
But there are no qualified technicians nearby.
Or there are 10 technicians but all are busy.
The platform says:
No technicians available.
Customer leaves.
Conversely, if you have 35 technicians but only 5 jobs/day:
Technicians stop opening the app.
That's the classic marketplace chicken-and-egg problem.
The client's existing repair business solves part of this.
Use their current jobs to seed the platform.
Instead of:
We're creating a new marketplace.
Position it as:
We're digitizing and expanding your existing repair operation into a nationwide service network.
That's much stronger.
Their existing:
5 shops + 35 technicians
becomes:
Founding Technician Network
Then external technicians join the network.
The existing shops become:
Authorized Repair Hubs
That gives the platform credibility.
I would consider this flow:
↓
↓
↓
Repair at home
↓
Pickup device
↓
↓
↓
↓
↓
↓
This makes the platform more than a lead-generation app.
It becomes a managed repair network.
That's considerably more defensible.
Once the core network works:
Businesses can submit:
- Office TV repairs
- Hotel appliances
- Restaurant equipment
- Corporate maintenance
Samsung/LG/Sony/etc. authorized or independent service relationships.
Annual maintenance contracts.
Technicians buy parts.
Platform-certified technicians.
Customer can potentially pay for expensive repairs in installments, subject to suitable financial partners/regulatory requirements.
Device repair protection.
Old TVs repaired and resold.
Eventually this could become much larger than repair alone.
I'd pitch the project in three phases.
3–4 months
TV repair only.
- Customer app
- Technician app
- Admin
- Matching
- Location
- Quotes
- Payment
- Wallet
- Commission
- Reviews
- Basic warranty
- Existing 35 technicians
Goal:
Prove the marketplace.
2–3 months
Add:
- Pickup/drop
- Repair hubs
- Parts
- Advanced warranty
- Dispute center
- Technician tiers
- Advanced analytics
- Call center integration
Goal:
Improve reliability and operational control.
3–6+ months
Add:
- More appliance categories
- More cities
- External technicians
- AI assistance
- B2B
- Parts marketplace
- Subscription
- Brand partnerships
Goal:
Become a nationwide repair infrastructure.
If I were your agency, I'd define the initial deliverable as:
A two-sided repair marketplace consisting of a customer mobile application, technician mobile application, Laravel-based operations/admin platform, location-based technician matching, digital quotation/approval, integrated payment, commission/wallet system, real-time job status, communication, ratings, and basic warranty/dispute management.
14–18 weeks
6–8 people
Pilot in Dhaka using the client's existing 35 technicians and 5 repair hubs.
TV repair only.
Don't measure success by:
"App downloaded."
Measure:
- Requests/day
- % matched
- % accepted
- Average time to assign
- Completion rate
- Average order value
- Platform commission
- Technician utilization
- Customer rating
- Repeat customers
- Warranty claims
- Cancellation rate
- Customer acquisition cost
I would take this lead seriously.
The interesting part isn't the app. There are thousands of companies capable of building a Laravel + Flutter marketplace.
The real moat could become:
35 technicians → verified technician network → 5 repair hubs → standardized repair processes → parts network → warranty → customer trust → nationwide repair infrastructure.
If they execute that well, they're no longer just an app connecting customers to repairmen. They're building a national service network.
And that distinction should probably be reflected in your proposal: sell the client a repair-network platform, not a mobile app.