WEBEnergy & MarketplaceIN
SolarSathi
A two-sided solar marketplace where a buyer sends one request and compares every quote in one place.
- Our role
- Product design · Frontend · Backend · Infrastructure
- Platforms
- Web
- React
- Node.js
- PostgreSQL
- AWS
- LivemarketplaceRunning at solarsathi.co.in
- MultivendorOne request fans out to many suppliers
- Indiasolar marketBuilt for the domestic procurement chain
- Fourworkflow statesRequested, reviewed, quoted, accepted
At a glance
- Business problem
- Buying commercial solar in India means finding vendors one at a time, describing the same requirement repeatedly, and comparing quotes that arrive in different formats over days. SolarSathi was built so a buyer describes a requirement once and receives comparable quotes in one place.
- Technical challenges
- SolarSathi coordinates an asynchronous conversation between one buyer and many vendors, where each vendor responds on their own schedule. The platform has to track every request independently, notify both sides at the right moments, and stay simple enough to ship as an MVP.
- Engineering solution
- SolarSathi models each quote request as a small state machine — requested, reviewed, quoted, accepted — with every transition firing an email notification. Vendor listings and search run on PostgreSQL, and the whole platform is deployed on AWS.
- Core features
- Multi-vendor listings with search and filtering. Quote requests that fan out from one buyer to many vendors. Four-state workflow tracking per request. Email notifications on every state change. Vendor profile and verification pages. Admin panel for listing management.
- Architecture
- ReactNode.jsPostgreSQLAWS Services
- Technical highlights
- A four-state machine keeps every request auditable rather than free-form. Notifications are driven by state transitions, not by scheduled polling. PostgreSQL search is tuned for vendor discovery by capacity and region. A mainstream stack chosen so the client could hire for it later.
- Business value
- SolarSathi turns solar procurement from a sequence of separate vendor conversations into one request with comparable answers. Vendors reach buyers they would not otherwise meet, and buyers stop repeating themselves.
The problem
Buying commercial solar in India is a procurement problem wearing an energy-industry costume.
A business that wants a rooftop system has to find vendors, one at a time, usually through search results and phone numbers. Then describe the same requirement to each one. Then wait. Quotes come back over days, in different formats, covering different things — one includes installation, one does not, one quotes panels only. Comparing them means rebuilding all of it in a spreadsheet.
Vendors have the mirror-image problem. They are good at solar and not at being found, and they spend time quoting for buyers who were never going to proceed.
Neither side is short of intent. They are short of a place to meet.
The constraints
One buyer, many vendors, no shared clock. Each vendor responds when they respond. The platform has to hold one request open across many independent replies without either side having to chase.
Ship an MVP, not a category leader. The temptation on any marketplace is to launch with messaging, payments, ratings, and escrow. That marketplace does not launch. The scope had to be the smallest thing that made procurement genuinely better.
A stack the client could hire for. SolarSathi was built with the expectation that the client might grow a team around it. That ruled out anything clever in favour of anything common.
Marketplaces do not fail on features. They fail because one side shows up and finds nothing there.
How we built it
Every quote request is a small state machine: requested → reviewed → quoted → accepted. One state at a time, only legal transitions permitted.
That choice does more work than it looks like. Status flags — is_quoted, is_reviewed — let a request end up in two states at once, and every confusing edge case and duplicate notification email comes from exactly that. A state machine makes those states unrepresentable.
Notifications hang off the transitions rather than off a scheduler. When a request moves to quoted, the buyer is emailed because the transition happened, not because a cron job noticed something changed. Fewer moving parts, and no window where the data is ahead of the notification.
Vendor discovery is PostgreSQL — indexed on capacity range and region, which is how buyers actually search. Deployed on AWS with the database managed rather than self-hosted, because a two-person MVP should not be running its own Postgres.
Inside the product
- The requirement, onceCapacity and location are stated at the top and inherited by every vendor. The buyer never restates them.
- Workflow, always visibleThe four states sit above the list so a buyer knows what is still outstanding without opening anything.
- Per-vendor stateEach vendor advances independently. Two quoted and two still moving is the normal case, not an error.
- Quotes alignedTabular figures in a fixed column. Comparison is the entire product, so the numbers must line up vertically.
The empty-marketplace problem was handled by making the vendor side useful before any buyer arrived. Listings and profiles are worth browsing on their own, so the platform is not a blank page on day one.
What shipped
- Multi-vendor listings with search and filtering
- Quote requests fanning out from one buyer to many vendors
- Four-state workflow tracking, per vendor, per request
- Email notifications fired by state transitions
- Vendor profile and verification pages
- An admin panel for listing management
- PostgreSQL search tuned for capacity and region
- AWS deployment with a managed database
The decisions that mattered
A state machine over status flags. Covered above, and the decision we would make first again. It is the difference between a workflow you can reason about and one you debug forever.
Email over real-time. No websockets, no in-app chat, no push. Procurement happens over days, and the notification channel every Indian business already checks is email. Real-time would have been engineering effort spent on a problem nobody had.
Mainstream stack over the best stack. React, Node and PostgreSQL are not the most interesting answer to any of these problems. They are the answer with the largest hiring pool, which mattered more than elegance for a client who might staff this later.
Lean flow first. The first version shipped without ratings, messaging or payments. Each of those is a real product on its own, and adding them before anyone had used the core flow would have been guessing.
If you are scoping something similar, what custom software actually costs covers the budget side and idea to MVP in six weeks covers the sequencing. Our web development work is where this kind of platform usually starts.
Questions buyers ask
How long does a two-sided marketplace MVP take?
The workflow is the schedule, not the page count. SolarSathi shipped with one lean quote flow and no real-time features, which is what made it deliverable — a marketplace that tries to launch with chat, payments and ratings usually launches with none of them.
How do you solve the empty-marketplace problem?
By making one side useful before the other exists. Vendor listings and profiles have value to a buyer browsing before a single quote request is sent, so the platform is not dead on day one.
Why a state machine rather than status flags?
Because a request has exactly one state and only some transitions are legal. Flags let a request be both quoted and requested, which is where the confusing edge cases and the duplicate notification emails come from.
Can we start smaller than this?
Usually yes, and usually you should. We build a free working prototype first so you can see the core flow before committing to the rest of it.