Sunspace Energy

Sunspace sells rooftop solar in Agra. Before this project it had no website, no record of who had enquired, and its project paperwork lived across phones and WhatsApp chats. I built a website that answers the buyer's real question (“what will this cost me after subsidy?”), one form that records where every enquiry came from, a WhatsApp referral programme, and a staff workspace that follows each customer from first contact through subsidy, net metering and after-sales service.

The amount of software isn't what I want to show here. What matters is that nearly every element traces back to something specific about how this business works: subsidies are paid into the customer's bank account, not the installer's; net metering is filed with one of two electricity companies depending on the street; buyers and referrers live on WhatsApp; and the founder isn't technical and shouldn't have to be.

• No website. The domain was registered the day we started and showed a parked page. The only DNS records were for email.
• Marketing was a printed flyer with a 1–10 kW price table, a toll-free number and a Gmail address. Its headline promised a “75% subsidy”, which only roughly holds for the smallest systems.
• No record of who had enquired and no way to tell which ad, post or conversation had produced a customer.
• Project paperwork everywhere. Each installation needs electricity bills, ID and bank proof, a quotation, site photos, net-metering forms and a commissioning report. All of it sat in phones and chats.

Facts about the market that shaped the product

I wrote these down early so that small decisions didn't each turn into a debate. Most of the choices later on this page come from one of them.

The design started in Claude Design, and twelve pages shipped on day one: home, a solutions overview, four solution pages (residential, commercial, industrial, solar + battery), the savings calculator, how it works, about, contact, privacy and terms. Five more followed: the Agra page, two guides, a guides index and the referral page.

The home hero

One form behind every button

Every call to action opens the same form, so there is one set of rules and one place a lead can go wrong. The field rules and error messages from the design were copied over word for word.

Captured without the visitor typing anything: which button they pressed (home_hero, calculator, agra_page, refer_page…), any estimate they ran, the ad tags from their first visit (UTM, gclid, fbclid), the page they landed on and the site that referred them. Each enquiry can be traced back to whatever produced it.

On the server: each lead gets a reference that is easy to read out over the phone (SS-YYMMDD-XXXXXX), and submissions are limited to 8 per 10 minutes per IP. Each lead is sent to every configured destination at once, and one success is enough. If no destination is configured in production, the API returns an error and the visitor sees the form's error message, never a false “thank you”.

The question a buyer actually has is “what will this cost me, after subsidy, and when does it pay back?”. The calculator answers it in under a minute and then hands that answer to the sales team.

Inputs, and why each is there

Modelling choices

• A range, not a number. Savings are shown ±10%, because a single precise figure would claim more certainty than a pre-visit estimate has.
• Conservative payback. It includes 0.5% panel ageing a year and assumes electricity prices won't rise. Promising less keeps the site survey from having to walk the number back.
• The method is on the page. A “How the estimate works” section lists the formulas and what is not included: financing, inverter replacement, shading on the actual site.
• No retyping. “Carries into your request so you never type it twice”: the estimate is attached to the lead, so sales starts the call already knowing the system size.

Before and after: pricing from the company's own price list

One pricing file now feeds the calculator, the Agra page and both guides, so the site can't quote two different prices. I checked the calculator against all ten rows of the flyer. That caught a missing digit in the flyer's 7 kW row. I also chose not to repeat the flyer's “75% subsidy” headline anywhere, because it is only roughly true at 1–2 kW.

I wrote a 90-day SEO plan that starts with Agra, then built the parts of it a developer can build. The Agra page answers the questions a local buyer actually searches for:

• Price table and a worked 3 kW example showing the price after subsidy, step by step.
• “Who supplies your power”: Torrent Power or DVVNL, which decides who you file net metering with.
• Local conditions: Agra's sunlight, dust and smog (more cleaning) and summer heat.
• Six FAQs marked up as FAQ structured data, plus the areas served and a form pre-filled with Agra.
• Two guides (“PM Surya Ghar subsidy in Agra” and “Rooftop solar cost in Agra”), LocalBusiness structured data, and a www → apex redirect that keeps the path and ad tags.
• A Google Business Profile description at 689 of 750 characters, with no prices because Google doesn't allow them in that field.

I didn't plan a staff app. I planned the smallest thing that would stop leads getting lost, and let real constraints pull the scope up from there. Each step below was triggered by a specific problem, not by a roadmap.

