DAY
--:--
Ankit Singh

--:--/Architect

Principal Architect · Verto · Pune

Everything customers touch, and most of what holds it up.

Founding engineer at Verto, a cross-border payments platform that started with two developers and a QA and now runs on an engineering team past fifty. In between: the client platform, the admin system that answers for it, the vendor integrations underneath, and the AWS estate all of it sits on.

01

What I actually build

The platform is private, so this is the shape of the work rather than the source.

01

Two surfaces, one access model

Problem
A cross-border payment fails in ways the customer cannot see: a vendor queue, a compliance hold, a corridor that closed at four in the afternoon local time. Support has to answer for it in minutes, and the customer has to be able to act on the answer.
Decision
The client platform and the internal admin were built as one system on a shared access model, role-based from its first draft. Same data, two audiences, different permissions rather than different truths.
Tradeoff
Every product change then lands twice, and the surfaces have been rewritten several times since. Each rewrite happened because the model had outgrown the screens, never the other way round.
TypeScriptReactAngularRBAC
02

Onboarding, Cards, Payment Links

Problem
Regulated onboarding is where a business either gets in or gives up, behind documents, checks and a queue nobody outside can see. Cards and payment links then have to move money with no one in the loop at all.
Decision
Each shipped as a product in its own right, with its own state machine and its rules held as data. Requirements change faster than a release cycle, so the flows read their constraints rather than encode them.
Tradeoff
Configurable rules are harder to reason about than hard-coded ones, and they need their own tooling to stay legible. The alternative is a deploy every time a jurisdiction changes its mind.
OnboardingCardsPayment links
03

Vendors that agree on nothing

Problem
Every provider arrives with its own model, its own failure vocabulary and its own private definition of done. Customers want one API and one mental model, and they are right to.
Decision
An adapter for each vendor, a single internal model behind them, and capability published as data, so a caller learns what a corridor supports before trying it rather than after.
Tradeoff
The abstraction lies a little, because some corridors genuinely cannot do what others can. A documented lie beats a surprise at settlement.
Node.jsRESTIntegrations
04

An estate you can lose and get back

Problem
A single cloud account is one blast radius, one bill and one set of credentials. Disaster recovery that has never been exercised is a claim rather than a capability.
Decision
The AWS estate moved into Organizations, with accounts separated along real boundaries, and the DR setup was built and then actually run. Much of the delivery tooling the team uses came out of the same work.
Tradeoff
Account separation slows everyone down before it protects anyone, and DR is the one project whose success looks like nothing happening at all.
AWSOrganizationsDRDevOps
05

Tooling for a team that grew twenty times over

Problem
Three engineers agree by talking. Fifty cannot, and the constraint becomes how consistently code gets reviewed long before it becomes how fast anyone writes it.
Decision
Internal tools carry the standards, including a code reviewer built in-house that reads what the team ships and applies what a style document never managed to.
Tradeoff
Internal tools have users who know exactly where you sit. They are never finished, and they rot the week nobody owns them.
Internal toolsCode reviewDeveloper experience
02

Where the work has run

Verto

Founding engineer, now Principal Architect

A Y Combinator fintech clearing on the order of $25B a year across 49 currencies, with Unilever and Maersk among its customers. Two developers and a QA at the start, an engineering team past fifty now. The work runs from the client platform and the admin behind it to the cloud the whole thing sits on, with the vendor and security work in between.

Now

Locusnine Innovations

Full-stack, then lead

Enterprise work on TypeScript, Node, Angular and serverless, including an IoT learning platform built on Angular and a canvas editor, and real-time telemetry for an industrial client over WebSockets and DynamoDB. The first versions of what became Verto were written here too. Verto acquired the company in 2022, which is how the team and the work arrived where they are now.

Until 2022

WizPanda

Engineer, in a team of three

A CEO, a CTO and one engineer. Two children's apps came out of it, one shipping through Vodafone and Telefónica in Spain and Brazil in four languages, the other a video streaming product for an Indian customer, built across Ionic and React Native. Also a marketplace for home construction materials, and several smaller products that never needed a second version.

Before that

CauseCode Technologies

Engineer, and the first job

A team of six, healthtech web and mobile out of Pune, on the Grails and Groovy stack the shop ran on. Converge came out of that bench: a conference app for attendees, browsing tracks and sessions, booking and enrolling, built on Grails and MongoDB with a TypeScript front end that also shipped as a mobile build. It was shown at Mobile World Congress in Barcelona. The other one was Curious, a self-tracking health product, which is a thing I have apparently never stopped building in some form.

Where the career started

Shri Shankaracharya Technical Campus

BE, Information Technology

The fundamentals. The rest came later and more expensively, from production.

Where it started
03

Tools, honestly

No percentages. Nobody has ever been 80% good at Node.

Working in now

  • TypeScript
  • Node.js
  • React
  • Angular
  • AWS
  • Serverless
  • Python
  • Flutter

Shipped with earlier

  • Vue
  • Groovy / Grails
  • Dart
  • Whatever the client had already chosen

Own or share

  • Cloud infrastructure
  • Disaster recovery
  • DevOps and delivery
  • Access control
  • API design
  • Vendor and payment integrations
  • Security review
  • Internal tooling

Coming next

Writing. Most of what is on this page was learned by getting it wrong first, and none of that is written down anywhere useful yet. The notes exist. The posts do not.

Happy to talk about payments, access control, or the cloud bill underneath both.