We had built 100+ APIs for identity verification — things like PAN and Aadhaar checks — used to onboard new customers. Every bank wanted a different combination, in a different order, so every bank ended up with its own custom build, done by them or by us. I designed the platform that turned that into something one person composes on a canvas — and returns through a single API call.
What I owned — I owned this end to end — from the first workshop to what shipped. That meant talking to the people who'd use it, mapping out how the whole thing should work, designing every screen, and building the design system behind it. When Connect v1 became v2, and then v3, I stayed on all the way through.
Cross-functional collaboration with Leadership, Product Managers, Solution Engineering, QA and Sales Operations.
Those 100+ services covered everything from OTP checks to face match and bank verification. Banks and NBFCs — non-bank lenders — used them to confirm a new customer's identity before onboarding them.
The catch was that no two customers wanted the same ones, in the same order. Vertex Bank might want a phone OTP, then a PAN check, then a penny-drop check to confirm the bank account. The next bank would want a completely different combination, sequenced differently.
So every customer became its own project: assign a team, integrate one API call per service, ship it, then start over for the next one.
That worked while the customers were large. It stopped working as they got smaller — the cost of serving a client barely moved, but the contract shrank.
Capacity, not demand, was setting how far down-market the business could go.
A hundred services on one page is a list, not a system. Search only helps people who already know what the platform calls the thing they need — which excludes every new user. So I grouped services by the job they do, then ran a card sort to test whether that grouping matched how people actually think.
Nobody disputed the grouping afterwards. In a company where every service has an owner with a view on where it belongs, that silence was the research paying for itself. These are the three decisions that followed.
Hovering any node or category gives a two-line explanation; configuration opens in a right-side panel. Expose everything at once and the builder becomes the form it was replacing.
A place to plug in your own outside connection — with its own keys and credentials — folded into the same flow and returned through the same single call. Some things a customer needs can never be one of the pre-built services. Rather than force-fit those into the existing system, I left a door open.
Published and draft tracks, numbered versions with author and timestamp, restore and publish. Proposed in the scoping room before anyone requested it — in regulated finance, knowing who changed what, when and why isn't a convenience, it's the difference between a platform an auditor accepts and one they don't.
How Connect v1 became v2, then v3 — why it started, what changed, how it worked, and what happened next.
My regional CEO turned it into a product question: what if the flow could be composed in a portal instead of assembled by a team? Scope wasn't handed down from there. It was set by a recurring cross-functional group, plus a full-day workshop to decide what was actually worth building.
My job in that room wasn't to take requirements. It was to hear what each expert described and push it further than they'd framed it.
The original idea was to let banks build their own verification flows themselves. That idea didn't survive first contact with the problem. Composing a flow correctly means knowing dozens of small rules — like when a dedupe check (catching duplicate applicants) is needed, or what to do when a face match comes back uncertain. That's knowledge the company had. The banks didn't.
So the product changed shape: not no-code for customers, but low-code for our own implementation team. Same architecture, honest about who could actually use it.
Drag services onto a canvas. Connect them into a flow. Publish. The change that mattered most sits underneath: the composed flow returns through one API call.
Before, integrating a client meant hitting each service separately and stitching the results. After, the whole verification journey happens through one API call. That's what collapsed the work — and it made the product simpler on the client's side too, which was never the stated goal but turned out to matter in sales conversations.
One integration per service — stitched together by a team, per client.
One endpoint. The sequence lives in the flow, not in the client's integration.
Connect v1 shipped. We showed it to leadership and it landed well. Then we gave it to our own implementation team and put them on real work with smaller clients. They hit two walls.
A flow would fail, the output would be wrong, and there was no way to tell which of twelve nodes caused it. For a product whose entire promise is making logic visible, the failure state was invisible.
A verification journey isn't only logic — it's the pages the end customer sees. The flow could be composed, but the interface around it still needed a separate build, which put a team back in the loop.
Neither was in the original scope. Both existed because we watched people struggle.
Flows now ran, but they produced data with nowhere to look at it. So we started doing the familiar thing: assign a team per customer, build them a back-end portal. The exact pattern the platform had just removed, returning at the next layer.
The next version took the same engine and made it work for more than just identity checks — any team at the company could now use it. It also added what a company-wide tool needs: maker-checker approval, so the person who builds a flow isn't the person who approves it, plus task assignment, version history, and logs. It also absorbed a similar low-code tool from Finflux, a lending startup the company had acquired, which had built something almost identical for approving loans.
This final version closed the last gap. Every time a customer goes through a flow, our product gives it its own ID and turns that into a report a bank's own staff can log in and read. When a customer completes onboarding at Vertex Bank, someone at Vertex Bank can open it and see the report — without anyone at the company building them a portal.
Each version contains the one before it. Connect v3 has everything v1 and v2 could do, plus case management on top.
The same reflex — assign a team, build it custom, per customer — kept reappearing at each layer. Each product removed one more instance of it.
Setting up a new customer used to take a whole team, over weeks. Now one person can own the whole flow. For design, that means the hard part — the structure — is already decided. All that's left is picking type and colour for each client.
New products get adopted because they're new. Teams only migrate flows that already work when the new thing is genuinely better.
We found the debugging problem by watching our own team struggle with real client work — that's the right way to find it. But next time, I'd design what happens when something goes wrong at the same time as what happens when it goes right, not after.
The idea of letting other people build on top of the platform, and letting customers bring their own tools — that idea was possible from day one, I just didn't reach for it until v3. If I'd started there, v1 probably would have been built differently from the very first day.
I designed version history to work the way Figma's does. Engineering built it differently, in a way that was easier for them to maintain — so I went with their version instead. It wasn't worth fighting for mine when theirs worked just as well.
Connect v3 was built to keep growing. These are the natural next steps — not things we've already shipped:
Connect v3 already lets customers plug in their own endpoint inside a flow. Extending that from one endpoint to full ownership of their own APIs is the same idea, taken further.
Every product so far concentrated capability inside the platform team. A marketplace inverts that: partners contribute the next hundred services instead of us building all of them.
The same problem Connect v1 solved with a visual builder — composing verification logic without writing code — is one step further from being solved with plain language instead of a canvas.
Want the thinking behind another project?