1. Day 1

   Don't build an admin screen. Send leads to tools the founder already uses: a Google Sheet plus an email alert.

2. Day 1

   The sheet fails. The business Gmail account couldn't create the Apps Script the sheet needed. Leads go into MongoDB instead, with a password-protected page at /admin/leads.

3. Day 1

   Moved to its own app. Twelve minutes later the leads page moved out of the website to workspace.sunspace.in. The public site keeps only the code that writes a lead, and the internal tool can grow without putting the public site at risk.

4. Day 2

   Individual accounts, so employees could use it, each with their own sign-in and an activity log of who changed what.

5. Day 3

   A full lifecycle. A lead pipeline with hot/warm/cold interest and priority, then projects from a won lead through to after-sales, documents, the WhatsApp inbox and referrals.

6. Day 7

   Access by area (leads, projects or both), leads added by hand for walk-ins, and the save and filter speed fixes.

The lead pipeline

The biggest product decision in the workspace: a project's stage is never set by hand. It is the first stage that still has a required step open.

A status someone types goes out of date the moment they forget to update it. A checklist is what the installation team actually works through, so the stage is calculated from it. Optional steps (such as “System design finalised”) can be skipped without blocking the stage. When the lifecycle definition changes, a version stamp makes every existing project recalculate its stage once.

The stages, after checking them against how installations actually run

The result is Booking → Survey & design → Installation → Net metering → Commissioning & subsidy → Handover → In service, with 16 required steps.

Money, documents and after-sales

• Payments and subsidy. Contract, received and balance. The expected central and state subsidy is filled in from the system size, and the dates each is credited are recorded. Subsidy is never counted as received, because it goes to the customer's bank, and counting it would make every balance look smaller than it is.
• Documents. 18 document types (bills, Aadhaar and PAN ID cards, bank proof, quotation, site photos, DCR certificate, net-metering papers, commissioning report, warranty cards), each attached to the checklist step that needs it. Files are stored privately in Cloudflare R2 and can only be opened through the signed-in app. Up to 10 files at 15 MB each; HTML files are refused. “Replace the current file” is on by default (except for photos), and the old file is deleted only after the new one uploads.
• After-sales. Warranty end dates counted from commissioning, AMC dates, and service tickets (complaint, cleaning, maintenance, warranty claim). A Service page lists open tickets, visits due in the next 14 days and AMCs ending soon. In a dusty city, cleaning visits keep the relationship going, and that is where referrals come from.

The project page went through three versions

Before

One long page, with documents in the middle of the checklist. Every tick reloaded the whole page.

After

A stepper, and “Update stage”: tick several steps, attach each step's documents, add a note, and save once. Only that part of the page refreshes. Version three moved navigation into a sidebar and documents into a compact bar.

My own review of version one was blunt: every click refreshes the whole page, and the project flow doesn't look like a flow. A second round was about speed and calm:

• Feeling instant. Whole rows are clickable and load in advance on hover, and loading states appear immediately. Switching a filter cancels the request already in progress (the fix I asked for). Rapid status clicks are merged so only the latest is saved: in testing, twelve quick clicks left one clean history entry.
• Less visual noise. A sidebar replaced the top header, borders got lighter, table headers stay visible while scrolling, and the app is called “Sunspace”, not “Workspace”.

The first version had two roles: an admin and a member who could work leads. Then the real requirement arrived: whoever adds a team member decides whether they see leads, projects or both; referrals shouldn't show on the team page; and only admins should check referrers and pay them out. Some people only sell, some only install, and the referral money is the founder's.

Details that make the matrix work in practice

• Hidden, not just blocked. The sidebar shows only the areas a person can use, and they land in their own area after signing in.
• Pickers respect access. Owner dropdowns list only people with access to that area, so a project can't be assigned to a leads-only salesperson.
• No one locked out by the change. Accounts created before this existed keep both areas.
• Security basics. Everyone has their own email and password. Passwords are hashed with PBKDF2-SHA256 at 100,000 iterations, the most Cloudflare Workers allows. Sessions are stored as hashed tokens and expire after 7 days, so resetting or disabling someone signs them out everywhere at once. Temporary passwords must be changed at first sign-in. Nobody can disable or demote themselves, and there is always one active admin. Sign-in attempts are rate-limited, form posts from other sites are refused, and every page is hidden from search engines.
• First run. A one-time setup key creates the owner account, then setup closes for good. Hashed passwords can't be recovered, so there is a small script to set a new one directly in the database.

