iBricks — a B2B SaaS for contractors across construction, HVAC, electrical, and plumbing.
The seams nobody sees.
- Three years as the founding designer of iBricks, a B2B SaaS for contractors across construction, HVAC, electrical, plumbing. Fifteen modules, four user types, mobile and desktop end-to-end, with a network effect built into the product itself.
- Designed for retention and expansion from day one. Contractors don't just use features, they move through a revenue chain, from tender discovery to payment recovery, inside one product.
- Built decision systems, not dashboards. AI-assisted workflows reduce research and data entry effort by 60–70% and turn hours of manual work into minutes.
- Survived two complete tech rebuilds without redesign because the product logic was defined beyond screens.
A contractor opens his phone in a Thursday afternoon meeting. One project he hasn't checked in two weeks is running ₹25 lakh over budget. The AI usage ticker reads $0.75 against $5.00. Both numbers update live.
The product meters itself while it meters the business. That's not a dashboard feature. That's the design philosophy.
Three years ago iBricks wasn't a product you could use. There was a version, built with one engineer, so confusing the founder got lost while explaining it.
This is what got built between then and now. And how.
The First Call
May 2023. Vivek had built a v1 with one engineer. He couldn't explain it without losing the thread.
He shared his screen and walked me through it. The point was to show me where users got stuck.
He came with one ask. The billing module. He didn't have the confidence to scope more.
Before I opened Figma, I asked him one question.
When a contractor stops using this product, why?
If a founder can't answer that, the product gets built blind.
I designed project first. Then the billing module that fed into it. Edge cases included from day one.
When he finally saw his product the way he had described it in his head, something flipped. He started talking about the next module. Then the one after. Then ten more.
We didn't build to a flat roadmap. We shipped module by module, in the order Vivek could see one. Design didn't replace the roadmap. It unblocked it.
Four contracts replaced, one product
Once one module worked, the brief grew.
Tender discovery. Bid analytics. End-to-end project execution. Procurement. Workmen attendance. Payment recovery. A contractor ecosystem that became its own section in this case study.
Every one of those is a separate product in most companies. One tool for billing. Another for procurement. A spreadsheet for attendance. Email for tenders. Four vendor contracts the customer keeps writing checks for.
iBricks consolidates them into one product. That consolidation is the wedge. Every additional module a customer adopts is expansion revenue iBricks captures and a competitor's contract that doesn't get renewed.
Why one-module customers churn
Once Vivek saw billing and project work, he stopped thinking in modules. He started thinking in flow. So I stopped designing screens and started drawing the chain.
Two chains, actually. One going out, one coming in. Both anchored at the same project.
The cost chain runs from a tender search to a vendor payment. The revenue chain runs from a project invoice to recovery. The contractor is paying vendors while billing the client.
I drew the full chain before I drew the next screen.
The chain is the NRR (Net Revenue Retention) engine. A customer who uses one module churns inside a year. A customer who uses three doesn't. iBricks was designed to pull the customer deeper into the chain on purpose.
Most product design starts with screens. Screens lead to features. Features lead to products that work in isolation and break at the seams.
I started with the seams.
Where B2B accounts actually churn
A project dashboard had to serve four people who walked into it for four different reasons.
Site engineer wanted his next action. Project manager wanted project health. Procurement officer wanted his incoming request queue. Owner wanted the cross-project layer.
Same data. Same component. Different default per role. Site engineer's view is mobile-first, three-fields-deep, action-led. Project manager's is desktop, cost-vs-budget on top. Procurement defaults to the PR queue — what's waiting on review, what's ready for a PO. Owner's lifts to the cross-project view.
This isn't just visual tuning. It's enforced at the permission layer.
During team onboarding, the admin decides which projects each user can access, and which modules within those projects. A site engineer assigned to Project A doesn't see Project B's PRs. A procurement officer not on the construction side doesn't see workmen attendance.
Role-based access is the floor. Role-based defaults are the polish on top.
A B2B account doesn't churn evenly. It churns at the role with the worst experience. If the site engineer can't approve from his phone, the account stops buying add-ons. If the founder can't see cross-project cash flow, the next project pack never gets bought.
Role-tuned defaults are how you protect activation per role. One dashboard to maintain. Four jobs served.
How one product serves ₹5 Cr and ₹50 Cr customers
The chain looks automatic from the outside. Award a tender. Get a project. Raise a request. Get a PO (Purchase Order). Mark delivered. Get an invoice. Send for payment.
It is not automatic. Every step passes through a human approval layer. And the approval layer is itself a design problem.
Some companies want a single approver. Some want two in sequence. Some want level-wise approvals tied to roles. Some want approvals turned off for one area and on for another. Some want rules that vary by project.
So the approval layer became a configurable engine. Not a hardcoded gate. The company sets the rules. The system enforces them. Work moves forward when humans say so.
This is an ACV (Annual Contract Value) decision, not a UX decision. Hardcoded approvals lose enterprise deals because every enterprise has its own governance. No approvals at all lose them too because finance refuses a tool that can't enforce control. The configurable engine is the reason iBricks can take a ₹5 Cr customer and a ₹50 Cr customer on the same product.
The seams are where multi-role B2B products live or die. The screens get the credit. The seams do the work.
The product as its own GTM channel
The hardest module wasn't construction. It was contractors.
A contractor in India isn't a single user. He's a hub. He gets a project. He breaks it into pieces. He sends those pieces as RFQs (Requests for Quotation) to other contractors who specialize in HVAC, CCTV, electrical, plumbing. Some take the work. Some negotiate. Some pass.
The subcontractor accepting an RFQ becomes a contractor in his own right. He gets a work order. He runs the piece. He has his own subcontractors below him. He sees the same product, the same way, with the same flows.
The product is a network, not a tool.
This is the company's GTM (Go-to-Market) hidden inside the product. Every subcontractor who accepts a work order on iBricks is a future paid account. CAC (Customer Acquisition Cost) drops as the network grows. The contractor ecosystem isn't a UX layer. It's the distribution channel.
A contractor on Project A is a subcontractor on Project B at the same time. Both views live. Both have to make sense to the same person on the same login. Same user. Two opposite roles. Both correct.
The product's tagline is "Har Contractor ka Humsafar."Every contractor's companion. Construction, HVAC, CCTV, electrical, anyone in the chain. The product had to design itself around that line.
Pricing was the hardest screen
The most recent work was the monetization architecture. Five pricing dimensions in one purchase decision.
A one-time onboarding payment that includes a hardware tool. A Bluetooth laser distance meter that auto-fills measurement sheets during billing. The hardware is a perceived-value lift and a soft lock-in. Customers don't return SaaS subscriptions when there's a physical asset on their desk.
Project packs at four tiers. Each pack bundled with AI credits, because parts of the product use AI to extract BoQs (Bill of Quantities), derive material lists, and pull quantities from drawings. AI credits are gross margin. Bundling them at a curated rate protects it.
Pay-as-you-go credits beyond the bundle. Heavy users hit a ceiling and top up. That's expansion revenue without forcing an upgrade.
Enterprise as a custom path. Builders with fifty-plus projects don't fit a checkout. A custom path raises the ceiling.
And under all of this, three permission states. Paid users see the full product. Free users see a curated subset. Free is an activation funnel. Team members get a default the company can modify per person.
That's the architecture.
The brief Vivek gave me had seven storage tiers. As a designer my job is not to render a brief. It's to ask if the brief is right for the user. Seven tiers at the point of purchase is decision fatigue. Decision fatigue is a conversion drop. We tightened it.
A founder gives you a brief. The brief is not always right. A vendor renders it. A consultant runs the math on it.
Where AI saves cost, where it leaks margin
I use AI in two places. In the product. And in my process.
In the product, AI extracts BoQs from documents. Auto-derives material lists. Pulls quantities from drawings. Bulk-uploads items into the database. Each one removes hours of manual work for a real user. AI should disappear into the workflow.
AI in the product is also a margin question. Every call costs the company. Screens are designed to give the user the AI shortcut once and not let them re-trigger it accidentally. That's not UX polish. That's COGS (Cost of Goods Sold) protection.
In my process, AI is a stage. Not a tool.
The stage is for brainstorming, decision logic, edge-case pressure-testing, documentation.
The skill is knowing when to skip it. The monetization architecture, the contractor ecosystem, the role-based dashboards: AI accelerates the wrong stage on those. Strategy stays human.
A solo designer using AI well ships a roadmap that used to need a team. That collapses design cost per feature. For an early-stage SaaS, that's the difference between extending runway and raising sooner than you wanted to.
Why the design survived two rebuilds
Three years of decisions used to live in my head. Now they live in markdown files. One per module. Why this layout. Why three steps not five. Why this user sees this and another doesn't. Why we said no to that feature in v3.
Not a style guide. Not a component library. Both of those exist too. This is the layer above. The thinking.
The design didn't break when the code did.
When the product survived two complete tech rebuilds, the design layer did not need to be rebuilt. The screens were translated. The decisions were already documented. Engineering velocity stayed intact across both rebuilds. That's revenue protected.
For a founder reading this, the documentation layer is also a hiring discount. Your next designer onboards in a week, not a quarter. Your next PM doesn't ask the founder why a flow looks the way it does. They read the file.
Vivek's recommendation, on LinkedIn
What three years actually proves
The product hasn't launched. The architecture has.
Vivek came with one ask. The product has fifteen modules.
Numbers will follow launch. The architecture is already there.
iBricks isn't a SaaS
The category page calls it construction software. Modules. Subscriptions. PLG.
That's the surface.
Underneath, iBricks is a phase one move. Operating layer today. Payment infrastructure tomorrow. Embedded credit the year after. Material distribution the year after that. Each phase compounds on the data the previous one captured.
The design brief was for the foundation, not the surface.
Role-based access routes payments next year. Configurable approvals route credit underwriting flows the year after. The hardware bundle is the entry credential for an ecosystem the contractor doesn't leave.
I could have designed for the surface alone. Easier brief. Faster ship.
I designed for what phase five will need on top of phase one.
That took three years.
What this means if you're already shipping
Most of you reading this don't need a founding designer. You have a product. It works. Users are on it. You're past zero.
What you need is a designer who moves a metric. Here are the levers I work on.
Activation and friction audit. Why users hesitate, where they drop, what blocks first value. Output is a prioritized list of design fixes mapped to your funnel.
Design system that ships faster, not prettier. An extension that fits the codebase you already shipped, so engineering velocity goes up and design cost per feature goes down.
New module that fits the retention chain. New screens that don't break the seams that already work.
Pricing flow that converts under complexity. Multi-dimensional purchase decisions, free-to-paid funnels, expansion revenue mechanics.
Documentation layer that cuts your design hiring cost. Your next designer onboards in a week, not a quarter.
Founding-designer thinking, applied to a product that already works. That's the offer.
Most B2B products fail at the seams between modules. The screens work. The connections don't. Repeat purchases stop there.
Where this fits
Most teams don't need more screens. They need clarity on how the product actually holds together.
That's where I work.
I operate at the layer where workflows connect, decisions happen, and product complexity either scales or breaks.
If you're building something multi-module, multi-role, and revenue-critical, this is the difference between adding features and building a system that actually works.
If your product is getting complicated, let's talk.