Amit Kanswal

I build the tools other engineers build on.

Contentstack sells the engine behind a website's content — but not the website itself. My job for the last six years has been everything around that engine: the app store where customers find add-ons, the place outside developers go to publish them, the ready-made starter websites, and the toolkit all of it runs on.

It means the people I build for are mostly other engineers — inside the company and at partner companies I'll never meet. That changes the job. A normal feature can be fixed next sprint if it's wrong. A tool that hundreds of developers already built on top of cannot: change it carelessly and you break their work, not just yours. Most of what I've learned is about making things that stay reliable while everything around them keeps moving.

Six years, measured

Pulled from the systems my team actually worked in — the ticket tracker, the code repository, the engineering wiki. Every figure here traces back to a record rather than to memory.

Alongside those: 73 design and decision documents written or revised, 14 reference websites and 20+ editor apps built and maintained, and roughly 25 formal production releases assembled and shepherded.

The number I'd point at is the reviews. Reading 891 of other people's changes is not what gets anyone promoted, but it is what a team feels when you leave.

These figures span public and private repositories across six years. A public GitHub profile shows only a fraction of them, because most of this work lived in private company repositories.

What I've built

Six areas, roughly in order of how much they mattered. Each has an optional panel with the technical detail, for anyone who wants it.

Four years · 402 pieces of workThe app store and the developer portal

Two connected products. One is the storefront where customers browse add-ons for their content system and install them. The other is where outside developers go to publish those add-ons — registering an app, setting up its permissions, cutting a version, pushing it live.

Together they decide who can install what, at which version, with which permissions, in which country's data centre. It is the part of the business that lets other companies extend the product, so a mistake here is not a bug in one screen — it is a partner unable to ship.

This was the largest single area of my work, and I stayed with it for four years.

13 seconds → 0.15 secondsMaking it fast

Both products had grown inside one enormous codebase, so any change to either meant rebuilding and re-releasing everything. I was a founding member of the initiative that split them into independently deployable pieces.

The headline result is below. It is worth pressing the button.

Two years as its ownerThe toolkit outside developers build with

Other companies build small apps that live inside Contentstack's content editor — a video picker, a translation panel, a dashboard. For security those apps run walled off from the editor and can't touch it directly. They talk to it through a toolkit, and from 2024 that toolkit was mine to own: the design, the code, the documentation, the releases, and the questions from developers using it.

The interesting constraint is that I could never break anything. Every app already built on it keeps working or partners lose their product. So the work was mostly about adding real capability without disturbing anything already there.

The two largest additions: letting apps securely reach the rest of the platform rather than a short fixed list of actions, and letting them write data back into the editor rather than only read it — delivered in four stages, from simple fields up to whole entries.

Seven years · 14 websitesThe starter websites

Contentstack sells the back end of a website without the front end, so customers have to build their own. To save them weeks, the company gave away fourteen ready-made websites — one for each popular way of building them — that a developer could copy, point at their own content, and have running in minutes.

Keeping fourteen websites current for seven years, while every one of those fourteen technologies kept changing underneath, was largely my job. When a new platform capability shipped, getting it into all fourteen and out the door was mine. This fleet holds the single largest concentration of my code changes — more than any other area I worked on.

One of them was accepted into a major framework vendor's own official examples collection, which put it in front of that framework's entire community rather than only customers who already knew where to look.

20+ builtThe apps inside the editor

Small, self-contained tools that plug into the content editor and solve one editorial problem each. I built or maintained more than twenty.

The one I'd talk about in an interview is an editorial workflow board: a drag-and-drop board showing every piece of content grouped by where it sits in the approval process, so an editor can see what's in draft, what's in review and what's ready, and move things along directly.

Building it turned out to need a search capability the platform didn't have. Rather than working around it, I added that capability to the shared toolkit and told the rest of the organisation it existed — and other teams went on to use it when they hit the same wall. A requirement for one app became something everyone could build on. That is the version of this job I want more of.

Five yearsTesting, and keeping releases safe

Apps that run inside another product's editor are awkward to test: an automated test has to log in, navigate the host product, find the walled-off frame, and only then touch the thing it came to check. No pattern for this existed, so I built one, then rolled it out until every marketplace app had tests standing between it and a bad release.

Alongside that, I was often the person assembling the formal paperwork for a production release — what is shipping, at what version, to which regions, with what evidence — and sequencing the order things went out in. One release bundled twelve interdependent components at different versions.

Three yearsThe person things got escalated to

Because I owned the toolkit and much of the app surface, I became the person support and customer success came to when a customer said an app was broken. The work is detective work: take a vague report, reproduce it, and work out whether the fault is ours, the partner's, or the customer's own setup — then fix it or hand it over with a clear explanation.

Most of the time it turned out not to be our fault. Saying so clearly, with evidence, was as much of the job as fixing the ones that were. 269 issues raised and routed to the right team is what that looks like counted up.

How I decide

Five things I believe, learned the slow way.

Six years, one company, three promotions

• 2023 → present Senior Software Engineer — Developer Platforms / DevXOwned the developer toolkit; founding member of the micro-frontend rebuild; routing design and position paper Contentstack · Pune
• 2022 → 2023 Software Engineer IIThe workflow board; built the end-to-end testing approach; co-authored the team's engineering standards Contentstack
• 2020 → 2022 Application EngineerThe starter website fleet; editor field extensions; first integration designs Contentstack
• 2019 B.E., Electronics & Telecommunications Mumbai University

• Runner-up, Contentstack Hackathon — a prototype that was later built into the product.
• Above & Beyond award, four times — for consistently exceeding expectations and delivering high-impact outcomes.
• Mentoring and code review — ran internal sessions on performance, TypeScript and testing, and mentored junior engineers throughout.

What I work with

A working piece of it

This one is for engineers, and it is safe to skip.

It is a live, working version of the validation design described above. On the left, a mock third-party app in a genuinely walled-off frame. On the right, the host side that decides what to accept. Press a preset and send it — or edit the data and break it however you like.

• Send “schema violation” and the fast check rejects it immediately, naming the exact fields at fault. Nothing is saved.
• Send “valid” and it is accepted and saved, then the slower checks come back clear.
• Send “soft warnings” and it is saved first, with the warnings arriving afterwards — because a slow rule is not allowed to block someone typing.