Run ads on Instagram. People show interest by messaging on WhatsApp and send leads our way. If a lead actually succeeds, they get ₹5,000.

The brief

The conventional design is a sign-up page with a personal referral link and a form for each friend. I sketched that first, then dropped it. The people this is for (past customers, friends, an Instagram audience) won't fill in forms, but they will send a WhatsApp message. On WhatsApp the phone number is the identity: it links the bot conversation, the lead, the project and the payout, with no accounts. Once a referred friend's number is attached to a project, the referrer gets WhatsApp updates on its progress.

Rules of the programme, and why

• Paid on the final payment, not at installation. Sunspace has the customer's money before it pays out. The reward moves from pending to due when “Final payment received” is ticked on the project (the referrer gets a WhatsApp message asking for their UPI ID), then to paid when an admin records the payout (and a confirmation goes out).
• A short counts / doesn't count list. Self-referrals, existing customers and addresses outside the service area are listed up front, so there are no arguments later.
• Open questions written onto the page. The terms carry a visible note to confirm with an accountant, and I flagged that payouts may need tax deducted at source (TDS).

The bot

Three options: Get solar (creates a lead), Refer a friend (signs the person up as a referrer, then turns a friend's name and number into a lead credited to them) and Talk to us (hands the chat to staff, and the bot goes quiet). A UPI ID the referrer sends is saved automatically. STOP and START control marketing messages, and “delete my data” flags the chat and pauses the bot.

Build or buy

WhatsApp tools like AiSensy and Interakt cost roughly ₹1,000–3,000 a month and keep chats in their own app. Building our own bot and inbox puts each chat next to the lead and the project it belongs to, which is the whole point of the referral flow. Setting up Meta is hard for a non-developer, so the admin's WhatsApp page includes a self-check: which settings are present or missing, what the access token can reach, whether Meta is reaching the webhook, whether the number is registered (with a form to register it using its PIN), and one-click linking. It turns a developer-only setup into a checklist the founder can follow.

I worked as the PM and directed Claude Code as the engineering team. The leverage came from running work in parallel; the quality came from testing before every release and reviewing everything myself.

• Design first. The visual system and pages were designed in Claude Design, then turned into code with the design's exact field rules and messages.
• Parallel builds. On day one, five agents worked side by side on the lead form and API, the calculator and planner, the 3D home, the solution pages and the legal pages. Two more built the Agra page and the guides, and separate sessions handled the lead pipeline and the referral page.
• Testing before each release. Every feature ran against a throwaway local database on Cloudflare's own runtime before it was pushed: 13 checks for the first leads page, 16 for splitting off the workspace, 38 for accounts, 78 for the lead pipeline, 55 for projects and 24 for the WhatsApp bot. Bugs got their own stress tests, such as 80 leads with 17 rapid filter clicks for the quick-view crash.
• A register of every integration. At handover the founder got a spreadsheet of all 24 services: 17 live, 4 in progress, 1 needing a setting and 2 not set up. It also listed every server setting by name (never the value), the 11 workspace modules, all 17 pages with their indexing status, the 11 analytics events and the open to-dos.

The site, calculator, Agra pages, referral page and workspace are live. WhatsApp is waiting on Meta (switching the app to Live, and template review). Search Console and the Google Business Profile are in progress. The 11 analytics events are wired up, but GA4 isn't connected yet. So there are no outcome numbers yet, and I'm not going to invent any. Sample impact figures and testimonials carry a visible “sample” label until the founder supplies real ones.

The first 90 days: what I'd watch

• Let constraints set the scope. “Don't build an admin” was the right first answer. The blocked sheet, the employees and the paperwork each earned the next step.
• The user's channel beats my form. Dropping the referral-link design for WhatsApp-only made the programme usable for the people it's for. My job was making it work within Meta's rules.
• Calculate state; don't ask people to keep it up to date. A stage derived from the checklist ended a whole category of stale-status problems.
• Investigate before building. The “personal number” bug was test data. Checking first saved a fix that would have broken something that worked.
• Speed you can feel is a feature. “It takes a second” is a product complaint, not a technical one. Prefetching, cancelling stale requests and merging saves fixed it.