ServiceHub Private Limited
Freelance Product DeveloperServices Marketplace
ServiceHub is an on-demand marketplace connecting customers with local service providers. It was a paid client engagement and I was the sole developer — requirements, architecture, build, deployment and handover.
The distinctive thing about it isn’t the product; it’s the constraint. A fixed budget and a fixed timeline with one developer means every scope conversation is a trade-off conversation, and I was the one having them, directly with the client.
- Client product — access on request
Shared authentication
shared data model
Role-based routing
customer or service provider
Customer marketplace
find and book
Provider experience
manage incoming work
Admin panel
outside the marketplace application
01 / 09
Problem
The client needed a working two-sided marketplace: customers finding and booking local service providers, providers managing what came in. And they needed the operational tooling to actually run it, which is the part that tends to get discovered late.
The constraint was the real problem. Fixed budget, fixed timeline, one developer. Under those conditions the failure mode isn’t building the wrong thing — it’s agreeing to build all of it.
02 / 09
Goal
Product goal
A marketplace serving both sides, deployed and handed over, plus an admin panel that lets the client operate it without a developer.
Delivery goal
An MVP that ships inside the budget and the timeline, with the trade-offs agreed explicitly rather than absorbed silently.
Handover goal
The client owns a running system at the end, not a dependency on me.
03 / 09
Architecture
One role-based application, two experiences
Rather than two codebases, a single application where role determines the product a user gets — customer or service provider. Shared authentication, shared data model, divergent interfaces.
Separate admin panel
Operations deliberately live outside the marketplace application. Admin users have a different job, a different risk profile and a different release cadence than either side of the marketplace, and coupling them would have made every operational change a marketplace deployment.
Data and backend layer
REST APIs between the application and its services.
Frontend
A React application.
Screens pending — walkthrough available on request
04 / 09
Key features
Customer marketplace
Find and book local service providers
Why it was in the MVPHalf the two-sided market — without it there’s no product
Provider experience
Providers manage incoming work
Why it was in the MVPThe other half; a marketplace with one side is a directory
Role-based authentication
One auth system routes users to their experience
Why it was in the MVPThe architectural decision that made one codebase viable for two products
Admin operations panel
Client runs day-to-day operations independently
Why it was in the MVPSurfaced in requirements elicitation; without it the client needs a developer forever
Deployment & handover
Client owns a running system
Why it was in the MVPThe engagement isn’t delivered until this is true
05 / 09
Technical decisions
One role-based application instead of two parallel apps.
Two apps would have been cleaner in isolation and twice the maintenance surface — and I was the entire maintenance team. Role-based routing over shared auth and a shared data model meant one deployment path, one set of dependencies, one place to fix a bug. I could make that call confidently precisely because I was the person who’d pay for the wrong one.
Admin panel separate, everything else together.
The consistent-sounding decision would have been to put admin behind another role in the same app. I split it, because operations and marketplace change for unrelated reasons at unrelated times. Coupling them would have meant redeploying the customer-facing product to change an internal workflow. The rule I was applying: share what shares a reason to change.
Elicit requirements directly rather than work from the brief.
I ran the requirements conversation with the client myself rather than working from a feature list. That’s where the operational needs surfaced — the separate admin panel is the piece that determines whether the client can run the business after handover, and it comes out of asking what has to happen daily rather than what the product should have.
Negotiate trade-offs in the open.
With a fixed budget, every added feature removes another one. I put those exchanges to the client explicitly rather than quietly absorbing scope and hoping the timeline held. Uncomfortable conversations early instead of silent scope creep later.
Managed infrastructure over a hand-rolled backend.
One developer against a fixed timeline. Managed data infrastructure and a typed ORM buy time that goes into product surface instead of plumbing. The trade-off is platform coupling, which is the right trade at this scale and the wrong one at a much larger one.
06 / 09
Challenges
Being every role at once.
Product manager, architect, engineer, deployer and account manager, with no one to check any of it. The mitigation was writing decisions down before implementing them — if a choice couldn’t survive being written as a sentence, it usually wasn’t a good choice.
Fixed budget as a design constraint.
Budget wasn’t a project-management detail; it decided architecture. One codebase over two, managed services over custom infrastructure, both sides of the marketplace shipped properly over a wider surface shipped partially. Every one of those is a budget decision wearing technical clothes.
A client who knows the business, not the software.
A client buying software knows their business, not what a feature costs to build. Translating “can we also do X” into “X costs roughly this much of Y” — in terms they could make a call on — was most of the value I added before writing any code.
Delivering to a client means someone else’s business depends on it.
A personal project failing is a bad evening. This failing is a client’s operations. That changed how I thought about the admin panel, error paths and handover documentation.
07 / 09
Lessons learned
Requirements elicitation is where the product gets found.
The separate admin panel — arguably the most important deliverable for the client’s ability to operate after handover — came out of asking what has to happen daily, not out of a feature discussion. I now treat any feature list as a starting hypothesis rather than a specification.
Architecture is a budget document.
“One role-based app or two?” is a technical question with a financial answer. Being the person who pays for the decision makes you decide differently, and better.
Say the trade-off out loud.
Every added feature removes another one when the budget is fixed. Putting that exchange to the client explicitly, rather than absorbing it quietly, is the difference between a scoped MVP and an open-ended build. Absorbing scope silently is the most common way solo delivery fails.
Split by reason to change, not by resemblance.
Admin looks like it belongs in the app and doesn’t belong in its deployment cycle. Coupling by similarity is a trap; coupling by shared cause of change is the actual rule.
Handover is a feature.
The engagement wasn’t finished when the code worked. It was finished when the client could run the thing without me.
08 / 09
Future improvements
Instrument the two-sided funnel — booking completion by side — so scope conversations after MVP are driven by data instead of intuition.
Extend the admin panel from operations into reporting, so the client can answer their own business questions.
Add provider-side analytics; providers currently manage work without visibility into their own performance.
Formalise the handover with runbook documentation, so operational knowledge doesn’t live in my head.
Revisit the single-application decision if provider requirements diverge much further from customer requirements.
09 / 09
Technologies used
Confirmed from the résumé
- Requirements Elicitation
- MVP Definition
- Stakeholder & Client Management
- System Architecture
- Role-Based Application Design
In the global skills list, not attributed to ServiceHub
- React
- Next.js
- TypeScript
- Supabase
- Prisma
- REST APIs
- Git