TableCraft Earns a 58.65 Proof of Usefulness Score by Building a Schema-Driven Toolkit for Drizzle ORM and React Data Tables

In this interview, we speak with Jackson Kasi about TableCraft, a schema-driven toolkit that turns Drizzle ORM tables into production-ready data APIs and React data tables. The goal is simple: stop developers from rebuilding the same admin panel and internal tool plumbing every time. ⚡

What does TableCraft do? And why is now the time for it to exist?

TableCraft turns a Drizzle ORM schema into a working data workflow: backend query APIs plus frontend React tables with search, filtering, sorting, pagination, export, joins, and type-safe integrations.

The timing matters because modern teams want to move faster without giving up control. Type-safe tooling has improved a lot, but there is still a huge amount of repeated work between defining a schema and shipping a useful admin interface. Teams still hand-build query params, filtering logic, pagination, sorting, column config, joins, and frontend table state over and over. TableCraft exists to compress that repeated work into configuration.

What is your traction to date? How many people does TableCraft reach?

TableCraft is still early-stage, open-source, and pre-scale. Its current reach mainly comes from GitHub, the live demo, and the public docs.

I want to be accurate: this is not yet a large-scale product with a big verified user base. The project is still in the public validation stage.

Current reach comes from:

• GitHub discovery
• Demo users
• Documentation readers
• Early open-source word-of-mouth

Who does your TableCraft serve? What’s exciting about your users and customers?

TableCraft is for developers and product teams building admin panels, dashboards, and CRUD-heavy business applications. It is especially useful for teams already using Drizzle ORM and React who want Airtable-like table capabilities without rebuilding every layer themselves.

The core users are:

• Indie hackers
• Startup teams
• Full-stack engineers
• Product teams shipping internal tools

What is exciting about these users is that they are usually solving real operational problems, not just exploring a novelty. When a tool saves that kind of user time across multiple screens and projects, its usefulness compounds quickly.

What technologies were used in the making of TableCraft? And why did you choose the ones most essential to your tech stack?

TableCraft is built with TypeScript, Bun, React, TanStack Table, Drizzle ORM, Hono, Express and Next.js adapters, Elysia, Zod, Tailwind CSS, shadcn/ui, Vitest, and Vite.

Those choices were deliberate. Drizzle ORM gives the project its schema foundation. TypeScript and Zod improve safety and integration confidence. TanStack Table is a strong base for advanced table behavior on the frontend. Bun keeps the development loop fast. The framework adapters matter because I wanted TableCraft to fit into real application stacks instead of forcing developers into one specific runtime.

What is traction to date for TableCraft? Around the web, who’s been noticing?

Right now, the most visible traction comes from the public surfaces of the project:

• Demo: https://tablecraft-demo.vercel.app/
• Docs: https://jacksonkasi.gitbook.io/tablecraft
• GitHub: https://github.com/jacksonkasi1/TableCraft

There is also an earlier demand signal behind the project. TableCraft builds on lessons from a related open-source project, tnks-data-table, which reached 200+ GitHub stars:

• Predecessor project: https://github.com/jacksonkasi1/tnks-data-table

I want to be precise about that: those stars belong to tnks-data-table, not TableCraft. But they do validate the problem space. TableCraft is the larger evolution of that idea, moving from a table component into a more complete schema-driven backend-plus-frontend workflow.

TableCraft scored a 58.65 Proof of Usefulness score - how do you feel about that? Needs reassessed or just right?

I think the score is fair.

The report recognized what I hoped it would recognize:

• strong real-world utility
• good technical choices
• clear market relevance

It also exposed the obvious weak spot, which is public traction. That is accurate. The product is ahead of the proof layer right now.

That makes the score useful rather than disappointing. It shows that the next step is not chasing complexity for its own sake. The next step is making the value easier to see, easier to adopt, and easier to verify in public.

What excites you about TableCraft’s potential usefulness?

The exciting part is how common this pain is. Teams repeatedly rebuild the same data table and API patterns: search, filter, sort, paginate, export, join related data, hide sensitive fields, and wire all of it to a frontend. That is a frustrating amount of repeated work for something every serious app needs. 🔁

Common repeated work includes:

• search and filter logic
• sorting and pagination
• joins and related data views
• export and permissions handling
• frontend table state and URL sync

TableCraft turns that repeated engineering work into configuration. If it works the way I want it to, it does not just save code. It saves days of engineering time across every admin panel and internal tool a team needs to build. That is the kind of usefulness I care about: reducing friction in work developers already do constantly.

Walk us through your most concrete evidence of usefulness. Not vanity metrics or projections - what’s the one data point that proves people genuinely need what you’ve built?

The strongest early proof is that TableCraft did not start from a vague idea. It grew out of a real problem that already showed developer demand through tnks-data-table, the earlier related project that reached 200+ GitHub stars.

That signal mattered because it showed the problem was real. Developers did not just want a nicer table component. They wanted a faster path from schema to working internal tools. TableCraft exists because that original demand pointed to a bigger opportunity.

The next proof layer I want to make more visible is practical implementation evidence: how much code gets removed, how much setup time gets reduced, and how quickly a real admin panel can go from schema to production-ready behavior.

How do you measure genuine user adoption versus “tourists” who sign up but never return? What’s your retention story?

For an open-source developer tool, retention looks different from SaaS retention. The important signals are repeat usage patterns: developers returning to the docs, revisiting the demo, integrating the library into more than one screen, and using it again in later projects.

I am still early in building that measurement layer, so I do not want to overstate the retention story. What matters next is instrumenting adoption better and pairing that with stronger public examples that show developers are not just visiting the project, but actually using the workflow in real applications.

If we re-score your project in 12 months, which criterion will show the biggest improvement, and what are you doing right now to make that happen?

The biggest improvement should be in Evidence of Traction.

That is where the most upside is. Right now I am focused on:

• improving documentation quality
• creating stronger example applications
• publishing manual-vs-TableCraft comparisons
• making the first successful integration much easier

If that goes well, the public proof will become much stronger because people will have more concrete reasons to try, use, and share the project.

How Did You Hear About HackerNoon? Share With Us About Your Experience With HackerNoon.

I heard about HackerNoon through the broader developer ecosystem and public conversations around launching technical products in the open. What I like about the Proof of Usefulness framing is that it rewards utility over pure hype. That is a better lens for open-source developer tools, where the real question is not whether the product sounds exciting, but whether it actually saves people time and solves meaningful problems.

You mentioned that TableCraft builds on the success of tnks-data-table, which reached 200+ GitHub stars. How are you planning to migrate or leverage that existing community to build traction for TableCraft?

The goal is not to treat that earlier community like a traffic source. The goal is to respect the original problem they cared about and show that TableCraft is a meaningful continuation of that work.

Practically, that means clearer migration paths, clearer positioning, and better examples. I want developers who understood the value of tnks-data-table to quickly see why TableCraft matters: it expands the original idea into a more complete workflow that connects schema, API, and UI.

With an initial focus on GitHub, demo users, and docs readers, what specific technical content or open-source adoption strategies are you prioritizing to drive developer word-of-mouth growth over the next 6-12 months?

The focus is on high-signal technical content, not generic promotion.

That means publishing:

• schema-to-admin-panel walkthroughs
• manual-vs-TableCraft comparisons
• short implementation examples for common use cases
• more production-oriented documentation for Drizzle ORM + React teams

For developer tools, the best word-of-mouth usually comes from someone saying, “this saved me a lot of time,” so the strategy is to make that outcome easier to experience and easier to share. 🚀

TableCraft promises to save days of engineering time by generating full data workflows from a Drizzle schema. Can you walk us through a specific example of an admin panel or internal tool where TableCraft significantly reduced the repetitive boilerplate code for a developer?

One simple example is an orders or users admin panel.

Without TableCraft, a developer usually has to:

• build API endpoints for listing and filtering data
• parse query parameters
• implement sorting and pagination logic
• hide sensitive fields
• join related data
• add export behavior
• wire a frontend table with matching filters, state handling, and URL sync

With TableCraft, much of that becomes declarative configuration on top of the Drizzle schema. Instead of hand-building every moving part, the developer defines the behavior once and gets a production-ready workflow much faster. That is the repetitive surface area I want to compress: not the business logic that makes each product unique, but the boilerplate teams keep paying for again and again.