Building the test-authoring layer in days, not months, at Appliqation

Appliqation is a test-management platform built for AI-accelerated development — what the team calls “the quality layer for AI code.” Its premise is simple: AI now writes code in a fraction of the old time, but testing has not kept pace. Appliqation closes that gap with a continuous quality loop, from test generation through execution, evidence, and analysis.

At the center of that loop is authoring. Testers write and manage their test cases in a spreadsheet-style grid built with Handsontable — the surface Appliqation markets as FastSheet.

This is the story of why the team chose to buy that grid instead of building it, and what that decision freed them to do.

The challenge

Testers have a long-standing habit: they write test cases in Excel or Google Sheets, then import them into their tool of choice. The reason is the authoring experience. Spreadsheets let them copy a case, change a value, and have the next one ready in seconds.

Most testing tools break that habit. They offer forms, one test case per page, with a click to the next screen and back again. That constant context switching is admin work, not testing.

Appliqation wanted the spreadsheet authoring experience inside the product — but governed. Testers needed the freedom to write the way they always have. The platform needed structure it could rely on in the backend.

Authoring is not a side feature here. It is the base of the product.

If I don't have test cases, there's nothing else I can do. Test-case writing had to be robust, reliable, and stable.

Evaluating the options

The team started by building the grid themselves in React, in late 2024. When AI tools matured, they tried generating it that way too. The initial cases worked. Extending them did not.

Spreadsheets are deceptively complex. Users cut, merge, paste, and move cells in ways that are hard to predict. Each new requirement meant more refactoring, and the cost kept climbing.

So Appliqation looked outward. They evaluated AG Grid, commercial and open source solutions, and their own custom build. They picked three critical cases and ran proof-of-concepts against both AG Grid and Handsontable.

AG Grid was the closest competitor, but it had drifted from the feel of a real spreadsheet. The cell-level control the team wanted was less direct, and the documentation was harder to work through. Handsontable was simpler, closer to actual Excel and Google Sheets behavior, and offered granular control at the cell, row, and column level — with clear documentation and APIs for before- and after-paste behavior.

If I had to build this myself, I'd have to forget about my product and spend two years on the grid alone.

The solution

Handsontable became the sole authoring interface in the product. Around 25 to 30 customizations sit on top of it. Two mattered most.

Modular test cases with parent–child structure. What a tester sees as one continuous sheet is, in the backend, a set of separate test cases, each with its own steps. The team keyed these with UUIDs (Universally Unique Identifiers) so a parent case and its child steps stay linked. The IDs persist when rows are copied, pasted, or moved — a requirement at the scale they are planning for.

Guided row behavior. Type a step, and it drops to the next row beneath its parent. The parent–child relationship stays clear without the tester having to manage it.

Because the authoring foundation was stable, the team could focus on the backend and on AI. When tester behavior shifted toward AI-generated test cases, Appliqation added a generation flow directly into the grid: AI proposes cases, the tester approves, and they land in the sheet with a temporary highlight for the session.

That integration shipped in under a day.

I added AI test-case generation in less than a day, because everything had an API. I just called it.

Test cases are strings, and Handsontable gave the team the structure and guide rails to keep that data usable.

The results

The decision to buy rather than build paid off in time, stability, and adoption.

• Months of UI development saved. Building and stabilizing the grid in-house would have taken an estimated three to four months. That work moved off the team's plate.
• A stable base that removed regression risk. New features plug in without breaking what came before, so the team moves forward instead of backtracking to fix the foundation.
• Adoption on sight. Around eight in ten testers are impressed by the authoring screen before the demo even begins. For people who have spent years in Excel, it feels familiar immediately.
• Built to scale. More than 1,000 scenarios run on Handsontable today, each with its own grid. The architecture is designed to reach hundreds of thousands.
• Performant page loads. The number of test cases in a single scenario or test set like Regression can even go to 500–800, i.e. 2,000–3,000 rows. The authoring and loading experience is still excellent.

On its own site, Appliqation positions this as FastSheet — an “Excel-like interface” that is “fast, familiar, no learning curve,” and credits it with “3x faster test creation.”

The authoring experience is completely off my shoulders. People don't need to be told how to use it. They see it and start writing.

What's next

Appliqation stays on its current Handsontable version. It works, so there is no reason to change it. Arijit is already looking ahead. He wants to describe a customization in plain language and watch Handsontable build it. That capability is arriving — an AI assistant now lives in the documentation.

The authoring layer is stable. Appliqation is now building on top of it. The grid is not the story anymore. It is the foundation that makes the story possible.

Arijit has become an advocate. He recommends Handsontable to other founders building data-heavy applications, and points them to the same starting place every time.

I tell them to go check out Handsontable. Everything is out of the box. We just built on top of it and added some guide rails.