The Problem
Decades of serious infrastructure work, and almost no way for a new client to find it. Khaleel Electricals is a Class-1 licensed electrical contractor in Bengaluru, trusted by names the city knows, from Malabar Gold & Diamonds to St John's. Yet two everyday gaps were quietly costing the firm work:- No digital presence. A prospect who heard the name had nowhere to land. With nothing online, a decades-old Class-1 contractor looked no different from a one-person operation, and enquiries drifted to firms that were simply easier to find.
- Paperwork that ran on memory. Quotations and invoices were typed in Word or written by hand, then wrestled onto pre-printed letterhead that never quite lined up. Old quotes were almost impossible to find and reuse, payments lived in someone's head, and nobody had a single view of who owed what.
Two Audiences, Two Broken Journeys
Before designing anything, I mapped who the firm actually needed to serve and where each journey broke. The prospect arrives on a recommendation and wants one thing fast: proof that this firm can handle serious work. With nothing online, that journey died before it began. So the job was never "build a website". It was to make decades of real capability legible in the few seconds a busy client gives you. The office lives inside the quote-to-cash flow: draft a quotation, win the job, raise invoices, chase payments. Every stage leaked time. I walked through how a quote was actually made, typed in Word or written by hand, fought onto letterhead, hunted down whenever it needed reusing, and tracked in someone's memory once it went out. Those pains were not cosmetic. They were the workflow. Mapping both journeys made the core decision obvious: this was one brand doing two jobs, not a website with an admin panel bolted on. The identity had to come first, because both experiences would be built on top of it.The Rebrand
The firm needed an identity that matched its standing, so I rebranded Khaleel Electricals from the ground up: a new logo, business cards, and a letterhead that carries through to every quotation and invoice the office sends. That one identity is the thread tying everything together. It sets the tone of the marketing site and, crucially, it is the letterhead the invoicing dashboard reproduces. Because I designed the letterhead in the first place, rebuilding it in code to a pixel was a continuation of the same brand work rather than a guess at someone else's template.Designing the Marketing Experience
The prospect needs to feel the firm's capability quickly, so I designed the site as a single scrolling story rather than a brochure, moving from a hook, through the firm's promise, into proof.
A short, confident headline sits over the firm's Class-1 licence, paired with a line illustration of a transmission tower feeding a home. The page is bold where it counts and calm where it should be, because the audience wants answers, not decoration.
The structure follows the journey rather than a sitemap:
- A pinned narrative that advances chapter by chapter, so the firm's story is paced and felt rather than dumped in a wall of text.
- A services breakdown across five categories that mirror what a Class-1 licence actually covers, from substations and switchgear to earthing and testing, so a prospect can self-qualify in seconds.
- Proof that is shown, not claimed.
Statistics count up as the band scrolls into view over an animated circuit motif, putting the firm's track record in motion instead of leaving it as a static line.
A client wall of flip cards cycles through named clients and the sectors the firm serves, turning reputation into something a stranger can take in at a glance. A working contact form closes the loop so an interested prospect can reach the owner without friction.
Designing the Office's Workflow
For the office I designed around the quote-to-cash flow, not around screens. Three decisions shaped the experience:- The document is the interface. A live A4 preview reproduces the firm's letterhead as you type, so the thing you edit is the thing you send. That alone ends the text drift, the alignment fights, and the misaligned second pass through the printer.
- Nothing should be entered twice. Past documents are saved, searchable and reusable, so duplicating last month's quotation to tweak a line is a click rather than a file hunt. The client address book builds itself from saved documents, and the revenue overview reads real money in and out. The office maintains nothing by hand.
- Status follows the money. A payments ledger on every invoice records date, amount and method; the balance updates live and the status derives itself from unpaid to partial to paid. Payment details, a bank block and a scannable UPI QR code sit on the document so clients can pay the exact balance.
Taking the Workflow Into the Field
The dashboard fixed the office, but it still assumed someone was sitting at it. The raw material of a quote rarely starts at a desk. It starts on site, as a handwritten job sheet or a few lines the contractor reels off between calls. Turning that into a document still meant going back to a screen and typing it all in again. So the next step was to meet the work where it actually happens, on a phone, in a chat. The contractor already lives in messaging all day, so I made the capture surface a Telegram assistant rather than one more screen to learn. It did not start as broadly as it ended. The first version was photo-first: snap the handwritten sheet and let the assistant read it. That worked, but it still assumed the job was already written down, and on site the contractor was usually on the move with nothing to photograph. Voice came next, and it proved the most natural input of all. Dictating a quotation as a few spoken lines needs no camera and no typing, so a photo, a PDF, typed text and a voice note now all arrive at the same place. The flow follows how a contractor thinks, not how a database wants its data:- Snap it or say it. Send a photo of the handwritten sheet, a scanned PDF, a typed line, or a voice note describing the job. The assistant reads the handwriting or the speech and turns it into a draft invoice or quotation.
- Nothing lands without a nod. Handwriting and speech are fuzzy, so the assistant always shows the parsed job and waits for a tap before anything reaches the books. A misread figure is caught in the preview, never in the accounts.
- Build it point by point. A job is usually worked out one item at a time, so a draft can be grown the same way: record a point, add another, and submit only once the whole job is in.
- Repair a point, do not redo the job. Reading handwriting and speech will occasionally slip, so if one line comes out wrong the contractor taps to edit it, picks it from the list, and resends just that item as a fresh photo, voice note, PDF or typed line. The assistant re-reads it and swaps it in. A finished invoice or quotation can be corrected the same way after it is saved: pick the document, pick the point, send the right version, and the change shows up live on the dashboard with the total updated. A single misread never means starting over.
- Close the loop on money. Record a payment, see exactly who owes what and for how long, and send a client their document as a link with a ready WhatsApp message, all without opening a laptop. A weekly summary lists outstanding balances so chasing payments stops depending on memory.
Under the Hood
The engineering is deliberately low-drama, in service of the two experiences above. Both products are vanilla HTML, CSS and JavaScript, with no framework and no build step, so they load instantly and the firm can have the code understood and edited years from now. The dashboard treats the cloud (Supabase Postgres with row-level security) as the source of truth and local storage as an instant cache, so a flaky connection never stops the office from billing. The letterhead is rebuilt in code and rendered client-side with html2pdf.js, so the on-screen preview and the emailed PDF are byte-for-byte identical, with measurement-based pagination keeping headers, footers and totals where they belong. Email sends through a serverless function via Resend, and several documents for the same client can go out together in one message. The field assistant runs the same way, as a Telegram webhook on a serverless function: Google's Gemini reads each sheet or voice note into structured fields, and the draft is written to the same Supabase source of truth the dashboard streams from, so it appears on screen the moment it is confirmed. The confirm-before-save rule keeps an AI misread out of the books. For a small business, longevity and load speed beat developer convenience every time.Audited and Hardened
With both products live, I put the whole codebase through a senior-level review across architecture, security, data access, performance, accessibility and observability, then acted on what it found.- Security, end to end. Row-level security keeps the data locked to the owner, the service-role key never reaches the browser, and the Telegram assistant is gated by a secret token and an allow-list. The public share links were hardened, the automation and email endpoints scoped down to the owner, and the marketing site given a content-security-policy, the usual security headers, and subresource integrity on every third-party script.
- Accessibility to WCAG 2.2 AA. The marketing site gained keyboard-operable navigation and gallery, proper landmarks and form labels, stronger colour contrast, and animation that steps aside for a reduced-motion preference, so the experience holds up for everyone, not just a mouse on a fast machine.
- Resilience and visibility. Every outbound call, to Supabase, Gemini, Resend and Telegram, now has a timeout and a log, so a failed send or a missed reminder leaves a trail instead of vanishing. Shared money and formatting logic moved into one tested module, and every change shipped through a preview deploy and a smoke test before it reached the live site.
Platform Evolution
Lessons
- Map the journey before the feature Walking the office through how a quote was actually made, reused and chased told me what to build far better than any feature list would have. The dashboard solves a workflow, not a wishlist.
- Trust is a design problem, not a copy problem The firm's credibility was already real; it just was not legible online. Animated proof, counting statistics and a named client wall did more for perceived capability than any amount of "about us" prose.
- Derive state, do not set it Letting invoice status fall out of the payments ledger, and letting the address book and revenue build themselves from saved work, removed an entire class of human error. The books stay honest because nobody has to remember to update them.
- Match the real identity, then keep tech boring Rebuilding the printed letterhead in code is what made the dashboard feel like theirs, and choosing no framework is what will keep it alive for years. The least glamorous decisions did the most work.
- Automate the typing, not the judgement The field assistant reads a sheet or a spoken note in seconds, but it never commits anything by itself. The person still approves every draft and every figure. Handing the machine the tedious part while keeping a human on the decision is what makes an AI feature safe enough to sit next to someone's accounts.
- Meet the work where it is, and let people fix it The assistant began with photo capture, but the most natural input proved to be a spoken one, which removed the last bit of friction between a job on site and a draft in the books. And because reading handwriting or speech will sometimes slip, every point stays repairable on its own, in a draft or in a saved document, so relying on the bot never means risking the whole job on a single misread.
FAQ
By mapping two journeys first: the prospect who needed to gauge the firm's credibility in seconds, and the office stuck in a slow quote-to-cash flow. Those maps, not a feature wishlist, set the scope. The website answers the trust problem and the dashboard answers the paperwork problem, and a single rebrand ties them together.
The audience is busy clients who want answers fast. A single narrative page guides them from a hook to the firm's promise to proof, with pinned storytelling and a horizontal project showcase. Every motion effect is desktop-pinned but mobile-light, respects reduced-motion preferences, and degrades gracefully if the animation library fails to load.
It is derived, not set. Each payment on the ledger records its date, amount and method, the balance updates live, and the status moves itself from unpaid to partial to paid. The revenue overview then reflects real money received and outstanding rather than figures someone remembered to mark off.
The document is rebuilt in HTML and CSS to mirror the firm's printed identity, then rendered client-side with html2pdf.js. The on-screen A4 preview and the emailed PDF come from the same markup, so they are byte-for-byte identical, with measurement-based pagination that keeps headers, footers and totals where they belong.
Both are vanilla HTML, CSS and JavaScript on purpose. The site loads instantly with no build step, and a small business can have the code understood and edited years from now without chasing a dependency tree. For this client, longevity and load speed mattered more than developer convenience.
It is a capture surface for the field, not a separate app. A photo, PDF, typed line or voice note is read into a draft invoice or quotation, the contractor confirms it, and it lands in the same Supabase source of truth the dashboard uses, appearing there live. The phone and the desk are two windows onto one set of books.
Nothing is saved without a human tap. The assistant shows the parsed job and waits for confirmation, so a misread figure is caught in the preview rather than in the accounts. The model handles the typing while the person keeps the judgement.
Only that line is redone, never the whole job. The contractor taps to edit the point, picks it from the list, and resends just that item as a photo, voice note, PDF or typed line; the assistant re-reads it and swaps it in. It works on a saved document too, with the change appearing live on the dashboard and the total updated. Point-level repair is what makes the assistant trustworthy enough for real billing.
Row-level security locks the data to the owner and the service-role key never reaches the browser. The Telegram assistant is gated by a secret token and an allow-list, the share links are hardened, and the marketing site runs a content-security-policy with subresource integrity on third-party scripts. Every outbound call has a timeout and a log, and changes ship through a preview deploy and a smoke test.